MySQL AB меняет лицензию

не буду спорить. просто я понял, что раз:
"We want FOSS-only (Free and Open Source Software) applications to be able to use GPL-licensed MySQL Client libraries despite the fact that not all FOSS licenses are compatible with the GPL. Therefore we have issued the following exception"
то есть дают список разрешенных лицензий, но НЕ совместимых с GPL. остальные же FOSS, может я не прав...
по мне, так вообще - чем скорее люди перейдут на СУБД postgresql с электронных таблиц - тем лучше :-)

> то есть дают список разрешенных лицензий, но НЕ совместимых с GPL

С каких пор MIT и new-style BSD стали несовместима с GPL?

Они дают список FOSS-лицензий, _отличных_ от GPL, для которых они решили сделать исключение.

Кстати в любом случае - а при чем тут лицензия явы? Вряд ли кто-нибудь будет свой софт, пусть даже и писанный на яве, под ней релизить.

> по мне, так вообще - чем скорее люди перейдут на СУБД postgresql с электронных таблиц - тем лучше :-)

Да кто ж спорит =) Я вообще так и не понял толком, _зачем_ нужен MySQL, в чем его ниша? Для мелких задач - sqlite. Для серьезного - Postgres или Firebird. Для действительно крупномасштабных вещей, Oracle - это наше все. И что здесь делать мускулю?

И что здесь делать мускулю?
---
долго думал об этом :-)
у него одно свойство - доступность широкому кругу пользователей.
а оттуда вытекает несколько следствий:
* каждый может его поставить и +- настроить
* куча кул-пхп-кодеров, самоцель которых "посмотри как я умею", а вовсе не "just for fun" (что, как мне кажется, является более продуктивным - мозги на пиписькомеренье не отвлекаются). никакого исследовательского интереса.
* из предыдущего пункта вытекает следующий: куча ужасно-написанных приложений, разработчики (?) которых даже не знают, что такое техническое задание
* отсюда же следует ощущение массовости - куча никому ненужного, глючного барахла...

подсобила ещё сильная поддержка в пхп

а так да. мускл штука конечно прикольная - для изучения sql-syntax. сейчас ссылку не дам, но парни с sf.net тестили его и постгрес у себя. мускл задыхался при одновременной регистрации 5-7 человек. падал в корку (4-ая версия вроде была там).
у него даже свойства как у таблиц - пока оперативки хватает - всё прикольно, а потом :)))

а простые сайтики, которых полно, могут вообще обойтись без базы. зачем утежелять систему. текстовые файлики самое то - быстро так :-)

Кстати в любом случае - а при чем тут лицензия явы? Вряд ли кто-нибудь будет свой софт, пусть даже и писанный на яве, под ней релизить.
---
а ну так разве лицензию на мускл не надо было покупать, если продукт свой продаешь?

С каких пор MIT и new-style BSD стали несовместима с GPL?
---
говорю ж: плохо понял, не спал ))

> а так да. мускл штука конечно прикольная - для изучения sql-syntax. > > сейчас ссылку не дам, но парни с sf.net тестили его и постгрес у себя. > мускл задыхался при одновременной регистрации 5-7 человек. падал в > корку (4-ая версия вроде была там). > у него даже свойства как у таблиц - пока оперативки хватает - всё > прикольно, а потом :)))

Хммм. Сами-то поняли что сказали? Куча примеров сайтов с количеством юзверей > 10.000, хотябы postnuke.com. Если бы оно все падало, не жил бы этот сервак уже более 10 лет :) Не хочу начинать флейм по поводу МуСКЛ-Постгрес, у каждого есть свои ++ и --. А теперь так, крутые пацаны. Моя ситуация: в месяц есть 4-5 клиентов, которые хотят платить по 300-400 у.е. за "пионерский" саит. И что, кто-то из присутствующих здесь откажется потому что "Посгрес круче"??? Или откроем свой хостинг, прикупим Т1 как минимум, постабим постгрес и будем пальцы гнуть? Не уверен. Так что уймитесь, пожалуйста.

Спасибо.

вот нашёл ссылку. прошу прощения если непраавильно вспомнил чего-то
http://www.phpbuilder.com/columns/tim20000705.php3

ещё раз говорю: у мускл есть только один плюс - это его доступность для ширкого круга кулхакеров. однако там, где он обычно применяется всегда хватает derkley db или того же sqllite... а если уж нужен сервер - то однозначно постгрес. и дело не в крутости, дело в качестве и благонадёжности

ps никто не знает как заставить этот прекрасный ресур хранить пароль, тчобы каждый раз не вводить?

> ps никто не знает как заставить этот прекрасный ресур хранить пароль, тчобы каждый раз не вводить?

use password manager

> ещё раз говорю: у мускл есть только один плюс - это его доступность > для ширкого круга кулхакеров. однако там, где он обычно применяется > всегда хватает derkley db или того же sqllite... а если уж нужен

Ок, Дык напокажиte мне проваидера, который обеспечит мне sqllite or db, плус админ интерфеис для всего этого, a? То-то.

> сервер - то однозначно постгрес. и дело не в крутости, дело в качестве > и благонадёжности

Вы, товарищ, судя по Вашему вопросу, имеете весьма скудное представление о MySQL, а рассуждаете о качестве и благонадежности :)

Спасибо.

> Ок, Дык напокажиte мне проваидера, который обеспечит мне sqllite or db, плус админ интерфеис для всего этого, a? То-то.

Вот о том и речь, Мускуль _уже_ завоевал рынок "песочниц" (заслужено или нет - это другой вопрос), и выбить его оттуда представляется проблематичным. В том числе и в силу отсутствия четких стандартов на такую штуку, как SQL (а точнее, желающих этим стандартам следовать).

Ок, Дык напокажиte мне проваидера, который обеспечит мне sqllite or db, плус админ интерфеис для всего этого, a? То-то.
------
:)))
улыбки в тему доступности беркли дб :) она везде вочти по дефолту идёт. вы лишь подтвердили то, что я сказал: проблема мускла в общедоступности
админ интерфейс. пхп есть? вперёд:
http://lv.php.net/sqlite
http://lv.php.net/manual/en/ref.dba.php
(я с этим мало сталкивался, потому читайте сами).
http://www.sleepycat.com/products/data.shtml - почитайте о возможностях berkeley db. там отличная поддержка транзакций!
попробуйте гугль :)
изучите это и возможно это избавит вас от головной боли.

Вы, товарищ, судя по Вашему вопросу, имеете весьма скудное представление о MySQL, а рассуждаете о качестве и благонадежности :)
---
эх. зато неплохо разбираюсь в СУДБ.
http://openacs.org/philosophy/why-not-mysql.html - это для начала.
вы про нормальные формы слышали? разве может штука с недоделанными foreign keys, без триггеров, процедур, транзакций считаться СУБД? нет, не может. вы возразите, что для веб-сайта эти штуки не особо нужны (корпоративного веб-сайтика простого) - я соглашусь, но ведь мы же уже говорим о СУБД. о бизнес прилождениях? а там, ой как нелегко без процедур транзакций и триггеров.

Этой ссылке (http://openacs.org/philosophy/why-not-mysql.html) уже 3 года и соответственно она уже настолько устарела что просто стыдно приводить ее в качестве аргумента.

Транзакции в MySQL есть при использование Innodb которая кстати идет в комплекте по умолчанию и очень хорошие транзакции по скорости именно транзакционного хранилиша постгресу не говоря уже о SQLLite еще ковылять до него и ковылять.

Где использовать mysql. Не знаю... Но у меня в базу пишутся заголовки всех проходящих пакетов, так вот после 10 минут работы (при большом обьёие трафика, или когда msblast был) постгресс загибался. На всякий случай попробовал мускуль (не хотел пробовать, наслушавшись всяких постгресс-защитников и мускль-обсир..ей, думал толк то какой от этого мускуля, но так как он всё равно был установлен решил потратить 20 минут на переделку под mysql) и я был очень удивлен, когда мускуль нормально проработал час, два, три... Потом у меня закралась мысль, что не всё в базу пишется и решил дай ка попробую считать iptables. После суток работы, показания iptables и то что в базе совпадало, вот так и работает уже пол года.

О транзакциях просто не все еще в курсе =)

А вот такие вещи как foreign keys и stored procedures будьте добры предъявить пожалуйста.

А что sqlite по скорости уступает мускулю - так я и не спорю (хотя не во всем, не во всем... см. таблицу на их сайте). Но дык речь шла о том, что 90% случаев использования MySQL - это в "песочницах" в связке с PHP. Так вот в этом случае о каких-то серьезных требованиях к скорости etc речь не идет. А так sqlite просто удобней. И опять же есть там некоторые вещи, которых в MySQL вроде бы нет (триггеры, скажем).

> Моя ситуация: в месяц есть 4-5 клиентов, которые хотят платить по 300-400 у.е. за "пионерский" саит. И что, кто-то из присутствующих здесь откажется потому что "Посгрес круче"???

Нет, конечно. Сам бы я на VB.NET вряд ли стал писать - но мне за это платят =)

Собственно, потому оно (VB.NET и мускуль) так и популярно...

так же можно сказать: виндозу используют на 90% компьютеров - значит она лучшая :-)

>Да кто ж спорит =) Я вообще так и не понял толком, _зачем_ нужен >MySQL, в чем его ниша? Для мелких задач - sqlite. Для серьезного - >Postgres или Firebird. Для действительно крупномасштабных вещей, >Oracle - это наше все. И что здесь делать мускулю?

а что тогда 70% свех db-серваков в нете под mysql висят ??? Postgres - плохо потдерживает стандарты сиквел.

> а что тогда 70% свех db-серваков в нете под mysql висят ??? Postgres - плохо потдерживает стандарты сиквел.

я уже говорил про леммингов.
постгрес поддерживает практически весь sql92 и и частично sql99.

в постгрес поддержка стандартов более полная нежели в мускле. подумайте почему.

>>вы про нормальные формы слышали? разве может штука с недоделанными foreign keys, без триггеров, процедур, транзакций считаться СУБД?

Программировал 3 года на Oracle PL/SQL и вот к чему пришел:
1) foreign keys - штука хорошая, но вполне можно обойтись без нее.
2) без триггеров - роу триггеры, по моему, вообще недоразумение. Во первых: дикий оверхэд из за переключений SQL to PL/SQL engines. Во вторых постоянные пляски вокруг мутации таблиц. В третьих, разбрасывание логики: таблицы (констрэйтны и дефаулт значения) - триггеры - процедуры. Лучше чтобы логика лежала в одном месте - процедурах. Короче обхожусь без триггеров вообще.
3) процедуры - без них никуда. Программирую с подходом процедур упакованных в пакеты.
4) транзакций - без них субд не субд.
Таким образом субд по минимуму должна поддерживать транзакции и как можно продвинутей (перл-ориентед?) процедурное расширение SQL. Триггеры уж точно фича - то есть клевое конечно, но совсем не обязательное потребительское свойство.

> 1) foreign keys - штука хорошая, но вполне можно обойтись без нее.

Но, согласитесь, не лишняя =) Опять же диаграммки там всякие генерить...

> 3) процедуры - без них никуда. Программирую с подходом процедур упакованных в пакеты.

Вот это интересно. Когда там в MySQL процедуры планируются? =)

> 4) транзакций

Вроде бы мускуль это умеет для InnoDB-таблиц. Только вот я слышал очень разные мнения по поводу скорости этого дела (хотя бы по сравнению с тем же постгресом), и его надежности.

Кстати, никто в Сети не видел обзора FOSS СУБД по состоянию на _сегодняшний_ день (т.е. Postgres 7.4 и MySQL 4.x)?

>>Когда там в MySQL процедуры планируются? =)
Ожидаются в MySQL 5.0
http://dev.mysql.com/doc/mysql/ru/TODO_MySQL_5.0.html

>>и как можно продвинутей (перл-ориентед?) процедурное расширение SQL.
Что там будет за язык действительно интересно.

> Postgres - плохо потдерживает стандарты сиквел.

гыгыгы... по сравнению с mysql постгрес это просто идеальная поддержка стандартов -)

Вон уже Ingres открывают, правда тоже под своей лицензией типа CPL.