MySQL 4.1.10a и 4.0.24 вышли

>потому как триггера и на с++ писать можно.

.. и завалить сервер по sigsegv с непредсказуемыми результатами.. нет ужж. Уж если пользоваться то без выкрутасов в виде udf.

>.. и завалить сервер по sigsegv с непредсказуемыми результатами.. нет ужж. Уж если пользоваться то без выкрутасов в виде udf.

Если руки кривые, сервер можно завалить и безо всяких триггеров. Одним SELECT.

>reproduceable test case не было, как смогли повторить,

Был testcase. Ты не внимательно читал.

На счет can't repeat - я это мог повторить раз через раз, на более или менее большой таблице (> 500 тыс. записей), они просто не старались. На маленьких таблицах этот баг не проявляется, что наводит на мысль, как и где нужно использовать mysql. И только через *ГОД* они смогли отловить баг, наблюдаемый мною на любом сервере, видать наконец таблица разрослась и у них.

> Вот ежели бы их в одну кучу...

Ждем MyPostgeSQL?

>Если руки кривые, сервер можно завалить и безо всяких триггеров. Одним SELECT.

Приведи пример.

>Приведи пример.

Да ради бога: SELECT goods.*, producers.*, category.category_id, prices.*, count(DISTINCT recall_id) as recalls_count, count(DISTINCT secrets_id) as secrets_count, count(DISTINCT instructions_id) as instructions_count, count(DISTINCT reviews_id) as reviews_count, count(DISTINCT logos_id) as logos_count, count(DISTINCT melodys_id) as melodys_count, count(DISTINCT soft_id) as soft_count, count(DISTINCT services_id) as services_count, count(DISTINCT forum_id) as forum_count, count(DISTINCT baraholka_id) as baraholka_count, count(DISTINCT foto_id) as foto_count FROM goods, producers, category LEFT JOIN prices ON prices.prices_goods_id=goods.goods_id LEFT JOIN recall ON recall.recall_goods_id=goods.goods_id LEFT JOIN secrets ON secrets.secrets_goods_id=goods.goods_id AND secrets.secrets_validation!=1 LEFT JOIN instructions ON instructions.instructions_goods_id=goods.goods_id AND instructions.instructions_validation!=1 LEFT JOIN

... ... ...

>Приведи пример.

Поэтому проблема не в хранимых процедурах на C, а в том, умеет человек писать код или нет. И если не умеет, то помочь ну ничем нельзя.

А касаемо Постгреса и ХП... Для задач со сложной бизнес-логикой MySQL не подходит. Ну то есть совсем. В то же время хранить _только_ HTML-контент и одну связь "один ко многим" в СУБД уровня хотя бы Postgres - безумие.

вызывающе неверная информация. полгода назад ставил постгри - все правильно работает и order by и upper и lower. с русскими и украинскими буквами и даже с недавно сравнительно введенной GHE WITH UPTURN. а вот в мыскале когда я его щупал года три назад - просто кочмарь был с этим.

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

ну с твоими хвалебными постами виндозе мы уже знакомы, а вот скажи нам юнный друк есть ли в мыскале что то подобное PL/pgSQL? а на перле\питоне можно писать процедуры?

>>но эта лицемерная двойная лицензия мне не интересна.

>Поподробнее можно, что в ней лицемерного?

Посмотрите, что остается от GPL в некоммерческой лицензии mysql, а не существует там в виде ненужного придатка, и Вы поймете.

> что то подобное PL/pgSQL?

Application server... стыкуем с любой БД, пишем на любом удобном языке,
а не на костыле pgsql, который живёт в рамках одной субд, но не живёт в
других. И зачем вообще тебе SQL база, если твоё творение ни в какую
другую БД не переносимо? Вот завтра тебе дадут команду перенести твоё
приложение на оракл... а у тебя километры на pgsql написаны... Ну, ты,
мужик, понял ;)

>а у тебя километры на pgsql написаны... Ну, ты, мужик, понял ;)

Вы НЕ работали с PL/PgSQL. Но это неважно. Вы считаете, что и на Oracle тоже не следует использовать PL/SQL?

Ну как же! Ведь дадут завтра команду - перенести все на DB2 или Informix, а у тебя там километры на PL/SQL писаны.

Ну, на огакул эти километры транслируются. На москаля же переходить команды не будет... :) А если будет, то лучше сразу искать другую работу, чем на руководство с дуршлагами вместо черепов работать...

понял что ты ни сном ни духом о ходе дискуссии

>Посмотрите, что остается от GPL в некоммерческой лицензии mysql, а не существует там в виде ненужного придатка, и Вы поймете.

Я достаточно хорошо знаю лицензию mysql, так вот там некоммерческая лицензия именно GPL, в своем чистом виде. Так сказать vanilla GPL, согласованный с FSF. Для всех кто использует GPL (и не только, для всех FOSS - compatible лицензий) mysql - бесплатен. Не верите - сходите, не поленитесь на mysql.com и прочитайте сами.

И есть коммерческая лицензия mysql _для_ _тех_ _кто_ _не_ _может_ использовать GPL. К примеру когда Novell собрался распространять mysql в составе netware, он просто не мог использовать GPL, и предпочел купить коммерческую лицензию.

Я не вижу тут ничего лицемерного..

> Вы НЕ работали с PL/PgSQL. Но это неважно.

Работал и работаю. Но это не важно ;) То - работа. Зарабатывание быстрых
и грязных денег ;) Здесь мне никто не платит. Могу говорить то, что думаю ;)

> Вы считаете, что и на Oracle тоже не следует использовать PL/SQL?

А в чём великая разница и кому важно моё мнение? Думайте сами.
Приложение как было непортабельным, так и останется. Где преимущество
стандарта SQL, который типа должен работать где угодно? Зачем нужен
единый стандарт после которого каждый с чистой совестью намертво
привязывается на всю жизнь к одной единственной БД? ;)

>Где преимущество стандарта SQL, который типа должен работать где угодно?

Стандарт SQL - это типичный сферический конь в вакууме. SELECT CURRENT_TIMESTAMP FROM DUAL; SELECT CURRENT_TIMESTAMP; SELECT NOW(); Суть одно и то же, но на разных RDBMS. И гдк тут Стандарт?

>Зачем нужен единый стандарт после которого каждый с чистой совестью намертво привязывается на всю жизнь к одной единственной БД? ;)

Можно узнать, сколько раз и с каких на какие RDBMS Вы портировали проект? Про MySQL просьба не упоминать, оно - не RDBMS. Оно - файловая система с интерфейсом SQL.

идите учитесь

Чему, если не секрет? ;)

> Оно - файловая система с интерфейсом SQL.

Очень ясное и красивое определение. От именно она и нужна. Старые как
мир лозунги юникс-вэй: KISS & Everything is file!

>Очень ясное и красивое определение. От именно она и нужна. Старые как мир лозунги юникс-вэй: KISS & Everything is file!

Просто на большее оно не способно. В отличие от взрослых СУБД. И если ваш кругозор заканчивается на движках к вебсайтам, то увы и ах, понять убогость MySQL не получится.

Где в MySQL CHECK, CONSTRAINT, VIEW? Где хранимые процедуры? Где триггеры? Все в пятой, девелоперской версии? Совсем недавно были сделаны FOREIGN KEYS. До этого орали про то, что они нафиг не нужны.

Да, без всего этого можно обойтись. В баннеровертелке или в базе для гостевой книги. Но не в крупном проекте.