Вчера целый час качал по модему MySQL 4.0 а сегодня уже 4.0.1, прикольно ;) нада посмотреть что изменили такого интересного, может еще часок покачаю.
Владимир Храмков.

Эачем тратить целый час? Гораздо проще скачать патчик http://www.mysql.com/Downloads/Patches/mysql-4.0.0-alpha-4.0.1-alpha.patch.gz

Да посмотрел я исходники, sql_cache.cc, есть там про кеширование результатов.
Даже метода расписана. Давно токое хотелось, а то приходилась на клиенте это делать что неправильно и не всегда возможно!

А тригера и транзакци как?

Чудак человек зачем спрашиваешь целый час тратить на скачивание было, так у меня исходников предыдцщих версий не было ;)
Транзакции в 4 версии есть и работают нормально, конечно под хорошей нагрузкой я не тестил но на простеньких примерчиках все - ок.
Тригеров нету :( А еще в 4.0.0 версии при компиляции ошибка выскакиевает когда делаю ./configure --with-extra-charsets=all
странно как-то, попробуйте в 4.0.1 может пофиксили этот трабл.

Господа, кстати, про транзакции. Я так понимаю что речь идет про InnoDB. Кроме транзакций она еще должна поддерживать foreign keys, но вот только как-то в 3.23.46 эти самые FK то не хотят ставиться (накладываться на таблицу - выдает ошибку создания или изменения файла tablename.frm), да еще, как утверждает дока, после alter table они ломаются и не восстанавливаются.
А как с этим в 4.0.х ? Вообще, есть ли в каком-то существующем релизе MySQL нормальная поддержка FK ?

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

>Господа, кстати, про транзакции. Я так понимаю что речь идет про >InnoDB. Кроме транзакций она еще должна поддерживать foreign keys, >но вот только как-то в 3.23.46 эти самые FK то не хотят ставиться
>(накладываться на таблицу - выдает ошибку создания или изменения >файла tablename.frm), да еще, как утверждает дока, после alter table >они ломаются и не восстанавливаются.
>А как с этим в 4.0.х ? Вообще, есть ли в каком-то существующем >релизе MySQL нормальная поддержка FK ?

Так они же в доках везде, где встречаются FK, орут, что это для лохов, а нормальные пацаны используют средства, реализованные в mySQL! ;) Вообще не понимаю, как можно поддерживать целостность данных клиентскими средствами...

Сомневаюсь, что они нормально сделают. Если изначально в архитектуру не заложено - кранты. Такие вещи нельзя памперсами вешать. Может, конечно, как обещали, заново всё перепишут...

Хех. Дык как я понял они именно для транзакций и FK и придумали InnoDB ...

Я пробовал FK на 4.0.0 и InnoDB не получилось :( Значит не сделали еще, а хотелось. Думаю в итоге придется ставить Postgress а то эти пацаны из MySQL только и делают что дают советы, ты так не делай ты делай вот так зачем тебе это возьми вот это. Задрали они не SQL получает а хрен знает что в итоге. И целостность данных никакая, под большой нагрузкой куча траблов вылазит :( типа скрипт прервался (или его прервали) что-то не докончил и кранты, бери backup и вперед. конечно транзакции и lock tables (rows &/or columns) ето уже что-то и многие проблемы решает, но все равно не дело навешивать все ето на движок который изначально не для этого делался.
Владимир Храмков

Дык ежели бы триггера сделали то вообще FK не надо:)

> Задрали они не SQL получает а хрен знает что в итоге.

А что такое SQL? Это и есть непортабельное "неусваяемое" хрен знает что-такое.
В mysql сделали великое дело. Их "SQL" на удивление портабельный! Из большой кучки
дерьма в mysql оставили от "SQL" маленькую золотую крупицу. Проблемы у вас будут
в любом случае - и с FK, и с триггерами, и с транзакциями. Вот только в mysql
последствия этих проблем много легче.

> под большой нагрузкой куча траблов вылазит:( типа скрипт прервался

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

> Проблемы у вас будут в любом случае - и с FK, и с триггерами, и с транзакциями.
> Вот только в mysql последствия этих проблем много легче.

Уважаемый, судя по заявлению ты никогда в жизни кроме select * from my_table и не писал ! И что такое _ДЕЙСТВИТЕЛЬНО БОЛЬШАЯ _ база со сложными связями ты и понятия не имеешь. Отсюда столь уверенные выкрики.

Проблемы - они есть всегда, на то тебе и з/п платят чтобы ты их решал, причем желательно быстро и успешно. А когда у тебя в базе нарушается foreign key constraint, а база содержит несколько сотен тысяч записей в каждой таблице, я посмотрю как ты прыгать начнешь ... Вот для этого и нужны:
1. Транзакции
2. FK
3. Триггеры

А пока этого не будет - никто mysql на серьезные БД не поставит, а как БД для баннерокрутилки - она действительно просто супер ...

Полностью поддерживаю предыдущего аратора ;) Дело в том что недочеты в программировании есть всегда , но ведь мы не боги а люди и следственно делаем ошибки, просто я хотел сказать что когда у меня есть идея и алгоритм ее воплощения, то я хочу работать именно над реализацией алгоритма а не сидеть и извращаться с написание запросов... очень часто бывает что нужно сделать вложенный запрос SELECT * FROM table1 WHERE id1 in (SELECT id2 FROM table2);
а ребята из MYsql мне говорят что так нельзя делай по-другому и получается что большую часть времени работы над проектом уходит на такую фигню :(

> Уважаемый, судя по заявлению ты никогда в жизни кроме select * from my_table и не писал

Писал огромный многомодульный бухгалтерский проект под оракл. Потому и предупреждаю
таких зеленых как ты, что проблем ты отгребешь в десятеро больше, чем ты их решишь с помощью
крутой и правильной СУБД. Произойдет это ровно в тот момент, когда у твоей конторы
появится жирный клиент, у которого нет оракла, но есть установленный sybase, informix и т.п.
Вот тогда и начнутся пляски с бубнами вокруг "стандартного" SQL.

А зарплату - ее и асенизаторам платят, и тоже за решение определенных проблем ;)

>Писал огромный многомодульный бухгалтерский проект под оракл
Я почему-то с детства испытываю плохие чувства к людям (они не программисты ;) которые пишут многомодульные бухгалтерские проекты.
Я просто уверен на 99% что с MySQL ты отгреб бы еще больше и что даже пляски с бубнами тебе бы не помогли при переносе, да какой там перенос, просто реализовать бухгалтерскую систему (документооборот, зряплата, кадры и прочее) на MySQL в настоящий момент является потерей времени и сил, без нормальной поддержки тригеров, сторид процедур и внешних ключей это геморой какой-то... представь как несколько человек будут менять что-то одновременно ! все хана в какой-то момент произойдет глюк и данные в таблицах не будут соотвествовать при отсутствии внешних ключей тригеров и сторидпроцедур очень много работы по поддержанию целостности данных ложиться на программу (на Перле, на Си на Пионе или еще черт знает чего) а не как должно быть - на SQL сервер, это его работа смотреть за данными... в идеале вся логика работы с данными (на ниском уровне - уровне доступа к таблицам столбцам и данным непосредственно) должна быть реализована на SQL сервере, иначе все превратиться в один момент в сплошной бардак...
проверенно на опыте, но пока от MySQL не отказался (много проектов завязаны на нем) но перевожу их на LOCK TABLES и транзакции, что-то получается, основные проблемы с не соответствием данных решены, но... много еще осталось и пока много времени трачу на поиски приемлемых решений на MySQL

Это мое субьективное мнение, я мог ошибаться.

Владимир Храмков.

2anonymous about SQL

1. Est' standart. I vse, vse dolzhny ego priderzhivat'sa. Inache poluchitsa bardak. 2. Sravni realizacii SQL v Oracle, DB2, PostgreSQL and MySQL 3. SELECT * FROM table1 WHERE id1 in (SELECT id2 FROM table2) - eto ne hrena ne pokazatel, vse zavisit ot razmera tablic, kluchey i realizacii optimizatora.