We have changed the release model so that instead of focusing on quality and features our release is now defined by timeliness and features. Quality is not regarded to be that important. To quote Mårten Mickos: "MySQL 5.1 will be release as GA in or before December because I say so". Mårten's reasons for this is that he needs something he can sell and a release marked "GA" is much easier to sell than a release marked "RC".
— Michael Widenius , Oops, we did it again (MySQL 5.1 released as GA with crashing bugs)
A>We have changed the release model so that instead of focusing on quality and features our release is now defined by timeliness and features. Quality is not regarded to be that important. To quote Mårten Mickos: "MySQL 5.1 will be release as GA in or before December because I say so". Mårten's reasons for this is that he needs something he can sell and a release marked "GA" is much easier to sell than a release marked "RC".
A>— Michael Widenius , Oops, we did it again (MySQL 5.1 released as GA with crashing bugs)
A>Вот так вот
Можно, конечно, смеяться, но эта стратегия работает. Так, MySQL по вкусным фичам уже ИМХО обгоняет PostgreeSQL. И классическое утверждение "MySQL для мелких задач, Postgree для крупных" уже перешло в разряд стереотипов, которые имеют мало общего с действительностью.
A>>We have changed the release model so that instead of focusing on quality and features our release is now defined by timeliness and features. Quality is not regarded to be that important. To quote Mårten Mickos: "MySQL 5.1 will be release as GA in or before December because I say so". Mårten's reasons for this is that he needs something he can sell and a release marked "GA" is much easier to sell than a release marked "RC".
A>>— Michael Widenius , Oops, we did it again (MySQL 5.1 released as GA with crashing bugs)
A>>Вот так вот
T>Можно, конечно, смеяться, но эта стратегия работает. Так, MySQL по вкусным фичам уже ИМХО обгоняет PostgreeSQL. И классическое утверждение "MySQL для мелких задач, Postgree для крупных" уже перешло в разряд стереотипов, которые имеют мало общего с действительностью.
Не, они обе для мелких. Для крупных MSSQL и Oracle. :>
Здравствуйте, mrTwister, Вы писали:
A>>Вот так вот
T>Можно, конечно, смеяться, но эта стратегия работает.
Да действительно смешно, уродливое поделие — а есть его фанаты. Да, работает. МММ тоже работало.
T>Так, MySQL по вкусным фичам уже ИМХО обгоняет PostgreeSQL. И классическое утверждение "MySQL для мелких задач, Postgree для крупных" уже перешло в разряд стереотипов, которые имеют мало общего с действительностью.
Вкусные фичи? Например? Нахрен невперлись фичи, если ACID-а нет.
Здравствуйте, mrTwister, Вы писали:
T>P.S.: сейчас кто-нибудь скажет, что для крупных только Oracle, а MSSQL для мелких. Хотелось бы услышать аргументацию и для этого утверждения.
Не ругайтесь девочки — это все для мелких баз.
Для крупных — kx-database.
T> Можно, конечно, смеяться, но эта стратегия работает. Так, MySQL по вкусным фичам уже ИМХО обгоняет PostgreeSQL. И классическое утверждение "MySQL для мелких задач, Postgree для крупных" уже перешло в разряд стереотипов, которые имеют мало общего с действительностью.
ачем мне нужны эти фичи, если:
— они выпускаются в ущерб качеству?
— они не работают полностью ни н одном из storage-engine'ов?
Здравствуйте, Mamut, Вы писали:
T>> ___>Нахрен невперлись фичи, если ACID-а нет. T>> Ну вот про эти стереотипы я и говорил. С чего ты взял, что ACID-а нет?
M>MyISAM не подерживает транзакции, например.
А также MEMORY, BLACKHOLE, CSV, MERGE и прочая экзотика. Только при чем тут они?
M>MyISAM — storage engine по умолчанию.
Еще один стереотип. Уже давно по умолчанию InnoDB
g> M>>MyISAM — storage engine по умолчанию.
g> T>Еще один стереотип. Уже давно по умолчанию InnoDB
g> А то что он медленный как черепаха, тоже стереотип, или до сих пор такая ситуация?
Его слегка оптимизировали. То есть он сейчас пошустрее стал
Здравствуйте, mrTwister, Вы писали:
T> T>> ___>Нахрен невперлись фичи, если ACID-а нет. T> T>> Ну вот про эти стереотипы я и говорил. С чего ты взял, что ACID-а нет?
T> M>MyISAM не подерживает транзакции, например.
T> А также MEMORY, BLACKHOLE, CSV, MERGE и прочая экзотика. Только при чем тут они?
При том, что нельзя говорить, что в MySQL-е есть ACID. Он есть при определенных условиях (например, при выборе только одного storage-engine'а — InnoDB)
T> M>MyISAM — storage engine по умолчанию.
T> Еще один стереотип. Уже давно по умолчанию InnoDB
MyISAM — The default MySQL storage engine and the one that is used the most in Web, data warehousing, and other application environments. MyISAM is supported in all MySQL configurations, and is the default storage engine unless you have configured MySQL to use a different one by default.
MyISAM — The default MySQL storage engine and the one that is used the most in Web, data warehousing, and other application environments. MyISAM is supported in all MySQL configurations, and is the default storage engine unless you have configured MySQL to use a different one by default.
MyISAM — The default MySQL storage engine and the one that is used the most in Web, data warehousing, and other application environments. MyISAM is supported in all MySQL configurations, and is the default storage engine unless you have configured MySQL to use a different one by default.
Здравствуйте, mrTwister, Вы писали:
T> M>ачем мне нужны эти фичи, если: T> M>- они выпускаются в ущерб качеству?
T> Конкретные примеры, пожалуйста.
Еще раз.
MySQL заявили, что отныне MySQL будет фокусироваться не на качестве и фичах релиза, а на своевременности релиза. Качество не считается важным.
На что mrTwister ответил:
Можно, конечно, смеяться, но эта стратегия работает. Так, MySQL по вкусным фичам уже ИМХО обгоняет PostgreeSQL.
Так вот. Нафига мне эти фичи, если «качество неважно»? Нафига мне эти ичи с вот такущим списком ошибок и багов?
T> M>- они не работают полностью ни н одном из storage-engine'ов?
T> По крайней мере есть выбор и пространство для маневра. А для подавляющего большинства потребностей с головой хватает InnoDB.
Здравствуйте, Mamut, Вы писали:
M>При том, что нельзя говорить, что в MySQL-е есть ACID. Он есть при определенных условиях (например, при выборе только одного storage-engine'а — InnoDB)
То, что у тебя есть возможность кроме InnoDB выбрать что-то другое говорит лишь в пользу MySQL. Используй InnoDB и будет тебе счастье, в чем проблема? Тебя же никто не заставляет использовать MyISAM. Это все равно, что сказать, что, например C++ не поддерживает ООП, потому что ты можешь писать на С++ не используя ООП.
M>MySQL 5.1: http://dev.mysql.com/doc/refman/5.1/en/storage-engines.html
M>MyISAM — The default MySQL storage engine and the one that is used the most in Web, data warehousing, and other application environments. MyISAM is supported in all MySQL configurations, and is the default storage engine unless you have configured MySQL to use a different one by default.
M>MySQL 5.4: http://dev.mysql.com/doc/refman/5.4/en/storage-engines.html
M>MyISAM — The default MySQL storage engine and the one that is used the most in Web, data warehousing, and other application environments. MyISAM is supported in all MySQL configurations, and is the default storage engine unless you have configured MySQL to use a different one by default.
M>MySQL 6.0: http://dev.mysql.com/doc/refman/6.0/en/storage-engines.html
M>MyISAM — The default MySQL storage engine and the one that is used the most in Web, data warehousing, and other application environments. MyISAM is supported in all MySQL configurations, and is the default storage engine unless you have configured MySQL to use a different one by default.
Это не имеет значения, так как стандартный инсталлятор меняет конфигурацию и по-умолчанию делает дефолтным InnoDB.
Здравствуйте, Mamut, Вы писали:
M>Так вот. Нафига мне эти фичи, если «качество неважно»? Нафига мне эти ичи с вот такущим списком ошибок и багов?
Во-первых, бОльшая часть этих багов закрыта. Во-вторых, лучше иметь возможность использовать некоторую фичу с незначительными ограничениями, чем не иметь возможности использовать ее вообще.
Здравствуйте, mrTwister, Вы писали:
M>>Так вот. Нафига мне эти фичи, если «качество неважно»? Нафига мне эти ичи с вот такущим списком ошибок и багов?
T>Во-первых, бОльшая часть этих багов закрыта. Во-вторых, лучше иметь возможность использовать некоторую фичу с незначительными ограничениями, чем не иметь возможности использовать ее вообще.
И что умеет mysql, чего не умел бы oracle и mssql?
Здравствуйте, ДимДимыч, Вы писали:
ДД>Здравствуйте, kuj, Вы писали:
kuj>>И что умеет mysql, чего не умел бы oracle и mssql?
ДД>Как минимум умеет распространяться бесплатно на законных основаниях.
MS SQL и Oracle умеют точно также.
Здравствуйте, ДимДимыч, Вы писали:
kuj>>И что умеет mysql, чего не умел бы oracle и mssql?
ДД>Как минимум умеет распространяться бесплатно на законных основаниях.
Здравствуйте, mrTwister, Вы писали:
T>Здравствуйте, gandjustas, Вы писали:
ДД>>>Как минимум умеет распространяться бесплатно на законных основаниях. G>>MS SQL и Oracle умеют точно также.
T>Ты хотел сказать урезанные версии, которые можно использовать только в очень мелких проектах на крохотных базах. Не смешно.
База в 4 ГБ далеко не всегда является такой мелкой как хотелось бы некоторым.
Видел множество случаев где мускл загибался на базе в 200 метров (правда какая-то древняя версия), тогда как "урезанная версия" ms sql вполне достойно работала.
Если же действительно нгужна большая база (десятки гигов), то и цена БД в цене такого решения будет занимать минимум.
Здравствуйте, mrTwister, Вы писали:
T>Здравствуйте, kuj, Вы писали:
kuj>>MS SQL и Oracle тоже. kuj>>Что еще?
T>Дай ссылку на бесплатный MSSQL или Oracle, чтобы эффективно работали на 8-ядерной машине c 16GB оперативки и 300GB базой.
Дай ссылку на тоже самое для mysql.
А также дай сравнение производительности mysql и oracle\mssql на таких объемах.
ДД>>>Как минимум умеет распространяться бесплатно на законных основаниях. G>>MS SQL и Oracle умеют точно также.
T>Ты хотел сказать урезанные версии, которые можно использовать только в очень мелких проектах на крохотных базах. Не смешно.
Угу, будто бы mysql подходит для крупных проектов. Не смешно.
Здравствуйте, ДимДимыч, Вы писали:
kuj>>MS SQL и Oracle тоже.
ДД>Что тоже? Имеют лицензию GPL?
GPL лицензия единственная известная тебе лицензия? ;]
Хватит троллить, не смешно уже.
Здравствуйте, mrTwister, Вы писали:
kuj>>MS SQL и Oracle тоже. kuj>>Что еще?
T>Дай ссылку на бесплатный MSSQL или Oracle, чтобы эффективно работали на 8-ядерной машине c 16GB оперативки и 300GB базой.
Дай ссылку на MySQL, чтобы эффективно работал на 8-ядерной машине c 16GB оперативки и 300GB базой. :]
Здравствуйте, gandjustas, Вы писали:
G>База в 4 ГБ далеко не всегда является такой мелкой как хотелось бы некоторым. G>Видел множество случаев где мускл загибался на базе в 200 метров (правда какая-то древняя версия), тогда как "урезанная версия" ms sql вполне достойно работала.
Бла-бла-бла ни о чем.
G>Если же действительно нгужна большая база (десятки гигов), то и цена БД в цене такого решения будет занимать минимум.
Не понял логики: как связан размер базы со стоимостью решения?
Здравствуйте, gandjustas, Вы писали:
T>>Дай ссылку на бесплатный MSSQL или Oracle, чтобы эффективно работали на 8-ядерной машине c 16GB оперативки и 300GB базой.
G>Дай ссылку на тоже самое для mysql. http://dev.mysql.com/downloads/mysql/5.1.html
G>А также дай сравнение производительности mysql и oracle\mssql на таких объемах.
Бесплатные версии oracle\mssql на таких объемах не работают вообще.
Здравствуйте, mrTwister, Вы писали:
G>>База в 4 ГБ далеко не всегда является такой мелкой как хотелось бы некоторым. G>>Видел множество случаев где мускл загибался на базе в 200 метров (правда какая-то древняя версия), тогда как "урезанная версия" ms sql вполне достойно работала.
T>Бла-бла-бла ни о чем.
Жжесть аргумент. Ржу.
G>>Если же действительно нгужна большая база (десятки гигов), то и цена БД в цене такого решения будет занимать минимум.
T>Не понял логики: как связан размер базы со стоимостью решения?
Здравствуйте, kuj, Вы писали:
kuj>Здравствуйте, mrTwister, Вы писали:
kuj>>>MS SQL и Oracle тоже. kuj>>>Что еще?
T>>Дай ссылку на бесплатный MSSQL или Oracle, чтобы эффективно работали на 8-ядерной машине c 16GB оперативки и 300GB базой.
kuj>Дай ссылку на MySQL, чтобы эффективно работал на 8-ядерной машине c 16GB оперативки и 300GB базой. :]
Здравствуйте, kuj, Вы писали: G>>>Видел множество случаев где мускл загибался на базе в 200 метров (правда какая-то древняя версия), тогда как "урезанная версия" ms sql вполне достойно работала.
T>>Бла-бла-бла ни о чем.
kuj>Жжесть аргумент. Ржу.
Аргумент не лучше, чем: "когда-то где-то видел, как древняя версия mysql работала хуже, чем MSSQL". Я тоже могу написать, что видел, как ВАЗ2109 обогнал мерседес 30-ого года выпуска. Какой из этого можно сделать вывод?
G>>>Если же действительно нгужна большая база (десятки гигов), то и цена БД в цене такого решения будет занимать минимум.
T>>Не понял логики: как связан размер базы со стоимостью решения?
kuj>Ну раз не понял, значит не судьба. ;]
Здравствуйте, mrTwister, Вы писали:
T>>>Дай ссылку на бесплатный MSSQL или Oracle, чтобы эффективно работали на 8-ядерной машине c 16GB оперативки и 300GB базой.
kuj>>Дай ссылку на MySQL, чтобы эффективно работал на 8-ядерной машине c 16GB оперативки и 300GB базой. :]
T>http://dimitrik.free.fr/db_STRESS_MySQL_540_and_others_Apr2009.html#note_5443
T>В два раза быстрее, чем Postgrees
и где там "8-ядерной машине c 16GB оперативки и 300GB базой"? ;]
Здравствуйте, mrTwister, Вы писали:
T>Здравствуйте, gandjustas, Вы писали:
G>>База в 4 ГБ далеко не всегда является такой мелкой как хотелось бы некоторым. G>>Видел множество случаев где мускл загибался на базе в 200 метров (правда какая-то древняя версия), тогда как "урезанная версия" ms sql вполне достойно работала. T>Бла-бла-бла ни о чем.
Гы-гы. Съехал.
G>>Если же действительно нгужна большая база (десятки гигов), то и цена БД в цене такого решения будет занимать минимум. T>Не понял логики: как связан размер базы со стоимостью решения?
Непосредственно. Огромные объемы данных просто так никому не нужны. Программы обрабатывающие такие объемы данных стоят недешево.
Здравствуйте, mrTwister, Вы писали:
T>Здравствуйте, gandjustas, Вы писали:
T>>>Дай ссылку на бесплатный MSSQL или Oracle, чтобы эффективно работали на 8-ядерной машине c 16GB оперативки и 300GB базой.
G>>Дай ссылку на тоже самое для mysql. T>http://dev.mysql.com/downloads/mysql/5.1.html
Ну так где 8-ядерная машина c 16GB оперативки и 300GB базой?
G>>А также дай сравнение производительности mysql и oracle\mssql на таких объемах. T>Бесплатные версии oracle\mssql на таких объемах не работают вообще.
Судя по тому что ссылок нету бесплатный mysql тоже на таких объемах не работает, да и платный вряд ли.
Здравствуйте, mrTwister, Вы писали:
T>Здравствуйте, kuj, Вы писали:
kuj>>Здравствуйте, mrTwister, Вы писали:
kuj>>>>MS SQL и Oracle тоже. kuj>>>>Что еще?
T>>>Дай ссылку на бесплатный MSSQL или Oracle, чтобы эффективно работали на 8-ядерной машине c 16GB оперативки и 300GB базой.
kuj>>Дай ссылку на MySQL, чтобы эффективно работал на 8-ядерной машине c 16GB оперативки и 300GB базой. :]
T>http://dimitrik.free.fr/db_STRESS_MySQL_540_and_others_Apr2009.html#note_5443
T>В два раза быстрее, чем Postgrees
Да уж, на интеловских тестах интеловские процессоры всегда были быстрее всех.
Здесь аналогичный случай
Здравствуйте, gandjustas, Вы писали:
G>>>А также дай сравнение производительности mysql и oracle\mssql на таких объемах. T>>Бесплатные версии oracle\mssql на таких объемах не работают вообще. G>Судя по тому что ссылок нету бесплатный mysql тоже на таких объемах не работает,
Хватит торллить. В ссылке объемы еще больше.
G>да и платный вряд ли.
Платный от бесплатного отличается только наличием поддержки (АФАИК).
G>>>Если же действительно нгужна большая база (десятки гигов), то и цена БД в цене такого решения будет занимать минимум. T>>Не понял логики: как связан размер базы со стоимостью решения? G>Непосредственно. Огромные объемы данных просто так никому не нужны.
Верно.
G>Программы обрабатывающие такие объемы данных стоят недешево.
Здравствуйте, mrTwister, Вы писали:
T>Здравствуйте, gandjustas, Вы писали:
G>>>>Если же действительно нгужна большая база (десятки гигов), то и цена БД в цене такого решения будет занимать минимум. T>>>Не понял логики: как связан размер базы со стоимостью решения? G>>Непосредственно. Огромные объемы данных просто так никому не нужны. T>Верно.
G>>Программы обрабатывающие такие объемы данных стоят недешево. T>С чего ты взял?
Наверное с того что разработкой подобных программ занимаюсь.
Здравствуйте, gandjustas, Вы писали:
G>Да уж, на интеловских тестах интеловские процессоры всегда были быстрее всех. G>Здесь аналогичный случай
Потому что у интела и амд был примерно паритет и путем использования более "удобных" тестов можно было добиться преимущества как интела так и амд. С MySQL ситуация аналогична. Я не утверждаю, что MySQL работает быстрее, чем MSSQL (хотя могу написать тест, который будет работать быстрее на мускуле), я лишь утверждаю, что его производительность как минимум сопоставима с остальными ведущими СУБД. Разница незначительна и возможные просады производительности всегда можно выличить стандартными средствами (хинты, индексы, переписывание запроса и пр.). Причем это относится не только к MySQL. Низкая производительность и масштабируемость — это не аргумент против MySQL.
Здравствуйте, ДимДимыч, Вы писали:
ДД>Здравствуйте, kuj, Вы писали:
kuj>>И что умеет mysql, чего не умел бы oracle и mssql?
ДД>Как минимум умеет распространяться бесплатно на законных основаниях.
5-ый вроде как умеет. Стал платным. Могу ошибаться.
Здравствуйте, mrTwister, Вы писали:
T> M>При том, что нельзя говорить, что в MySQL-е есть ACID. Он есть при определенных условиях (например, при выборе только одного storage-engine'а — InnoDB)
T> То, что у тебя есть возможность кроме InnoDB выбрать что-то другое говорит лишь в пользу MySQL. Используй InnoDB и будет тебе счастье, в чем проблема? Тебя же никто не заставляет использовать MyISAM. Это все равно, что сказать, что, например C++ не поддерживает ООП, потому что ты можешь писать на С++ не используя ООП.
Любая аналогия является по умолчанию неверной.
Еще раз. По буквам.
Ни один из storage-engine'ов MySQL не поддерживает все фичи MySQL полностью.
Из-за этого приходится тратить дополнитлеьные усилия на проверку — а подходит ли нам этот движок или нет? А можем ли мы пожертвовать теми или иными фичами ли нет? А где у нас будет просаживание в производитльности, а где нет? А раздует ли добавление нового индекса в таблицу требования к харду в три раза или нет? Если нет, то не просадит ли он производительность в четыре раза? Если нет, то не наложит ли ограничения еще на что-нибудь? И т.п.
T> M>MyISAM — The default MySQL storage engine and the one that is used the most in Web, data warehousing, and other application environments. MyISAM is supported in all MySQL configurations, and is the default storage engine unless you have configured MySQL to use a different one by default.
T> Это не имеет значения, так как стандартный инсталлятор меняет конфигурацию и по-умолчанию делает дефолтным InnoDB.
Это имеет значение, когда кто-то безаппеляционно заявляет что-то типа:
T> Еще один стереотип. Уже давно по умолчанию InnoDB
Как оказалось, давно и в обозримом будущем движок по умолчанию — не InnoDB.
Здравствуйте, mrTwister, Вы писали:
T> M>Так вот. Нафига мне эти фичи, если «качество неважно»? Нафига мне эти ичи с вот такущим списком ошибок и багов?
T> Во-первых, бОльшая часть этих багов закрыта.
После выхода 5.1, ага
T> Во-вторых, лучше иметь возможность использовать некоторую фичу с незначительными ограничениями, чем не иметь возможности использовать ее вообще.
Во-вторых, лучше иметь возможность использовать стабильный продукт, чьим лозунго не является «Качество — не важно»
Здравствуйте, mrTwister, Вы писали:
T>Потому что у интела и амд был примерно паритет и путем использования более "удобных" тестов можно было добиться преимущества как интела так и амд. С MySQL ситуация аналогична. Я не утверждаю, что MySQL работает быстрее, чем MSSQL (хотя могу написать тест, который будет работать быстрее на мускуле)
Напиши.
Здравствуйте, mrTwister, Вы писали:
T>Можно, конечно, смеяться, но эта стратегия работает. Так, MySQL по вкусным фичам уже ИМХО обгоняет PostgreeSQL. И классическое утверждение "MySQL для мелких задач, Postgree для крупных" уже перешло в разряд стереотипов, которые имеют мало общего с действительностью.
Что там с check constraints? (Стандартная фича SQL, между прочим.) А живы ли ещё .frm-файлы, которые не журналируются и в итоге легко могут повредиться, и транзакции их не спасут? А что у нас с sequences? Или до сих пор нет ничего, кроме auto_increment, значения которого сбрасываются в select(max(id)) при перезапуске сервера? А что у нас с типом timestamp, первое поле которого ведёт себя как on insert/update set now (или как там), а остальные on update set null?
D>Что там с check constraints? (Стандартная фича SQL, между прочим.)
Внешние ключи есть, check constraints нет. Это не является препятствием для использования в крупных проектах.
D>А живы ли ещё .frm-файлы, которые не журналируются и в итоге легко могут повредиться, и транзакции их не спасут?
Файлы живы, но в случае с InnoDB они никем не модифицируются, могут быть в любой момент восстановлены, а следовательно не нуждаются в журналировании.
D>А что у нас с sequences? Или до сих пор нет ничего, кроме auto_increment,
Что не мешает жить MSSQL'ю
D>значения которого сбрасываются в select(max(id)) при перезапуске сервера?
Нет такого.
D>А что у нас с типом timestamp, первое поле которого ведёт себя как on insert/update set now (или как там), а остальные on update set null?
Здравствуйте, Mamut, Вы писали:
M>Любая аналогия является по умолчанию неверной.
M>Еще раз. По буквам.
M>Ни один из storage-engine'ов MySQL не поддерживает все фичи MySQL полностью.
InnoDB поддерживает достаточно фич, чтобы использовать остальные движки при необходимости в очень редких случаях.
T>> Это не имеет значения, так как стандартный инсталлятор меняет конфигурацию и по-умолчанию делает дефолтным InnoDB.
M>Это имеет значение, когда кто-то безаппеляционно заявляет что-то типа: M>
T>> Еще один стереотип. Уже давно по умолчанию InnoDB
M>Как оказалось, давно и в обозримом будущем движок по умолчанию — не InnoDB.
Это смотря что считать движком по умолчанию. При отсутствии конфигурации движок по умолчанию MyISAM. Возможно, это сделано для совместимости. Но факт то, что инсталлятор прописывает в конфиге по умолчанию InnoDB и именно InnoDB становится движком по умолчанию.
Здравствуйте, mrTwister, Вы писали:
T> M>Любая аналогия является по умолчанию неверной.
T> M>Еще раз. По буквам.
T> M>Ни один из storage-engine'ов MySQL не поддерживает все фичи MySQL полностью.
T> InnoDB поддерживает достаточно фич, чтобы использовать остальные движки при необходимости в очень редких случаях.
Угу, то-то мужики об этом не знают и ждут-не дождутся Flcon, который наконец-то будет компромиссом между InnoDB и MyISAM'ом
И то-то в High Performance MySQL целая глава о выборе storage engine'ов написана. Не говоря уже о постоянных сносках на engine'ы практически во всех главах — от оптимизации запросов до индексов до бэкапов. И каждый раз предупреждение: остороно, здесь потенциальная жопа, если вдруг вы используете MyISAM, а не InnoDB, и наоборот
T> T>> Это не имеет значения, так как стандартный инсталлятор меняет конфигурацию и по-умолчанию делает дефолтным InnoDB.
Не знаю, где и какой инсталлятор так делает, дефолтным движком в MySQL является MyISAM.
T> M>Это имеет значение, когда кто-то безаппеляционно заявляет что-то типа: T> M>
T> T>> Еще один стереотип. Уже давно по умолчанию InnoDB
T> M>
T> M>Как оказалось, давно и в обозримом будущем движок по умолчанию — не InnoDB.
T> Это смотря что считать движком по умолчанию. При отсутствии конфигурации движок по умолчанию MyISAM. Возможно, это сделано для совместимости. Но факт то, что инсталлятор прописывает в конфиге по умолчанию InnoDB и именно InnoDB становится движком по умолчанию.
Блин. «смотря что считать».. Ага. Еще раз:
MyISAM — The default MySQL storage engine and the one that is used the most in Web, data warehousing, and other application environments. MyISAM is supported in all MySQL configurations, and is the default storage engine unless you have configured MySQL to use a different one by default.
То, что авторы инсталлятора решили менять конфигурацию, остается на совести авторов инсталлятора. Движком MySQL по умолчанию является MyISAM. Думаю, авторам документации и, скажем, бывшему Manager of High Performace Group at MySQL Inc (одному из авторов High Performance MySQL)известно, что считать движком MySQL по умолчанию. Движком по умолчанию они называют MyISAM.
Здравствуйте, mrTwister, Вы писали:
D>>Что там с check constraints? (Стандартная фича SQL, между прочим.) T>Внешние ключи есть, check constraints нет. Это не является препятствием для использования в крупных проектах.
Гы.
D>>А живы ли ещё .frm-файлы, которые не журналируются и в итоге легко могут повредиться, и транзакции их не спасут? T>Файлы живы, но в случае с InnoDB они никем не модифицируются, могут быть в любой момент восстановлены, а следовательно не нуждаются в журналировании.
Если бы всё было так радужно, я бы и не знал о том, что эти файлы вообще существуют. И кстати, их наличие не позволяет использовать DDL с возможностью отката, что крайне полезно при автоматическом обновлении структуры базы.
D>>А что у нас с sequences? Или до сих пор нет ничего, кроме auto_increment, T>Что не мешает жить MSSQL'ю
MSSQL-евцы! У вас что, тоже sequences нет?! Не верю.
D>>значения которого сбрасываются в select(max(id)) при перезапуске сервера? T>Нет такого.
http://bugs.mysql.com/bug.php?id=41116
Статус: Not A Bug, but InnoDB restriction.
D>>А что у нас с типом timestamp, первое поле которого ведёт себя как on insert/update set now (или как там), а остальные on update set null? T>Не понял, что ты имеешь ввиду?
T>> InnoDB поддерживает достаточно фич, чтобы использовать остальные движки при необходимости в очень редких случаях.
M>Угу, то-то мужики об этом не знают и ждут-не дождутся Flcon, который наконец-то будет компромиссом между InnoDB и MyISAM'ом
M>И то-то в High Performance MySQL целая глава о выборе storage engine'ов написана. Не говоря уже о постоянных сносках на engine'ы практически во всех главах — от оптимизации запросов до индексов до бэкапов. И каждый раз предупреждение: остороно, здесь потенциальная жопа, если вдруг вы используете MyISAM, а не InnoDB, и наоборот
MyISAM — это очень специфический движек, который вместе со специфическими возможностями имеет и специфические ограничения. Он никто тебя не заставляет насильно его использовать. Есть InnoDB, который представляет собой обычную, классическую реализацию MVCC и является по сути аналогом движков от оракла или скюл сервера. Вот было утверждение, что MySQL мол не поддерживает ACID. А кто поддерживает? MSSQL? Ну дак аналогом движка MSSQL по сути является InnoDB. Да, InnoDB не поддерживает фичи MyISAM. Ну дак и MSSQL тоже не поддерживает фичи MyISAM.
Ага. Я еще ни разу не видел их использования в реальных крупных оракловых базах. Там таже форенкеи и те редкость.
D>>>А что у нас с sequences? Или до сих пор нет ничего, кроме auto_increment, T>>Что не мешает жить MSSQL'ю
D>MSSQL-евцы! У вас что, тоже sequences нет?! Не верю.
When started, mysql server is automatically resetting the AUTO_INCREMENT value for tables which are empty (does not reset the value for non-empty tables).
T>When started, mysql server is automatically resetting the AUTO_INCREMENT value for tables which are empty (does not reset the value for non-empty tables).
Да, тут я попутал. Впрочем, поведение всё равно дурацкое — я его запомнил только потому что кто-то на кывте жаловался и спрашивал, как сделать по-нормальному.
Здравствуйте, dimgel, Вы писали:
D>>>А что у нас с sequences? Или до сих пор нет ничего, кроме auto_increment, T>>Что не мешает жить MSSQL'ю
D>MSSQL-евцы! У вас что, тоже sequences нет?! Не верю.
А они и не нужны, так как есть comparable guid`ы (newsequentialid() — генерирует GUID`ы, где каждый последующий арифметически больше предыдущего), и COMB GUID`ы (сурогатные идентификаторы).
Здравствуйте, criosray, Вы писали:
D>>MSSQL-евцы! У вас что, тоже sequences нет?! Не верю. C>А они и не нужны, так как есть comparable guid`ы (newsequentialid() — генерирует GUID`ы, где каждый последующий арифметически больше предыдущего), и COMB GUID`ы (сурогатные идентификаторы).
Спасибо, очень интересная инфа.
Твистер, а в мускуле есть comparable GUIDs, раз уж последовательностями обделили?
Здравствуйте, mrTwister, Вы писали:
T>Здравствуйте, kuj, Вы писали:
kuj>>Угу, будто бы mysql подходит для крупных проектов. Не смешно.
T>Я уже просил привести аргументацию, почему не подходит. Единственный ответ был: "нет ACID"
Он уже научился распаралеливать запрос на несколько процов? Поправили уже проседание производительности в subqueries?
Luck in life always exists in the form of an abstract class that cannot be instantiated directly and needs to be inherited by hard work and dedication.
Здравствуйте, mrTwister, Вы писали:
T>Дай ссылку на бесплатный MSSQL или Oracle, чтобы эффективно работали на 8-ядерной машине c 16GB оперативки и 300GB базой.
Though may we should not be as surprised by these results — MySQL 6.0 still does not have hash or merge join which are frequently used for these kind of queries, and there is also no query parallelization which would allow MySQL to use CPUs and hard drives this system has more efficiently. Parallel query will be growing issue for MySQL because CPUs just continue to add more cores. Having 2 CPUs and being able to use only half of system CPU resources for query processing was not too bad, however with 16,32,64 cores it is just too bad.
Luck in life always exists in the form of an abstract class that cannot be instantiated directly and needs to be inherited by hard work and dedication.
Задавшись вопросом, а как с этим делом у PostgreSQL, нашёл интереснейшее обсуждение по производительности PgSQL vs MySQL: http://news.ycombinator.com/item?id=423523
Может ещё кому-нибудь понравится.
Здравствуйте, mrTwister, Вы писали:
T>Здравствуйте, Mamut, Вы писали:
M>>При том, что нельзя говорить, что в MySQL-е есть ACID. Он есть при определенных условиях (например, при выборе только одного storage-engine'а — InnoDB)
T>То, что у тебя есть возможность кроме InnoDB выбрать что-то другое говорит лишь в пользу MySQL. Используй InnoDB и будет тебе счастье, в чем проблема?
Luck in life always exists in the form of an abstract class that cannot be instantiated directly and needs to be inherited by hard work and dedication.
Здравствуйте, yuriylsh, Вы писали:
Y>Здравствуйте, mrTwister, Вы писали:
T>>Дай ссылку на бесплатный MSSQL или Oracle, чтобы эффективно работали на 8-ядерной машине c 16GB оперативки и 300GB базой.
Y>
Y>
Y>Though may we should not be as surprised by these results — MySQL 6.0 still does not have hash or merge join which are frequently used for these kind of queries, and there is also no query parallelization which would allow MySQL to use CPUs and hard drives this system has more efficiently. Parallel query will be growing issue for MySQL because CPUs just continue to add more cores. Having 2 CPUs and being able to use only half of system CPU resources for query processing was not too bad, however with 16,32,64 cores it is just too bad.
Здравствуйте, dimgel, Вы писали:
d> Твистер, а в мускуле есть comparable GUIDs, раз уж последовательностями обделили?
Есть простые UUID(), которые представляются строкой в UTF-8 (в 6.0 есть UUID_SHORT(), которые в 2 раза короче). Не смотря на то, что в документации явно не оговаривается его монотонное возрастание, на практике, под никсами, при наличии одной и той же сетевухи и монотонности времени, он монотонно возрастает (это может быть важно при использовании его в качестве ключа для InnoDB на больших таблицах).
Здравствуйте, ДимДимыч, Вы писали:
ДД>Как минимум умеет распространяться бесплатно на законных основаниях.
Один из стереотипов про MySQL — это его "бесплатность". Он бесплатен и поставляется в исходниках только для разработчиков FOSS.
Здравствуйте, Anton Batenev, Вы писали:
AB>Есть простые UUID()
Если он не Globally-Unique, то и радости от него ИМХО не сильно больше, чем от обычного serial. С другой стороны, GUID как правило без разницы где генерировать — в приложении или в SQL-сервере. За исключением случаев insert-select, или там insert из триггера. Тогда UDF.
Здравствуйте, yuriylsh, Вы писали:
Y>Он уже научился распаралеливать запрос на несколько процов?
да
Y>Поправили уже проседание производительности в subqueries?
да
Здравствуйте, agos, Вы писали:
A>Здравствуйте, ДимДимыч, Вы писали:
ДД>>Как минимум умеет распространяться бесплатно на законных основаниях. A>Один из стереотипов про MySQL — это его "бесплатность". Он бесплатен и поставляется в исходниках только для разработчиков FOSS.
Здравствуйте, dimgel, Вы писали:
d> AB>Есть простые UUID() d> Если он не Globally-Unique, то и радости от него ИМХО не сильно больше, чем от обычного serial.
Я имел ввиду, что под это не выделено отдельной сущности. А так, он вполне себе unique (GUID — это всего лишь одна из реализаций стандарта).
Здравствуйте, mrTwister, Вы писали:
T>Здравствуйте, yuriylsh, Вы писали:
Y>>Он уже научился распаралеливать запрос на несколько процов? T>да
нет
Y>>Поправили уже проседание производительности в subqueries? T>да
нет
Luck in life always exists in the form of an abstract class that cannot be instantiated directly and needs to be inherited by hard work and dedication.
Здравствуйте, mrTwister, Вы писали:
T> T>> InnoDB поддерживает достаточно фич, чтобы использовать остальные движки при необходимости в очень редких случаях.
T> M>Угу, то-то мужики об этом не знают и ждут-не дождутся Flcon, который наконец-то будет компромиссом между InnoDB и MyISAM'ом
T> M>И то-то в High Performance MySQL целая глава о выборе storage engine'ов написана. Не говоря уже о постоянных сносках на engine'ы практически во всех главах — от оптимизации запросов до индексов до бэкапов. И каждый раз предупреждение: остороно, здесь потенциальная жопа, если вдруг вы используете MyISAM, а не InnoDB, и наоборот
T> MyISAM — это очень специфический движек, который вместе со специфическими возможностями имеет и специфические ограничения. Он никто тебя не заставляет насильно его использовать. Есть InnoDB, который представляет собой обычную, классическую реализацию MVCC и является по сути аналогом движков от оракла или скюл сервера. Вот было утверждение, что MySQL мол не поддерживает ACID. А кто поддерживает? MSSQL? Ну дак аналогом движка MSSQL по сути является InnoDB. Да, InnoDB не поддерживает фичи MyISAM. Ну дак и MSSQL тоже не поддерживает фичи MyISAM.
Еще раз объясняю внятно и по-русски:
1. Ни один из движков MySQL не поддеживает все фичи, заявленные для MySQL'я
2. Если говорится, что MySQL поддерживает то-то и то-то, надо говорить, какой именно движок эту фичу поддерживает и с какой версии.
3. Именно эта чехарда с движками и фичами затрудняет если нне использование MySQL, то оценку его возможностей точно
4. Движком по умолчанию в MySQL'е все равно является MyISAM
Здравствуйте, dimgel, Вы писали:
D>Задавшись вопросом, а как с этим делом у PostgreSQL, нашёл интереснейшее обсуждение по производительности PgSQL vs MySQL: http://news.ycombinator.com/item?id=423523 D>Может ещё кому-нибудь понравится.
Собственно я полностью согласен с фразой:
The differences between the two are really minor today. Choose whichever one you like, but there are definite reasons to choose either one.
Причем я бы добавил, что разница сокращается не только между Postgree и MySQL но и и в том числе MSSQL, Oracle. То есть популярные СУБД становятся все более однообразны.
Здравствуйте, mrTwister, Вы писали:
T>Причем я бы добавил, что разница сокращается не только между Postgree и MySQL но и и в том числе MSSQL, Oracle. То есть популярные СУБД становятся все более однообразны.
Здравствуйте, mrTwister, Вы писали:
T> ДД>>Как минимум умеет распространяться бесплатно на законных основаниях.
T> A>Один из стереотипов про MySQL — это его "бесплатность". Он бесплатен и поставляется в исходниках только для разработчиков FOSS.
T> http://dev.mysql.com/downloads/mysql/5.1.html T>
T> No cost, freely available under the GPL License
agos сказал абсолютно то же самое, только другими словами.
Здравствуйте, criosray, Вы писали:
C>Здравствуйте, mrTwister, Вы писали:
T>>Причем я бы добавил, что разница сокращается не только между Postgree и MySQL но и и в том числе MSSQL, Oracle. То есть популярные СУБД становятся все более однообразны.
C>Это валидно только в контексте "моя первая пага".
Здравствуйте, mrTwister, Вы писали:
T> M>Еще раз объясняю внятно и по-русски: T> M>1. Ни один из движков MySQL не поддеживает все фичи, заявленные для MySQL'я
T> MSSQL тоже не поддерживает все фичи, заявленные для MySQL'я. И что?
Зато MSSQL пожжерживает все фичи, заявленные для MSSQL.
Когда говоришь, что MySQL подерживает ту или иную фичу, надо обязательно уточнять, для какого из двиков он эту фичу поддерживает. Потому что в MySQL нельзя одновременно поиметь и ACID и Full-text search, например.
Здравствуйте, yuriylsh, Вы писали:
Y>Здравствуйте, mrTwister, Вы писали:
T>>Здравствуйте, yuriylsh, Вы писали:
Y>>>Он уже научился распаралеливать запрос на несколько процов? T>>да Y>нет
Y>>>Поправили уже проседание производительности в subqueries? T>>да Y>нет http://www.mysql.com/news-and-events/generate-article.php?id=1602
Здравствуйте, mrTwister, Вы писали:
T>Здравствуйте, yuriylsh, Вы писали:
Y>>Здравствуйте, mrTwister, Вы писали:
T>>>Здравствуйте, yuriylsh, Вы писали:
Y>>>>Он уже научился распаралеливать запрос на несколько процов? T>>>да Y>>нет
Y>>>>Поправили уже проседание производительности в subqueries? T>>>да Y>>нет T>http://www.mysql.com/news-and-events/generate-article.php?id=1602
И? Что ты хотел этим сказать? Ты подрабатываешь у Sun распространением пресс-релизов? С таким уровнем аргументации можешь не напрягаться.
З.Ы.
# Scalability improvements -- these fixes allow the InnoDB storage engine to scale up to 16-way x86 servers and 64-way CMT servers, more than doubling its previous capability;
Это никакого отношения к моему первому вопросу не имеет.
# Subquery optimizations -- improves the performance of analytic query operations, with some subqueries now executing in a fraction of the time compared to previous MySQL versions;
Меня не интересую some subqueries.
The subquery must satisfy these conditions (этого ты нагуглить не успел, наверное...):
* It is not a UNION or UNION ALL
* It doesn't have GROUP BY, HAVING or any kind of aggregate functions
* It doesn't have ORDER BY ... LIMIT clause
Luck in life always exists in the form of an abstract class that cannot be instantiated directly and needs to be inherited by hard work and dedication.
Здравствуйте, yuriylsh, Вы писали:
Y>Ты подрабатываешь у Sun распространением пресс-релизов?
Нет.
Y>С таким уровнем аргументации можешь не напрягаться.
У тебя аргументации вообще нет никакой.
agos wrote:
> ДД>Как минимум умеет распространяться бесплатно на законных основаниях. > Один из стереотипов про MySQL — это его "бесплатность". Он бесплатен и поставляется в исходниках > только для разработчиков FOSS.
Обана, а какже я его из исходников то в генте собираю? о0
Ты чтото напутал.
Mamut wrote:
> agos сказал абсолютно то же самое, только другими словами.
Поясни ка, а то чтото я не вижу связи между "Он бесплатен и поставляется в исходниках только для разработчиков FOSS." и "No
cost, freely available under the GPL License", ибо первая фраза явно ограничивает количество людей, которым доступны исходники,
а вторая явно указывает что исходники в общем доступе.
Здравствуйте, fmiracle, Вы писали:
F>Здравствуйте, landerhigh, Вы писали:
kuj>>>Не, они обе для мелких. Для крупных MSSQL и Oracle. :> L>>Зеленая <b>груша</b>. F>Слива!
Слива в отношении к программному обеспечению звучит как-то неправильно
Здравствуйте, Sheridan, Вы писали:
S>Поясни ка, а то чтото я не вижу связи между "Он бесплатен и поставляется в исходниках только для разработчиков FOSS." и "No S>cost, freely available under the GPL License", ибо первая фраза явно ограничивает количество людей, которым доступны исходники, S>а вторая явно указывает что исходники в общем доступе.
Ну вообще-то вторая фраза точно так же ограничивает.
Здравствуйте, mrTwister, Вы писали:
T>>>Причем я бы добавил, что разница сокращается не только между Postgree и MySQL но и и в том числе MSSQL, Oracle. То есть популярные СУБД становятся все более однообразны.
C>>Это валидно только в контексте "моя первая пага".
T>Что ты имеешь ввиду?
Для самых примитивных запросов select from where a = b
Здравствуйте, Anton Batenev, Вы писали:
AB>Здравствуйте, dimgel, Вы писали:
d>> Твистер, а в мускуле есть comparable GUIDs, раз уж последовательностями обделили?
AB>Есть простые UUID(), которые представляются строкой в UTF-8
Че-то какой-то гон. GUID — 16 байтное целое число, а здесь строки?
Здравствуйте, mrTwister, Вы писали:
T>Здравствуйте, Mamut, Вы писали:
M>>Еще раз объясняю внятно и по-русски: M>>1. Ни один из движков MySQL не поддеживает все фичи, заявленные для MySQL'я
T>MSSQL тоже не поддерживает все фичи, заявленные для MySQL'я. И что?
А обязан?
Интересный аргумент. Я вот пообещал что ты с крыши спрыгнешь — иди уж выполняй мое обещание.
WF> A>Ну вообще-то вторая фраза точно так же ограничивает. WF> Да, ты не можешь сделать на его основе продукт с другой лицензией. WF> Но что мешает использовать его бесплатно (и совершенно легально) в коммерческом проекте?
GPL. Потому что тогда придется открывать исходники этого самого коммерческого проекта. Если только не извращаться по страшному
Здравствуйте, Mamut, Вы писали:
WF>> A>Ну вообще-то вторая фраза точно так же ограничивает. WF>> Да, ты не можешь сделать на его основе продукт с другой лицензией. WF>> Но что мешает использовать его бесплатно (и совершенно легально) в коммерческом проекте?
M>GPL. Потому что тогда придется открывать исходники этого самого коммерческого проекта. Если только не извращаться по страшному
WF> WF>> Да, ты не можешь сделать на его основе продукт с другой лицензией. WF> WF>> Но что мешает использовать его бесплатно (и совершенно легально) в коммерческом проекте?
WF> M>GPL. Потому что тогда придется открывать исходники этого самого коммерческого проекта. Если только не извращаться по страшному
WF> Да, но мы же не делаем "work based on the MySQL"?
Сложно сказать. Там ГПЛ достаточно мутна в этом отношении
Здравствуйте, Mamut, Вы писали:
M>Сложно сказать. Там ГПЛ достаточно мутна в этом отношении
Что мутного, SQL сервер — это отдельное приложение, связь с которым осуществляется по TCP. Чем он в этом смысле принципиально отличается от, скажем апача?
Здравствуйте, yuriylsh, Вы писали:
Y>Меня не интересую some subqueries.
А что тебя интересует?
Y>The subquery must satisfy these conditions (этого ты нагуглить не успел, наверное...): Y> * It is not a UNION or UNION ALL Y> * It doesn't have GROUP BY, HAVING or any kind of aggregate functions Y> * It doesn't have ORDER BY ... LIMIT clause
В особо тяжелых случаях (как описано выше) ничего не мешает переписать запрос в случае если производительности не хватает. Реально тормозных и сложных запросов обычно в приложении не много, так что переписать несколько запросов не проблема. Тем более что примерно тем же самым приходится заниматься и на оракле. Ну да, с MySQL в этом смысле надо быть более внимательным и оптимизатору надо в рот подкладывать запрос в более разжеванном виде.
Здравствуйте, Mamut, Вы писали:
M>Когда говоришь, что MySQL подерживает ту или иную фичу, надо обязательно уточнять, для какого из двиков он эту фичу поддерживает.
Здравствуйте, agos, Вы писали:
A>Здравствуйте, Sheridan, Вы писали:
S>>Обана, а какже я его из исходников то в генте собираю? о0 S>>Ты чтото напутал. A>http://www.mysql.com/about/legal/licensing/oem/
А почитать ссылку?
OEMs, ISVs, VARs and other distributors that combine and distribute commercially licensed software with MySQL software and do not wish to distribute the source code for the commercially licensed software under version 2 of the GNU General Public License (the "GPL") must enter into a commercial license agreement with Sun.
То есть другими словами если ты продаешь MySQL в составе своего продукта. А теперь вопрос: можешь ли ты продавать, например, MSSQL в составе своего продукта?
Здравствуйте, mrTwister, Вы писали:
M>>Сложно сказать. Там ГПЛ достаточно мутна в этом отношении
T>Что мутного, SQL сервер — это отдельное приложение, связь с которым осуществляется по TCP. Чем он в этом смысле принципиально отличается от, скажем апача?
Есть небольшой подвох: например, JDBC коннектор для Java под лицензией GPL (раньше был под LPGL). Включая его в состав приложения попадаем под условия GPL.
Здравствуйте, mrTwister, Вы писали:
T> M>Когда говоришь, что MySQL подерживает ту или иную фичу, надо обязательно уточнять, для какого из двиков он эту фичу поддерживает.
T> Хорошо, для InnoDB, доволен?
Да. для InnoDB есть ACID. Но нет чего-то дргого. И т.п.
Здравствуйте, mrTwister, Вы писали:
T> M>Сложно сказать. Там ГПЛ достаточно мутна в этом отношении
T> Что мутного, SQL сервер — это отдельное приложение, связь с которым осуществляется по TCP. Чем он в этом смысле принципиально отличается от, скажем апача?
Скажем, если для сязи используется libmysqlclient (или как он там называется). Все, приплыли
Здравствуйте, mrTwister, Вы писали:
T>Здравствуйте, agos, Вы писали:
A>>Здравствуйте, Sheridan, Вы писали:
S>>>Обана, а какже я его из исходников то в генте собираю? о0 S>>>Ты чтото напутал. A>>http://www.mysql.com/about/legal/licensing/oem/
T>А почитать ссылку? T>
T>OEMs, ISVs, VARs and other distributors that combine and distribute commercially licensed software with MySQL software and do not wish to distribute the source code for the commercially licensed software under version 2 of the GNU General Public License (the "GPL") must enter into a commercial license agreement with Sun.
T>То есть другими словами если ты продаешь MySQL в составе своего продукта. А теперь вопрос: можешь ли ты продавать, например, MSSQL в составе своего продукта?
Практичеки да.
Партнеры MS могут продавать SQL Server в составе продукта, имея с него некоторый процент.
Здравствуйте, _d_m_, Вы писали:
_> d>> Твистер, а в мускуле есть comparable GUIDs, раз уж последовательностями обделили? _> AB>Есть простые UUID(), которые представляются строкой в UTF-8 _> Че-то какой-то гон. GUID — 16 байтное целое число, а здесь строки?
Ну да, их строковое представление длиной 36 символов (16 * 2 hex + 4 разделителя). Если сильно хочется, можно их UDF-ом конвертнуть бинарное представление.
T>OEMs, ISVs, VARs and other distributors that combine and distribute commercially licensed software with MySQL software and do not wish to distribute the source code for the commercially licensed software under version 2 of the GNU General Public License (the "GPL") must enter into a commercial license agreement with Sun.
T>То есть другими словами если ты продаешь MySQL в составе своего продукта. А теперь вопрос: можешь ли ты продавать, например, MSSQL в составе своего продукта?
Да, звучит несколько размыто.
Но там всего два вида лицензирования, и уж точно кто не создаёт opensource решения не могут попасть под FOSS Exception. Следовательно остаётся одна.
Если вам это действительно интересно — поищите в инете, народ звонил/письма писал в MySql AB уточняя этот вопрос.
После уточнения часть народа отворчачивалась от MySql
Здравствуйте, agos, Вы писали:
A>Да, звучит несколько размыто. A>Но там всего два вида лицензирования, и уж точно кто не создаёт opensource решения не могут попасть под FOSS Exception. Следовательно остаётся одна. A>Если вам это действительно интересно — поищите в инете, народ звонил/письма писал в MySql AB уточняя этот вопрос. A>После уточнения часть народа отворчачивалась от MySql
GPL он и в африке GPL. Весь Linux-world под этой лицензией работает и ничего.
Здравствуйте, Mamut, Вы писали:
M>Здравствуйте, mrTwister, Вы писали:
T>> M>Когда говоришь, что MySQL подерживает ту или иную фичу, надо обязательно уточнять, для какого из двиков он эту фичу поддерживает.
T>> Хорошо, для InnoDB, доволен?
M>Да. для InnoDB есть ACID. Но нет чего-то дргого. И т.п.
Стоп-стоп. Какой ACID? Если для DDL его нет. Тут уже упоминали .frm файлы.
Здравствуйте, mrTwister, Вы писали:
T>Здравствуйте, yuriylsh, Вы писали:
Y>>Меня не интересую some subqueries.
T>А что тебя интересует?
Y>>The subquery must satisfy these conditions (этого ты нагуглить не успел, наверное...): Y>> * It is not a UNION or UNION ALL Y>> * It doesn't have GROUP BY, HAVING or any kind of aggregate functions Y>> * It doesn't have ORDER BY ... LIMIT clause
T>В особо тяжелых случаях (как описано выше) ничего не мешает переписать запрос в случае если производительности не хватает. Реально тормозных и сложных запросов обычно в приложении не много, так что переписать несколько запросов не проблема.
В приложениях моя первая пага? Да. Или ютуб — скорее всего. А вот в нашем приложении запросы на несколько экранов — норма.
T>Тем более что примерно тем же самым приходится заниматься и на оракле. Ну да, с MySQL в этом смысле надо быть более внимательным и оптимизатору надо в рот подкладывать запрос в более разжеванном виде.
А нахрен тогда такой оптимизатор? Что есть он, что нет — получается без разницы. Но... для первой паги пойдет.
Здравствуйте, mrTwister, Вы писали:
T>То есть другими словами если ты продаешь MySQL в составе своего продукта. А теперь вопрос: можешь ли ты продавать, например, MSSQL в составе своего продукта?
Да. А в чем проблема? MS SQL бесплатен в версии Express. Если потребности клиента больше чем Express — пожалуйста: Standard (x64, Itanium), Enterprise (x64, Itanium). Но в этом случае MS SQL не прикидывается бесплатным — все по чеснаку.
Здравствуйте, Anton Batenev, Вы писали:
AB>Здравствуйте, _d_m_, Вы писали:
_>> d>> Твистер, а в мускуле есть comparable GUIDs, раз уж последовательностями обделили? _>> AB>Есть простые UUID(), которые представляются строкой в UTF-8 _>> Че-то какой-то гон. GUID — 16 байтное целое число, а здесь строки?
AB>Ну да, их строковое представление длиной 36 символов (16 * 2 hex + 4 разделителя). Если сильно хочется, можно их UDF-ом конвертнуть бинарное представление.
Значит нет там поддержки GUID-ов. Обычное МыСклевкое решение — через задницу. Я в MS SQL, .Net CLR UDF-ами могу хоть звезду с неба достать.
Здравствуйте, _d_m_, Вы писали:
_>>> d>> Твистер, а в мускуле есть comparable GUIDs, раз уж последовательностями обделили? _>>> AB>Есть простые UUID(), которые представляются строкой в UTF-8 _>>> Че-то какой-то гон. GUID — 16 байтное целое число, а здесь строки?
AB>>Ну да, их строковое представление длиной 36 символов (16 * 2 hex + 4 разделителя). Если сильно хочется, можно их UDF-ом конвертнуть бинарное представление.
___>Значит нет там поддержки GUID-ов. Обычное МыСклевкое решение — через задницу. Я в MS SQL, .Net CLR UDF-ами могу хоть звезду с неба достать.
Не говоря уж об известной проблеме фрагментации индекса, построенного по GUID`ам (собственно почему и предумали sequential GUID`ы в MS SQL Server)...
Здравствуйте, _d_m_, Вы писали:
___>В приложениях моя первая пага?
Ну да, ну да. Google, Amazon, Flickr, Wikipedia работают на MySQL. Дак может все дело не в сложности приложения, а в кривых руках разработчика? Если руки кривые, то никакой оракл это не исправит — это диагноз.
___>А вот в нашем приложении запросы на несколько экранов — норма.
Какая разница на сколько экранов запрос?
T>>Тем более что примерно тем же самым приходится заниматься и на оракле. Ну да, с MySQL в этом смысле надо быть более внимательным и оптимизатору надо в рот подкладывать запрос в более разжеванном виде.
___>А нахрен тогда такой оптимизатор? Что есть он, что нет — получается без разницы.
Еще раз по буквам: примерно тем же самым приходится заниматься и на оракле.
Здравствуйте, criosray, Вы писали:
AB>>>Ну да, их строковое представление длиной 36 символов (16 * 2 hex + 4 разделителя). Если сильно хочется, можно их UDF-ом конвертнуть бинарное представление.
___>>Значит нет там поддержки GUID-ов. Обычное МыСклевкое решение — через задницу. Я в MS SQL, .Net CLR UDF-ами могу хоть звезду с неба достать.
C>Не говоря уж об известной проблеме фрагментации индекса, построенного по GUID`ам (собственно почему и предумали sequential GUID`ы в MS SQL Server)...
Нет никакой проблемы фрагментации. Просто при массовой вставке рандомных значений будет подыматься много страниц с диска, в случае же монотоного возрастания потребуется подымать значительно меньшее кол-во страниц.
Решение на строковых представлениях GUID-ов абсолютно в этом плане не отличается от бинарных GUID-ов.
Здравствуйте, mrTwister, Вы писали:
T>Здравствуйте, _d_m_, Вы писали:
___>>В приложениях моя первая пага?
T>Ну да, ну да. Google, Amazon, Flickr, Wikipedia работают на MySQL. Дак может все дело не в сложности приложения, а в кривых руках разработчика? Если руки кривые, то никакой оракл это не исправит — это диагноз.
___>>А вот в нашем приложении запросы на несколько экранов — норма.
T>Какая разница на сколько экранов запрос?
Ну это какбэ характеризует сложность запроса и уровень исполнения оптимизатора, чтобы он выполнять свою часть работы.
T>>>Тем более что примерно тем же самым приходится заниматься и на оракле. Ну да, с MySQL в этом смысле надо быть более внимательным и оптимизатору надо в рот подкладывать запрос в более разжеванном виде.
___>>А нахрен тогда такой оптимизатор? Что есть он, что нет — получается без разницы. T>Еще раз по буквам: примерно тем же самым приходится заниматься и на оракле.
Не знаю как на оракле, но на мс с-ку-эль мне надо только немного подтюнить запрос если он дает просадку на реальных данных.
Здравствуйте, _d_m_, Вы писали:
C>>Не говоря уж об известной проблеме фрагментации индекса, построенного по GUID`ам (собственно почему и предумали sequential GUID`ы в MS SQL Server)...
___>Нет никакой проблемы фрагментации. Просто при массовой вставке рандомных значений будет подыматься много страниц с диска, в случае же монотоного возрастания потребуется подымать значительно меньшее кол-во страниц.
_> T>> M>Когда говоришь, что MySQL подерживает ту или иную фичу, надо обязательно уточнять, для какого из двиков он эту фичу поддерживает.
_> T>> Хорошо, для InnoDB, доволен?
_> M>Да. для InnoDB есть ACID. Но нет чего-то дргого. И т.п.
_> Стоп-стоп. Какой ACID? Если для DDL его нет. Тут уже упоминали .frm файлы.
Ну, он в теории есть. По идее frm ожно восстановить по transaction-логам. Но это — в теории
Здравствуйте, criosray, Вы писали:
C>Здравствуйте, _d_m_, Вы писали:
C>>>Не говоря уж об известной проблеме фрагментации индекса, построенного по GUID`ам (собственно почему и предумали sequential GUID`ы в MS SQL Server)...
___>>Нет никакой проблемы фрагментации. Просто при массовой вставке рандомных значений будет подыматься много страниц с диска, в случае же монотоного возрастания потребуется подымать значительно меньшее кол-во страниц.
C>Ну конечно же есть проблема фрагментации .
Ладно есть, только этот MVP почему-то забыл про такой параметр индекса как fillfactor — для таких таблиц надо ставить 85-90% или использовать секвеншл гуид (что не всегда возможно). Кстати, индексы прекрасно дефрагментируются если чо.
Тем не менее повторяю решение в MySQL плохо — нет там ни гуидов, ни секвеншл гуидов, а только раздутые 36 байтные строки, которые фрагментируют индекс в ввиду немонотонного возрастания.
_> ___>>А нахрен тогда такой оптимизатор? Что есть он, что нет — получается без разницы.
_> T>Еще раз по буквам: примерно тем же самым приходится заниматься и на оракле.
_> Не знаю как на оракле, но на мс с-ку-эль мне надо только немного подтюнить запрос если он дает просадку на реальных данных.
Причем в Enterprise tudio есть гниальная фича «показать план запроса», оторый подскажет, на каких именно данных просаживается запрос. Обычно бывает достаточно прикрутить забытый индекс — и вуаля.Для MySQL'я таких тлзов просто не существует в природе, насколько я знаю
Здравствуйте, Mamut, Вы писали:
_>> ___>>А нахрен тогда такой оптимизатор? Что есть он, что нет — получается без разницы.
_>> T>Еще раз по буквам: примерно тем же самым приходится заниматься и на оракле.
_>> Не знаю как на оракле, но на мс с-ку-эль мне надо только немного подтюнить запрос если он дает просадку на реальных данных.
M>Причем в Enterprise tudio есть гниальная фича «показать план запроса», оторый подскажет, на каких именно данных просаживается запрос. Обычно бывает достаточно прикрутить забытый индекс — и вуаля.Для MySQL'я таких тлзов просто не существует в природе, насколько я знаю
Поправочка: MS SQL Server Management Studio. И таки да даже в бесплатной Express редакции.
Здравствуйте, Mamut, Вы писали:
M>Причем в Enterprise tudio есть гниальная фича «показать план запроса», оторый подскажет, на каких именно данных просаживается запрос. Обычно бывает достаточно прикрутить забытый индекс — и вуаля.
Здравствуйте, _d_m_, Вы писали:
___>Тем не менее повторяю решение в MySQL плохо — нет там ни гуидов, ни секвеншл гуидов, а только раздутые 36 байтные строки, которые фрагментируют индекс в ввиду немонотонного возрастания.
АФАИК UUID в MySQL дает именно sequential значения.
Здравствуйте, mrTwister, Вы писали:
T>Здравствуйте, _d_m_, Вы писали:
___>>Тем не менее повторяю решение в MySQL плохо — нет там ни гуидов, ни секвеншл гуидов, а только раздутые 36 байтные строки, которые фрагментируют индекс в ввиду немонотонного возрастания.
T>АФАИК UUID в MySQL дает именно sequential значения.
Даже если так — и что? GUID тем и удобен, что его можно генерировать на клиенте. А вот проблема ключа длиной 36 vs 16 — это риал.
А проблема фрагментации индексов преувеличена, я бы даже не называл это проблемой. Во всяком случае в MS SQL.
Здравствуйте, _d_m_, Вы писали:
_> Значит нет там поддержки GUID-ов. Обычное МыСклевкое решение — через задницу. Я в MS SQL, .Net CLR UDF-ами могу хоть звезду с неба достать.
Если говорить непосредственно о типе поля GUID в MSSQL, то да, аналога нет. Если говорить о наличии уникальной (глобально) возрастающей последовательности, то есть. Как ее применять и применять ли (поскольку "проблем" с репликацией у MySQL нет при любом типе PK) — вопрос уже другой.
З.Ы. Но если кому-то совсем-совсем невмоготу и хочется именно типа GUID, то исходники открыты
___>А проблема фрагментации индексов преувеличена, я бы даже не называл это проблемой. Во всяком случае в MS SQL.
Она не преувеличена. Из-за нее мы вынуждены перестраивать индексы частями через каждые двое суток. Всего 10-15 дней и фрагментация порядка 90%, что неприемлимо.
Использование sequential GUID`ов конкретно на этих PK неприемлимо.
Здравствуйте, _d_m_, Вы писали:
AB>>З.Ы. Но если кому-то совсем-совсем невмоготу и хочется именно типа GUID, то исходники открыты
___>Да-да там типа юникс вэй и прочее. А новые версии и апдейты как накатывать?
Наверно подразумевается, что Вы отправите патч, он будет утвержден, и накатан на основную ветку...
Здравствуйте, _d_m_, Вы писали:
___>Даже если так — и что? GUID тем и удобен, что его можно генерировать на клиенте. А вот проблема ключа длиной 36 vs 16 — это риал.
Ничего не мешает хранить 16 байт в бинари формате.
AB>Если говорить непосредственно о типе поля GUID в MSSQL, то да, аналога нет. Если говорить о наличии уникальной (глобально) возрастающей последовательности, то есть. Как ее применять и применять ли (поскольку "проблем" с репликацией у MySQL нет при любом типе PK) — вопрос уже другой.
Точно. Особенно заметно проблем нету, если надо слить базы с других серверов, а в качестве PK использованы автоинкременты.
Здравствуйте, mrTwister, Вы писали:
___>>Даже если так — и что? GUID тем и удобен, что его можно генерировать на клиенте. А вот проблема ключа длиной 36 vs 16 — это риал.
T>Ничего не мешает хранить 16 байт в бинари формате.
Здравствуйте, criosray, Вы писали:
C>Здравствуйте, _d_m_, Вы писали:
___>>А проблема фрагментации индексов преувеличена, я бы даже не называл это проблемой. Во всяком случае в MS SQL.
C>Она не преувеличена. Из-за нее мы вынуждены перестраивать индексы частями через каждые двое суток. Всего 10-15 дней и фрагментация порядка 90%, что неприемлимо.
Здравствуйте, Anton Batenev, Вы писали:
AB>Здравствуйте, _d_m_, Вы писали:
_>> Значит нет там поддержки GUID-ов. Обычное МыСклевкое решение — через задницу. Я в MS SQL, .Net CLR UDF-ами могу хоть звезду с неба достать.
AB>Если говорить непосредственно о типе поля GUID в MSSQL, то да, аналога нет. Если говорить о наличии уникальной (глобально) возрастающей последовательности, то есть. Как ее применять и применять ли (поскольку "проблем" с репликацией у MySQL нет при любом типе PK) — вопрос уже другой.
Это физически невозможно. И как же решили великие создатели MySQL эту проблему?
Здравствуйте, Mamut, Вы писали:
M> Причем в Enterprise tudio есть гниальная фича «показать план запроса», оторый подскажет, на каких именно данных просаживается запрос. Обычно бывает достаточно прикрутить забытый индекс — и вуаля.Для MySQL'я таких тлзов просто не существует в природе, насколько я знаю
EXPLAIN SELECT ...
SET profiling = 1;
SELECT ...;
SELECT ...;
SHOW PROFILES;
SHOW PROFILE CPU FOR QUERY 2;
Здравствуйте, _d_m_, Вы писали:
_> Даже если так — и что? GUID тем и удобен, что его можно генерировать на клиенте.
Так и здесь можно.
_> А вот проблема ключа длиной 36 vs 16 — это риал.
Как уже говорилось, если хочешь экономить место, никто не запрещает его конвертировать в бинарное представление и заносить в BINARY(16) поле, по которому построить такой же индекс.
Здравствуйте, _d_m_, Вы писали:
AB>>З.Ы. Но если кому-то совсем-совсем невмоготу и хочется именно типа GUID, то исходники открыты ___>Да-да там типа юникс вэй и прочее. А новые версии и апдейты как накатывать?
Как обычно — сливается тэг, накатывается патч, компилируется, при желании оборачивается в пакет и раскатывается по серверам. Для тех, кто возьмется лезть в исходники, думаю, все остальное проблем не составляет.
Здравствуйте, Mamut, Вы писали:
_>> Стоп-стоп. Какой ACID? Если для DDL его нет. Тут уже упоминали .frm файлы. M>Ну, он в теории есть. По идее frm ожно восстановить по transaction-логам. Но это — в теории
Не знаю, как щас, но год-полтора назад ситуация была следующая:
1) запускаем скрипт, в единой транзакции обновляющий структуру базы;
2) скрипт выбрасывает исключение;
3) транзакция откатывается, включая изменения метаданных, хранимых и используемых innodb, но НЕ включая изменения в frm-файлах, используемых ядром мускуля (в т.ч. планировщиком ЕМНИП);
4) все последующие запросы к таблицам, метаданные которых рассогласованы, падают с внутренней ошибкой;
5) делаем /etc/init.d/mysqld stop;
6) ручками или скриптиком восстанавливаем frm-файлы (в документации мускуля было howto);
7) делаем /etc/init.d/mysqld start;
8) не забываем повторять про себя "во б#$% п#$#$# е#$#$#$ е#@#@ их в с#$#%# что б вы м#$^@ п#$#$%#$# cо своим е#$&@# муcкулем!" в течение всего процесса, начиная с пункта 4 (можно раньше).
Здравствуйте, dimgel, Вы писали:
D>Не знаю, как щас, но год-полтора назад ситуация была следующая: D>1) запускаем скрипт, в единой транзакции обновляющий структуру базы; D>2) скрипт выбрасывает исключение; D>3) транзакция откатывается, включая изменения метаданных, хранимых и используемых innodb, но НЕ включая изменения в frm-файлах, используемых ядром мускуля (в т.ч. планировщиком ЕМНИП); D>4) все последующие запросы к таблицам, метаданные которых рассогласованы, падают с внутренней ошибкой; D>5) делаем /etc/init.d/mysqld stop; D>6) ручками или скриптиком восстанавливаем frm-файлы (в документации мускуля было howto); D>7) делаем /etc/init.d/mysqld start; D>8) не забываем повторять про себя "во б#$% п#$#$# е#$#$#$ е#@#@ их в с#$#%# что б вы м#$^@ п#$#$%#$# cо своим е#$&@# муcкулем!" в течение всего процесса, начиная с пункта 4 (можно раньше).
А всего то надо было сделать бекап перед деплойментом. Из всего этого следует только то, что деплоймент, изменяющий структуру базы данных на MySQL требует обязательный down-time на время прогона скрипта (и/или создния и восстановления бекапа). Но даже на оракле и скл сервере, все деплойменты которые я проводил/имел отношение/наблюдал проходили с down-time'ом на время бекапа (когда было возможно), прогона скрипта (без транзакций) и первичного тестирования. Так что в данном случае не было бы никакой разницы.
Здравствуйте, mrTwister, Вы писали:
T>А всего то надо было сделать бекап перед деплойментом.
Вот, ты сам и подтвердил, что ACID-ом тут и не пахнет, нужно вручную. Предлагаешь два раза двухгиговую базу лопатить — один раз бэкап, второй раз внутри транзакции. Гы, а третий раз — восстановление из бэкапа. Тот же PostgreSQL, кстати, прекрасненько откатывает транзакции с DDL. Наверное потому что в нём нет этого идиотского бардака со storage engines и задвоений метаданных.
T>Из всего этого следует только то, что деплоймент, изменяющий структуру базы данных на MySQL требует обязательный down-time на время прогона скрипта (и/или создния и восстановления бекапа).
Из сказанного это никак не следует, т.к. приведённый мной сценарий рушил метаданные независимо от того, работал с базой кто-нибудь ещё или нет.
И если уж на то пошло, условие down-time выполнялось автоматически, т.к. обновлялка работала при инициализации servlet context.
T>Но даже на оракле и скл сервере, все деплойменты которые я проводил/имел отношение/наблюдал проходили с down-time'ом на время бекапа (когда было возможно), прогона скрипта (без транзакций) и первичного тестирования. Так что в данном случае не было бы никакой разницы.
Здравствуйте, Sheridan, Вы писали:
>> ИМХО, просто предсмертная агония. Было уже такое, "догоним и перегоним" (по количеству, а качество по-барабану). S>Да скорей бы уже.
Эту реплику, Максимко, должен был произнести я. Тебя ж не заставляют под мускуль сайты писать? Так что тебе должно быть пофиг.
dimgel wrote:
> S>Да скорей бы уже. > Эту реплику, Максимко, должен был произнести я. Тебя ж не заставляют под мускуль сайты писать?
Но могут заставить
> Так что тебе должно быть пофиг.
Мне не пофиг
Мне же всех вас и тебя в частности жалко, ага
Здравствуйте, mrTwister, Вы писали:
T>А всего то надо было сделать бекап перед деплойментом.
На нормальных серверах с нормальными транзакциями — нет необходимости.
T>Из всего этого следует только то, что деплоймент, изменяющий структуру базы данных на MySQL требует обязательный down-time на время прогона скрипта (и/или создния и восстановления бекапа).
На нормальных серверах не нужен никакой даунтайм (за редким исключением), и (ты удивишься) даже бэкап там делается на горячую без остановки сервера и отключения клиентов.
T>Но даже на оракле и скл сервере, все деплойменты которые я проводил/имел отношение/наблюдал проходили с down-time'ом на время бекапа (когда было возможно), прогона скрипта (без транзакций) и первичного тестирования. Так что в данном случае не было бы никакой разницы.
Ерунда какая-то — не нужен никакой даунтайм для с-ку-эль сервера. Ты не умеешь его правильно готовить. За оракл — не скажу, с ним не работаю.
Здравствуйте, Anton Batenev, Вы писали:
AB>Здравствуйте, Mamut, Вы писали:
M>> Причем в Enterprise tudio есть гниальная фича «показать план запроса», оторый подскажет, на каких именно данных просаживается запрос. Обычно бывает достаточно прикрутить забытый индекс — и вуаля.Для MySQL'я таких тлзов просто не существует в природе, насколько я знаю
AB>
EXPLAIN SELECT ...
AB>
AB>SET profiling = 1;
AB>SELECT ...;
AB>SELECT ...;
AB>SHOW PROFILES;
AB>SHOW PROFILE CPU FOR QUERY 2;
AB>
Спасибо, посмеялся.
Во первых, речь шла про план запроса. Типа такого http://files.rsdn.ru/21534/PlanPutina2.GIF , там еще мышкой наводишь например на индекс скан и смотришь что, где и почему — число строк, размер строки, io cost и многое.
Во вторых, T-SQL-е есть и подобное: set statistics io, set statistics time, show plan text и прочее.
Здравствуйте, Anton Batenev, Вы писали:
_>> А вот проблема ключа длиной 36 vs 16 — это риал.
AB>Как уже говорилось, если хочешь экономить место, никто не запрещает его конвертировать в бинарное представление и заносить в BINARY(16) поле, по которому построить такой же индекс.
Да не проблема — я в MS SQL тоже легко могу использовать binary(16), и записывать, и сравнивать, и индексы строить. И?
Здравствуйте, Anton Batenev, Вы писали:
AB>Здравствуйте, _d_m_, Вы писали:
_>> Это физически невозможно. И как же решили великие создатели MySQL эту проблему?
AB>Как-то так. Решение без изысков (и не без недостатков), но работает и успешно используется.
Задаю вопрос по другому. Есть таблица с автоинкрементным полем. Эта таблица существует в двух БД и настроена двухсторонняя репликация этой таблицы, как быть с автоинкрементынм полем? Сразу говорю identity seed — есть чмо и отстой, поэтому не будем о этом. Итак, как?
Здравствуйте, Mamut, Вы писали: M>Причем в Enterprise tudio есть гниальная фича «показать план запроса», оторый подскажет, на каких именно данных просаживается запрос. Обычно бывает достаточно прикрутить забытый индекс — и вуаля.Для MySQL'я таких тлзов просто не существует в природе, насколько я знаю
Почему — есть. Мускульный explain выглядит, конечно, поплоше Query Plan-а в студии, но вполне пригоден для анализа.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, dimgel, Вы писали:
D>Вот, ты сам и подтвердил, что ACID-ом тут и не пахнет, нужно вручную.
Скажем так, ACID в случае с DDL не полностью в том смысле, что для отката может понадобится дополнительно пара приседаний.
D>Из сказанного это никак не следует, т.к. приведённый мной сценарий рушил метаданные независимо от того, работал с базой кто-нибудь ещё или нет. D>И если уж на то пошло, условие down-time выполнялось автоматически, т.к. обновлялка работала при инициализации servlet context.
Если с базой никто кроме тебя во время деплоймента не работает, то тогда зачем тебе транзакция?
T>>Но даже на оракле и скл сервере, все деплойменты которые я проводил/имел отношение/наблюдал проходили с down-time'ом на время бекапа (когда было возможно), прогона скрипта (без транзакций) и первичного тестирования. Так что в данном случае не было бы никакой разницы.
D>Это вообще о чём и к чему?
Это вообще к тому, что возможность проводить большой деплоймент, для которого требуется отдельная транзакция по рабочей базе хоть и полезна, но на практике редко используемая.
Здравствуйте, _d_m_, Вы писали:
___>Здравствуйте, mrTwister, Вы писали:
T>>А всего то надо было сделать бекап перед деплойментом.
___>На нормальных серверах с нормальными транзакциями — нет необходимости.
Дело не в нормальности сервера, а в нормальности процессов и в configuration management'е. Даже после удачно проведенного деплоймента приложение может перестать работать (1000 причин тому) и придется откатиться к предыдущей рабочей версии. Как тебе в этом случае транзакции помогут?
Здравствуйте, _d_m_, Вы писали:
___>Спасибо, посмеялся. ___>Во первых, речь шла про план запроса. Типа такого http://files.rsdn.ru/21534/PlanPutina2.GIF , там еще мышкой наводишь например на индекс скан и смотришь что, где и почему — число строк, размер строки, io cost и многое.
Тебе шашечки, или ехать? Или ты информацию только в картинках воспринимаешь?
Здравствуйте, _d_m_, Вы писали:
___>Да не проблема — я в MS SQL тоже легко могу использовать binary(16), и записывать, и сравнивать, и индексы строить. И?
Здравствуйте, _d_m_, Вы писали:
___>Задаю вопрос по другому. Есть таблица с автоинкрементным полем. Эта таблица существует в двух БД и настроена двухсторонняя репликация этой таблицы, как быть с автоинкрементынм полем? Сразу говорю identity seed — есть чмо и отстой, поэтому не будем о этом. Итак, как?
Здравствуйте, _d_m_, Вы писали:
___>и (ты удивишься) даже бэкап там делается на горячую без остановки сервера и отключения клиентов.
Это ты к чему? Хочешь сказать, что MySQL не может делать бекап без остановки сервера и отключения клиентов?
Здравствуйте, mrTwister, Вы писали:
T>Здравствуйте, _d_m_, Вы писали:
___>>и (ты удивишься) даже бэкап там делается на горячую без остановки сервера и отключения клиентов. T>Это ты к чему? Хочешь сказать, что MySQL не может делать бекап без остановки сервера и отключения клиентов?
Чьи слова?
Из всего этого следует только то, что деплоймент, изменяющий структуру базы данных на MySQL требует обязательный down-time на время прогона скрипта (и/или создния и восстановления бекапа).
Здравствуйте, mrTwister, Вы писали:
T>Здравствуйте, dimgel, Вы писали:
D>>Вот, ты сам и подтвердил, что ACID-ом тут и не пахнет, нужно вручную. T>Скажем так, ACID в случае с DDL не полностью в том смысле, что для отката может понадобится дополнительно пара приседаний.
Да понятно. Для бешенной собаки 30 верст не крюк. Да что там фанату MySQL пара приседаний... со штангой... 120 кг...
D>>Из сказанного это никак не следует, т.к. приведённый мной сценарий рушил метаданные независимо от того, работал с базой кто-нибудь ещё или нет. D>>И если уж на то пошло, условие down-time выполнялось автоматически, т.к. обновлялка работала при инициализации servlet context. T>Если с базой никто кроме тебя во время деплоймента не работает, то тогда зачем тебе транзакция?
Так мы дойдем что они вобщем и не нужны. Затем, что если апдейт версии завалится какой-нибудь ошибкой, БД и ее структура останется как до начала апдейта.
T>>>Но даже на оракле и скл сервере, все деплойменты которые я проводил/имел отношение/наблюдал проходили с down-time'ом на время бекапа (когда было возможно), прогона скрипта (без транзакций) и первичного тестирования. Так что в данном случае не было бы никакой разницы.
D>>Это вообще о чём и к чему?
T>Это вообще к тому, что возможность проводить большой деплоймент, для которого требуется отдельная транзакция по рабочей базе хоть и полезна, но на практике редко используемая.
Да-да-да. Если у вас эта возможность не используется, то она сразу переходит в раздел редко используемых.
Здравствуйте, mrTwister, Вы писали:
T>Здравствуйте, _d_m_, Вы писали:
___>>Спасибо, посмеялся. ___>>Во первых, речь шла про план запроса. Типа такого http://files.rsdn.ru/21534/PlanPutina2.GIF , там еще мышкой наводишь например на индекс скан и смотришь что, где и почему — число строк, размер строки, io cost и многое. T>Тебе шашечки, или ехать? Или ты информацию только в картинках воспринимаешь?
Видишь ли, ехать тоже по разному можно. Можно мягко с комфортом и кондишеном, а можно кашлять и трястись в кузове самосвала по пыльной гравийке.
Здравствуйте, _d_m_, Вы писали:
___>Чьи слова? ___>
___>Из всего этого следует только то, что деплоймент, изменяющий структуру базы данных на MySQL требует обязательный down-time на время прогона скрипта (и/или создния и восстановления бекапа).
Это было не о возможности сделать бекап на работающей базе, а об откате к предыдущей рабочей версии в случае каких-либо проблем. down-time нужен чтобы данные не потерялись. В нормальных компаниях, в которых налажены процессы, возможность такого отката обязательно обеспечивается независимо от крутости сервера баз данных. Без обеспечения отката никто не позволит вообще деплоймент проводить.
Здравствуйте, mrTwister, Вы писали:
T>Здравствуйте, _d_m_, Вы писали:
___>>Да не проблема — я в MS SQL тоже легко могу использовать binary(16), и записывать, и сравнивать, и индексы строить. И?
T>Что и?
Да то, что речь идет все-таки о гуидах, а не их эмуляции в binary.
Здравствуйте, mrTwister, Вы писали:
T>Здравствуйте, _d_m_, Вы писали:
___>>Задаю вопрос по другому. Есть таблица с автоинкрементным полем. Эта таблица существует в двух БД и настроена двухсторонняя репликация этой таблицы, как быть с автоинкрементынм полем? Сразу говорю identity seed — есть чмо и отстой, поэтому не будем о этом. Итак, как?
T>Не использовать двустороннюю репликацию.
Здравствуйте, _d_m_, Вы писали:
___>>>Спасибо, посмеялся. ___>>>Во первых, речь шла про план запроса. Типа такого http://files.rsdn.ru/21534/PlanPutina2.GIF , там еще мышкой наводишь например на индекс скан и смотришь что, где и почему — число строк, размер строки, io cost и многое. T>>Тебе шашечки, или ехать? Или ты информацию только в картинках воспринимаешь?
___>Видишь ли, ехать тоже по разному можно. Можно мягко с комфортом и кондишеном, а можно кашлять и трястись в кузове самосвала по пыльной гравийке.
+1
К тому же если надо анализировать сотни запросов, то инструментарий однозначно решает.
Здравствуйте, mrTwister, Вы писали: T>Скажем так, ACID в случае с DDL не полностью в том смысле, что для отката может понадобится дополнительно пара приседаний.
Это всё равно, что быть не полностью беременной. ACID означает определённые гарантии. Если их нет — то это не ACID. "Частичного ACID", как и "частичной потокобезопасности", "частичной иммутабельности" и прочего в природе не существует.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, _d_m_, Вы писали:
___>Видишь ли, ехать тоже по разному можно. Можно мягко с комфортом и кондишеном, а можно кашлять и трястись в кузове самосвала по пыльной гравийке.
Ну не все же на такси ездят, некоторые и на метро.
Здравствуйте, mrTwister, Вы писали:
T>Здравствуйте, _d_m_, Вы писали:
___>>Видишь ли, ехать тоже по разному можно. Можно мягко с комфортом и кондишеном, а можно кашлять и трястись в кузове самосвала по пыльной гравийке.
T>Ну не все же на такси ездят, некоторые и на метро.
На метро в кузове самосвала? Оригинально. Так вам же и предлагают с комфортом ехать, а вы: нет спасибо — в самосвале лучше.
Здравствуйте, mrTwister, Вы писали:
T>Это было не о возможности сделать бекап на работающей базе, а об откате к предыдущей рабочей версии в случае каких-либо проблем. down-time нужен чтобы данные не потерялись.
Совершенно непонятно, зачем нужен даунтайм для обеспечения нетеряемости данных. Для нетеряемости данных, вообще-то, достаточно бэкапа.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, mrTwister, Вы писали:
T>Здравствуйте, _d_m_, Вы писали:
___>>Да то, что речь идет все-таки о гуидах, а не их эмуляции в binary.
T>И какие проблемы с bibary?
С чем, чем? Интересная штука этот MySQL И типы данных у него интересные.
Ладно, оставим GUID-ы в покое. Худо-бедно, но можно и так.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, mrTwister, Вы писали:
T>>Это было не о возможности сделать бекап на работающей базе, а об откате к предыдущей рабочей версии в случае каких-либо проблем. down-time нужен чтобы данные не потерялись. S>Совершенно непонятно, зачем нужен даунтайм для обеспечения нетеряемости данных. Для нетеряемости данных, вообще-то, достаточно бэкапа.
Сначала ты сделал бекап, после этого юзеры нафигачили в базу кучу данных, потом ты понимаешь, что надо откатываться. Что делать будешь?
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, mrTwister, Вы писали:
T>>Это было не о возможности сделать бекап на работающей базе, а об откате к предыдущей рабочей версии в случае каких-либо проблем. down-time нужен чтобы данные не потерялись. S>Совершенно непонятно, зачем нужен даунтайм для обеспечения нетеряемости данных. Для нетеряемости данных, вообще-то, достаточно бэкапа.
Я так понял:
1. Делают бэкап;
2. Накатывают апдейт;
3. Ошибка, надо восстановить данные из бэкапа п.1.
4. Восстановление из бэкапа.
5. База в состоянии на момент времени п.1.
И если во время этого работают юзеры, то вся их работа будет потеряна.
Здравствуйте, _d_m_, Вы писали:
___>На метро в кузове самосвала? Оригинально. Так вам же и предлагают с комфортом ехать, а вы: нет спасибо — в самосвале лучше.
Мне надо роту солдат перевезти, а мне такси предлагают. Говорят, что там комфортнее. Может и комфортнее (я с этим, кстати и не спорю), только где же денег столько взять? Вот конкретный пример моей конторы: сделали систему на MSSQL, посчитали стоимость лицензии (несколько мощных многопроцессорных серверов в разных частях мира) офигели и перешли на MySQL. Полет нормальный.
Здравствуйте, mrTwister, Вы писали:
T>Здравствуйте, _d_m_, Вы писали:
___>>На метро в кузове самосвала? Оригинально. Так вам же и предлагают с комфортом ехать, а вы: нет спасибо — в самосвале лучше.
T>Мне надо роту солдат перевезти, а мне такси предлагают. Говорят, что там комфортнее. Может и комфортнее (я с этим, кстати и не спорю), только где же денег столько взять? Вот конкретный пример моей конторы: сделали систему на MSSQL, посчитали стоимость лицензии (несколько мощных многопроцессорных серверов в разных частях мира) офигели и перешли на MySQL. Полет нормальный.
Выделенное может стоить затрат гораздо больших, чем цена лицензий.
Здравствуйте, mrTwister, Вы писали: T>Сначала ты сделал бекап, после этого юзеры нафигачили в базу кучу данных, потом ты понимаешь, что надо откатываться. Что делать будешь?
Откатываться. А что, есть какие-то варианты?
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
T>>Мне надо роту солдат перевезти, а мне такси предлагают. Говорят, что там комфортнее. Может и комфортнее (я с этим, кстати и не спорю), только где же денег столько взять? Вот конкретный пример моей конторы: сделали систему на MSSQL, посчитали стоимость лицензии (несколько мощных многопроцессорных серверов в разных частях мира) офигели и перешли на MySQL. Полет нормальный.
G>Выделенное может стоить затрат гораздо больших, чем цена лицензий.
Видимо не в их случае. Странно другое — что они не посчитали стоимость ДО начала разработки и не учли в бюджете.
T>>Сначала ты сделал бекап, после этого юзеры нафигачили в базу кучу данных, потом ты понимаешь, что надо откатываться. Что делать будешь? S>Откатываться. А что, есть какие-то варианты?
Тут он прав — нужен даунтайм.
Отключаем внешние подключения, бэкапимся, производим все необходимые процедуры, тестируем, обнаруживаем проблему, пытаемся исправить, видим, что исправить быстро не выйдет, откатываемся, пускаем внешние подключения...
Здравствуйте, _d_m_, Вы писали:
_> ___>>Да не проблема — я в MS SQL тоже легко могу использовать binary(16), и записывать, и сравнивать, и индексы строить. И? _> T>Что и? _> Да то, что речь идет все-таки о гуидах, а не их эмуляции в binary.
Что-то я не совсем тебя понимаю. Если у тебя сейчас стоит задача найти фитчу, которую не поддерживает MySQL, но поддерживает MSSQL, после чего сказать: "Посмотрите какое убожество у него нет даже <...>", то можно же сделать проще — запроси, например, materialized views.
Здравствуйте, _d_m_, Вы писали:
_> Задаю вопрос по другому. Есть таблица с автоинкрементным полем. Эта таблица существует в двух БД и настроена двухсторонняя репликация этой таблицы, как быть с автоинкрементынм полем? Сразу говорю identity seed — есть чмо и отстой, поэтому не будем о этом. Итак, как?
Переформулируй задачу в терминах MySQL, чтобы мы все точно понимали, что у тебя есть, чего ты хочешь достичь и что ты будешь для этого делать.
Здравствуйте, criosray, Вы писали:
C>Тут он прав — нужен даунтайм. C>Отключаем внешние подключения, бэкапимся, производим все необходимые процедуры, тестируем, обнаруживаем проблему, пытаемся исправить, видим, что исправить быстро не выйдет, откатываемся, пускаем внешние подключения...
Ок, ясно.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, mrTwister, Вы писали:
T> M>Причем в Enterprise tudio есть гниальная фича «показать план запроса», оторый подскажет, на каких именно данных просаживается запрос. Обычно бывает достаточно прикрутить забытый индекс — и вуаля.
T> Все тоже самое.
T> M>Для MySQL'я таких тлзов просто не существует в природе, насколько я знаю
T> http://dev.mysql.com/doc/refman/5.1/en/explain.html
Здравствуйте, criosray, Вы писали:
c> ___>>Даже если так — и что? GUID тем и удобен, что его можно генерировать на клиенте. А вот проблема ключа длиной 36 vs 16 — это риал.
c> T>Ничего не мешает хранить 16 байт в бинари формате.
c> Точно. c> http://www.mysqlperformanceblog.com/2007/03/13/to-uuid-or-not-to-uuid/
О, спасибо. ЕНще один пример того, какая жопа может быть в мускуле только из-за движков.
Здравствуйте, _d_m_, Вы писали:
_> AB>Подробнее здесь и здесь.
_> Спасибо, посмеялся. _> Во первых, речь шла про план запроса. Типа такого http://files.rsdn.ru/21534/PlanPutina2.GIF , там еще мышкой наводишь например на индекс скан и смотришь что, где и почему — число строк, размер строки, io cost и многое.
Эм. Если тебе нужны рисунки, где можно поводить мышкой, то да, таких я не встречал (хотя, возможно, они есть). Технических преград к тому, чтобы они появились нет — преобразование из текстового вывода в графику вполне под силу. Вероятно, тут работает другой фактор — а кому это нужно, если большинство серверов тебя просто не пустят к себе по порту 3306 с клиентской машины и остается путь или через консоль (что предпочтительнее) или через всякие phpMyAdmin (которые для "бедных").
Если же ты имел ввиду какую-то метрику. То назови ее (можно еще дать тестовую схему, тестовый набор данных и тестовый запрос, который требуется разобрать) — покурим, посмотрим что может рассказать нам MySQL.
Здравствуйте, Anton Batenev, Вы писали:
AB>Что-то я не совсем тебя понимаю. Если у тебя сейчас стоит задача найти фитчу, которую не поддерживает MySQL, но поддерживает MSSQL, после чего сказать: "Посмотрите какое убожество у него нет даже <...>", то можно же сделать проще — запроси, например, materialized views.
Даже не заикался — т.к. понятно, что нет. Как и много другого. Просто человек заявил — что мол поддерживает GUID-ы, а как выяснилось нет. И постоянно приводит сравнения с MS SQL и Oracle, причем некорректные. Хотя MySQL-ю до нормальных СУБД, как свинье до Луны.
Здравствуйте, Anton Batenev, Вы писали:
AB>Здравствуйте, _d_m_, Вы писали:
_>> Задаю вопрос по другому. Есть таблица с автоинкрементным полем. Эта таблица существует в двух БД и настроена двухсторонняя репликация этой таблицы, как быть с автоинкрементынм полем? Сразу говорю identity seed — есть чмо и отстой, поэтому не будем о этом. Итак, как?
AB>Переформулируй задачу в терминах MySQL, чтобы мы все точно понимали, что у тебя есть, чего ты хочешь достичь и что ты будешь для этого делать.
Чеегоо? В каких терминах? У него другие термины?
Понимаешь, есть такой стандарт, называется SQL. Дык я и не сказал ничего такого, что бы выходило за его рамки. Ах да, в MySQL со стандартом плохо, говорят не дотягивает даже до SQL-86.
Здравствуйте, mrTwister, Вы писали:
T>Здравствуйте, _d_m_, Вы писали:
___>>Спасибо, посмеялся. ___>>Во первых, речь шла про план запроса. Типа такого http://files.rsdn.ru/21534/PlanPutina2.GIF , там еще мышкой наводишь например на индекс скан и смотришь что, где и почему — число строк, размер строки, io cost и многое. T>Тебе шашечки, или ехать? Или ты информацию только в картинках воспринимаешь?
Здравствуйте, _d_m_, Вы писали:
___>Чеегоо? В каких терминах? У него другие термины? ___>Понимаешь, есть такой стандарт, называется SQL. Дык я и не сказал ничего такого, что бы выходило за его рамки.
В каком стандарте есть репликация?
___>Ах да, в MySQL со стандартом плохо, говорят не дотягивает даже до SQL-86.
Давай по пунктам. Чего именно из стандарта нет в MySQL.
Здравствуйте, mrTwister, Вы писали:
T>Здравствуйте, _d_m_, Вы писали:
___>>Чеегоо? В каких терминах? У него другие термины? ___>>Понимаешь, есть такой стандарт, называется SQL. Дык я и не сказал ничего такого, что бы выходило за его рамки.
T>В каком стандарте есть репликация?
Ясно. В сад. К землеройкам.
Да это просто слив. Сценарий я описал недвусмысленно ясно и нечего прикидываться валенком.
Здравствуйте, mrTwister, Вы писали:
T>Здравствуйте, _d_m_, Вы писали:
___>>Даже не заикался — т.к. понятно, что нет. Как и много другого. Просто человек заявил — что мол поддерживает GUID-ы, а как выяснилось нет.
T>Ссылку покажешь, где я такое говорил?
Ну может и не ты конкретно, но из вашей компании. Тем не менее, подхватил и продолжил спор именно ты на именно эту тему.
___>>И постоянно приводит сравнения с MS SQL и Oracle, причем некорректные.
T>Какие именно сравнения некорректны?
Нет особого желания перелопачивать весь достаточно объемный топик. Любое сравнение MySQL с нормальной человеческой СУБД уже некорректно априори в силу ущербности MySQL
___>>Хотя MySQL-ю до нормальных СУБД, как свинье до Луны.
T>Вот я и пытаюсь понять, почему "MySQL-ю до нормальных СУБД, как свинье до Луны". Пока что в пример приводили мелочи, которые все имеют workaround.
Какие такие мелочи? ACID? Ну ни фига себе мелочь. Если ACID-а нет — это уже не СУБД.
Ладно, давай поговорим об уровнях изоляции (как части ACID): SERIALIZABLE обеспечивает?
или
Материализованные представления?
Интерфейсы массовой вставки (bulk load)?
Партиционирование таблиц?
Триггеры, замещающие триггеры?
Общие табличные выражения?
Оконные функции? (rank(), row_number() и пр.)
Операторы APPLY?
Табличные UDF? (или аналог)
select from select?
Автообновление статистик индексов?
Автоматическая параметризация AdHoc запросов?
Типы nvarchar(max), varbinary(max) (или аналоги)
Тип xml? Инексация содержимого данного типа? Вставка/изменение/удаление узлов? Подержка xpath запросов?
Работа с XML-ем (типа OPENXML) а также множество разных ф-ций?
Выдача результатов запроса в виде XML?
Операторы OUTPUT для INSERT/UPDATE/SELECT?
Сервисы аналитики (аналитические кубы)?
А что-типа ServiceBroker есть?
Может есть средства шифрования?
Плюс вагон и маленькая тележка мелочей, начиная с GUID, и заканчивая реально удобными тулзами типа студии и профайлера. Я уж не говорю, что на реально сложном запросом на несколько экранов поделка MySQL загнется — оптимизатор зачаточный. Ну как хотя-бы с запросиком на несколько... 10 джойнов?
Выходит MySQL годится только для несложных задач, но не более.
PS: Может что забыл, но это то с чем сами работаем, за редким исключением.
Здравствуйте, _d_m_, Вы писали:
___>PS: И таки планы запросов могу посмотреть?
Да. Но не в том виде, как в SMS
___>Или это просто блокнот с подсветкой синтакасиса?
Это Toad — "блокнот с подсветкой синтаксиса"?
Этот "блокнот с подсветкой синтаксиса" в версии для MSSQL Server стоит до 1300$, и народ покупает несмотря на наличие бесплатнй SMS. Как думаешь, почему?
Здравствуйте, Mamut, Вы писали:
T>> ___>Ах да, в MySQL со стандартом плохо, говорят не дотягивает даже до SQL-86.
T>> Давай по пунктам. Чего именно из стандарта нет в MySQL.
M>Здесь: http://troels.arvin.dk/db/rdbms/
Ну и?
PostgreSQL Has views. Breaks that standard by not allowing updates to views; offers the non-standard 'rules'-system as a work-around.
DB2 Conforms to at least SQL-92.
MSSQL Conforms to at least SQL-92.
MySQL Conforms to at least SQL-92.
Oracle Conforms to at least SQL-92.
Informix Conforms to at least SQL-92.
Здравствуйте, mrTwister, Вы писали:
T>Это Toad — "блокнот с подсветкой синтаксиса"? T>Этот "блокнот с подсветкой синтаксиса" в версии для MSSQL Server стоит до 1300$, и народ покупает несмотря на наличие бесплатнй SMS. Как думаешь, почему?
Там речь шла о бесплатных средствах. Аж автор топика жирным выделил.
Здравствуйте, _d_m_, Вы писали:
___>Какие такие мелочи? ACID? Ну ни фига себе мелочь. Если ACID-а нет — это уже не СУБД.
ACID есть. ACIDа нет только для DDL, где он и не нужен.
___>Ладно, давай поговорим об уровнях изоляции (как части ACID): SERIALIZABLE обеспечивает?
Да.
___>или
___>Материализованные представления?
workaround: http://www.shinguz.ch/MySQL/mysql_mv.html
___>Интерфейсы массовой вставки (bulk load)?
да ___>Партиционирование таблиц?
да
___>Триггеры, замещающие триггеры?
Да. Замещающих нет. workaround: на уровне приложения.
___>Общие табличные выражения?
Нет. workaround: куча способов, использовавшихся до появления 2005 сервера.
___>Оконные функции? (rank(), row_number() и пр.)
Да.
___>Операторы APPLY?
Нет. workaround: написать запрос иначе
___>Табличные UDF? (или аналог)
Нет.
___>select from select?
Да
___>Автообновление статистик индексов?
Да
___>Автоматическая параметризация AdHoc запросов?
Не знаю
___>Типы nvarchar(max), varbinary(max) (или аналоги)
Да
___>Тип xml? Инексация содержимого данного типа?
Нет. Используется строка.
___>Вставка/изменение/удаление узлов? Подержка xpath запросов?
Да.
___>Работа с XML-ем (типа OPENXML) а также множество разных ф-ций? Выдача результатов запроса в виде XML?
Нет. Через приложение.
___>Операторы OUTPUT для INSERT/UPDATE/SELECT? ___>Сервисы аналитики (аналитические кубы)? ___>А что-типа ServiceBroker есть?
Нет. Используй MSMQ или аналоги коих куча.
___>Может есть средства шифрования?
Есть.
___>Плюс вагон и маленькая тележка мелочей, начиная с GUID, и заканчивая реально удобными тулзами типа студии и профайлера. Я уж не говорю, что на реально сложном запросом на несколько экранов поделка MySQL загнется — оптимизатор зачаточный. Ну как хотя-бы с запросиком на несколько... 10 джойнов?
Еще раз количество экранов запроса не причем, оптимизатору плевать сколько у тебя экранов.
___>Выходит MySQL годится только для несложных задач, но не более.
Откуда это выходит?
С таким же успехом можно написать список фич и операторов, которые есть в MySQL, но нет в MSSQL
Например, Hash partitioning, REPLACE, INSERT ... ON DUPLICATE KEY UPDATE
Здравствуйте, avpavlov, Вы писали:
___>>Интерфейсы массовой вставки (bulk load)?
A>Это есть, и даже в некоторых моментах превосходит МС СКЛ.
A>Например, можно указать, что у нас декорированный КСВ
A>"v1","v2","v3" будет распарсено как v1,v2,v3 — в МС СКЛ этого нет и жутко бесит.
A>Зато в МС СКЛ есть импорт из fixed length файлов
Bulk load API — это не только файлы. См. класс SqlBulkCopy
Здравствуйте, mrTwister, Вы писали:
___>>Типы nvarchar(max), varbinary(max) (или аналоги) T>Да
Как? Можно пример?
___>>Тип xml? Инексация содержимого данного типа? T>Нет. Используется строка.
Это совсем не то.
___>>Вставка/изменение/удаление узлов? Подержка xpath запросов? T>Да.
Не понял. Поддержки XML нет, а поддержка встаки/изменения/xpath есть? Это что-то связанное с Девидом Блейном?
___>>Работа с XML-ем (типа OPENXML) а также множество разных ф-ций? Выдача результатов запроса в виде XML? T>Нет. Через приложение.
Совсем-совсем не то.
Здравствуйте, mrTwister, Вы писали:
T>Здравствуйте, _d_m_, Вы писали:
___>>Какие такие мелочи? ACID? Ну ни фига себе мелочь. Если ACID-а нет — это уже не СУБД.
T>ACID есть. ACIDа нет только для DDL, где он и не нужен.
Это MySQL твой не нужен.
___>>Ладно, давай поговорим об уровнях изоляции (как части ACID): SERIALIZABLE обеспечивает? T>Да.
For transactional messaging Service Broker is clearly a better choice than MSMQ. Being a part of the SQL Server database engine, Service Broker provides the same level of transactional gaurantees as any other database operations in the engine. Besides that, Service Broker scales up to multiple processors, as well as offers various means to scale out which MSMQ does not. If "exactly once, in-order" processing is a requirement (and given you are doing TCP, it seems to me that it must be), the conversation primitive of Service Broker is much more natural fit. With MSMQ you'd have to do a lot more work to get that right. Finally, SQL Server supports Windows Failover Clustering as well as database mirroring for high availability. And if you do not need your Service Broker conversations to span multiple instances, then you could simply use SQL Server 2005 express, which is free.
___>>Может есть средства шифрования? T>Есть.
___>>Плюс вагон и маленькая тележка мелочей, начиная с GUID, и заканчивая реально удобными тулзами типа студии и профайлера. Я уж не говорю, что на реально сложном запросом на несколько экранов поделка MySQL загнется — оптимизатор зачаточный. Ну как хотя-бы с запросиком на несколько... 10 джойнов? T>Еще раз количество экранов запроса не причем, оптимизатору плевать сколько у тебя экранов.
___>>Выходит MySQL годится только для несложных задач, но не более. T>Откуда это выходит?
Для тебя — ниоткуда. Наслаждайся MySQL и далее.
T>С таким же успехом можно написать список фич и операторов, которые есть в MySQL, но нет в MSSQL
Только вес этих фич маленький, так синтаксический сахарок, не более.
T>Например, Hash partitioning, REPLACE, INSERT ... ON DUPLICATE KEY UPDATE
Здравствуйте, criosray, Вы писали:
___>>>Типы nvarchar(max), varbinary(max) (или аналоги) T>>Да C>Как? Можно пример?
text, binary
___>>>Тип xml? Инексация содержимого данного типа? T>>Нет. Используется строка. C>Это совсем не то.
___>>>Вставка/изменение/удаление узлов? Подержка xpath запросов? T>>Да. C>Не понял. Поддержки XML нет, а поддержка встаки/изменения/xpath есть? Это что-то связанное с Девидом Блейном?
http://dev.mysql.com/doc/refman/5.1/en/xml-functions.html
___>>>Работа с XML-ем (типа OPENXML) а также множество разных ф-ций? Выдача результатов запроса в виде XML? T>>Нет. Через приложение. C>Совсем-совсем не то.
Что можно такого сделать через OPENXML, чего нельзя через приложение?
Здравствуйте, _d_m_, Вы писали:
___>Это MySQL твой не нужен. ___>Опять велосипед. ___>Ацтой. ___>Слив засчитан. ___>Для тебя — ниоткуда. Наслаждайся MySQL и далее.
Детский сад. Продолжать дискуссию в том же стиле не намерен.
Здравствуйте, mrTwister, Вы писали:
___>>>>Типы nvarchar(max), varbinary(max) (или аналоги) T>>>Да C>>Как? Можно пример?
T>text, binary
text не аналог, т.к. nvarchar(max) до 8к символов хранит строку как обычный nvarchar, а при привышении этого лимита происходит конвертация в LBO.
Не нужно пояснять в чем разница и в чем преимущество подхода mssql?
___>>>>Тип xml? Инексация содержимого данного типа? T>>>Нет. Используется строка. C>>Это совсем не то.
___>>>>Вставка/изменение/удаление узлов? Подержка xpath запросов? T>>>Да. C>>Не понял. Поддержки XML нет, а поддержка встаки/изменения/xpath есть? Это что-то связанное с Девидом Блейном?
T>http://dev.mysql.com/doc/refman/5.1/en/xml-functions.html
Понятно.
T>>>Нет. Через приложение. C>>Совсем-совсем не то. T>Что можно такого сделать через OPENXML, чего нельзя через приложение?
Нельзя выполнять операции непосредственно на сервере, не гоняя гигабайты данных по сети или по пайпу между процессами.
Здравствуйте, _d_m_, Вы писали:
_> Даже не заикался — т.к. понятно, что нет. Как и много другого. Просто человек заявил — что мол поддерживает GUID-ы, а как выяснилось нет.
Поддерживает, но не в типе поля. Это мы уже выяснили. Т.е. те, кто хочет воспользоваться приемуществами UUID, те им могут пользоваться уже сейчас. Тем, кому нужно только поле типа GUID, тем придется или править код или найти другой сервер БД. Проблемы тут я не вижу.
_> И постоянно приводит сравнения с MS SQL и Oracle, причем некорректные. Хотя MySQL-ю до нормальных СУБД, как свинье до Луны.
Понятие "нормальности" должно всегда быть относительно задачи. Можно привести по сотне use-case для каждого из серверов, где будет выиигрывать тот или другой.
Здравствуйте, _d_m_, Вы писали:
_> AB>Переформулируй задачу в терминах MySQL, чтобы мы все точно понимали, что у тебя есть, чего ты хочешь достичь и что ты будешь для этого делать. _> Чеегоо? В каких терминах? У него другие термины?
Лично мне не совсем понятно что и как именно ты хочешь. Репликацию типа master-master? Две и более NDB ноды дадут тебе два и более физических мастера.
_> Я уж не говорю, что на реально сложном запросом на несколько экранов поделка MySQL загнется — оптимизатор зачаточный. Ну как хотя-бы с запросиком на несколько... 10 джойнов?
Оптимизатор Мускуля и ен может быть незачаточным. Потому что он может оптимизировать сколько ему влезет, а потом напорется на движок.
Например, InnoDB не умеет быстро выполнять запрос SELECT COUNT(*) FROM table_name. Все. И пусть у MySQL будет хоть мегаоптимизатор, на InnoDB этот щзапрос выполнится где-то за O(m.n), где m — размер записи, а n — количество записей. И хоть ты убейся.
Так что десять джойнов могут спокойно упереться не только в оптимизатор, но и в движок
Здравствуйте, mrTwister, Вы писали:
T> T>> ___>Ах да, в MySQL со стандартом плохо, говорят не дотягивает даже до SQL-86.
T> T>> Давай по пунктам. Чего именно из стандарта нет в MySQL.
T> M>Здесь: http://troels.arvin.dk/db/rdbms/
T> Ну и?
Что ну и? Был вопрос:
Давай по пунктам. Чего именно из стандарта нет в MySQL.
Здравствуйте, Mamut, Вы писали:
M>Что ну и? Был вопрос: M>
M>Давай по пунктам. Чего именно из стандарта нет в MySQL.
M>Ответ на этот вопрос получен?
Ты вообще читал, о чем там речь шла? Человек утверждал, что MySQL плохо поддерживает стандарт (очевидно _d_m_ имел ввиду хуже, чем MSSQL) и что он не поддерживает даже SQL86.
Здравствуйте, mrTwister, Вы писали:
T> M>Что ну и? Был вопрос: T> M>
T> M>Давай по пунктам. Чего именно из стандарта нет в MySQL.
T> M>
T> M>Ответ на этот вопрос получен?
T> Ты вообще читал, о чем там речь шла? Человек утверждал, что MySQL плохо поддерживает стандарт (очевидно _d_m_ имел ввиду хуже, чем MSSQL) и что он не поддерживает даже SQL86.
Я могу еще раз. И по буквам. Я привычный.
___>Ах да, в MySQL со стандартом плохо, говорят не дотягивает даже до SQL-86.
T> Давай по пунктам. Чего именно из стандарта нет в MySQL.
Здравствуйте, criosray, Вы писали:
c> AB>Тем, кому нужно только поле типа GUID, тем придется или править код или найти другой сервер БД. Проблемы тут я не вижу. c> Не замечаете противоречия в своих словах?
Здравствуйте, Anton Batenev, Вы писали:
AB>Здравствуйте, Mamut, Вы писали:
M>> Например, InnoDB не умеет быстро выполнять запрос SELECT COUNT(*) FROM table_name. Все.
AB>
AB>Конечно, у подобного решения есть недостаток в виде того, что это оценочное значение, однако, на больших числах погрешность обычно вполне приемлемая.
Да-да я считал таким образом кол-во строк, а затем кто-то другой вставил в таблицу записей такое же кол-во как и было в таблице. Вобщем, очередные костыли.
PS: Да большинство фич MySQL — вроде нормальное яблоко, ан нет — сердцевинка то гнилая. А если мне надо точно знать число строк? А если на основе этого числа я в транзакции произвожу дальнейшие действия?
AB>Поддерживает, но не в типе поля. Это мы уже выяснили. Т.е. те, кто хочет воспользоваться приемуществами UUID, те им могут пользоваться уже сейчас. Тем, кому нужно только поле типа GUID, тем придется или править код или найти другой сервер БД. Проблемы тут я не вижу.
Здравствуйте, _d_m_, Вы писали:
___>PS: Да большинство фич MySQL — вроде нормальное яблоко, ан нет — сердцевинка то гнилая. А если мне надо точно знать число строк? А если на основе этого числа я в транзакции произвожу дальнейшие действия?
Ну считай через SELECT count(*)... — это будет не медленнее, чем на Oracle\MSSQL, так как алгоритмическая сложность одинаковая. Mamut упомянул это в контексте того, что на MyIsam select count(*) работает за O(1), потому что там другая архитектура.
Здравствуйте, mrTwister, Вы писали:
T> ___>PS: Да большинство фич MySQL — вроде нормальное яблоко, ан нет — сердцевинка то гнилая. А если мне надо точно знать число строк? А если на основе этого числа я в транзакции произвожу дальнейшие действия?
T> Ну считай через SELECT count(*)... — это будет не медленнее, чем на Oracle\MSSQL, так как алгоритмическая сложность одинаковая. Mamut упомянул это в контексте того, что на MyIsam select count(*) работает за O(1), потому что там другая архитектура.
Я об этом и говорю — что бардак с движками не позволяет MySQL'ю даже иметь нормальный оптимизатор запросов
Здравствуйте, Mamut, Вы писали:
M>По ссылке все написано. SQL-2008 не поддерживает никто, естественно. Но это не относится к ответу на вопрос «Где MySQL не дотягивает до стандарта»
Была претензия к MySQL, что мол он плохо стандарты поддерживает. Как выяснилось, не хуже остальных.
Здравствуйте, _d_m_, Вы писали:
_> PS: Да большинство фич MySQL — вроде нормальное яблоко, ан нет — сердцевинка то гнилая. А если мне надо точно знать число строк? А если на основе этого числа я в транзакции произвожу дальнейшие действия?
Можешь описать простой use-case(ы) где жизненно необходимо точное (именно точное) знание количества строк? Пример с SELECT COUNT(*) очень наглядный для объяснения некоторых вещей, а я так до сих пор не могу придумать хорошего примера, когда нельзя пользоваться оценочным. Был бы благодарен.
Здравствуйте, _d_m_, Вы писали:
_> AB>Поддерживает, но не в типе поля. Это мы уже выяснили. Т.е. те, кто хочет воспользоваться приемуществами UUID, те им могут пользоваться уже сейчас. Тем, кому нужно только поле типа GUID, тем придется или править код или найти другой сервер БД. Проблемы тут я не вижу. _> Ну вот и пришли к консенсусу
Здравствуйте, mrTwister, Вы писали:
T>Здравствуйте, Mamut, Вы писали:
M>>Я об этом и говорю — что бардак с движками не позволяет MySQL'ю даже иметь нормальный оптимизатор запросов
T>Ну дак _d_m_ очевидно решил, что на MSSQL select count(*) работает быстрее и с радостью пустился поливать говном MySQL
Здравствуйте, Anton Batenev, Вы писали:
AB>Здравствуйте, _d_m_, Вы писали:
_>> PS: Да большинство фич MySQL — вроде нормальное яблоко, ан нет — сердцевинка то гнилая. А если мне надо точно знать число строк? А если на основе этого числа я в транзакции произвожу дальнейшие действия?
AB>Можешь описать простой use-case(ы) где жизненно необходимо точное (именно точное) знание количества строк? Пример с SELECT COUNT(*) очень наглядный для объяснения некоторых вещей, а я так до сих пор не могу придумать хорошего примера, когда нельзя пользоваться оценочным. Был бы благодарен.
Сходу, что за 5 секунд в голову пришло — пэйджинг с навигацией по номеру страницы для последних страниц будет косячить.
Здравствуйте, mrTwister, Вы писали:
T>Здравствуйте, Mamut, Вы писали:
M>>По ссылке все написано. SQL-2008 не поддерживает никто, естественно. Но это не относится к ответу на вопрос «Где MySQL не дотягивает до стандарта»
T>Была претензия к MySQL, что мол он плохо стандарты поддерживает. Как выяснилось, не хуже остальных.
Ну-ну. Ты действительно в это веришь, или делаешь тут нам хорошую мину при плохой игре?
Специально скачал книгу в djvu формате "SQL Справочник. 2-е издание. Включает SQL Server, DB2, MySQL, Oracle и PostgeSQL". 832 страницы. Вобщем книга описывает стандарт SQL:2003 и как с этим делом в перечисленных СУБД. Я не стал штудировать стандарты SQL:86, SQL:92, SQL:99 — уверен и там у MySQL зияющие прорехи.
По поводу стандарта. В MySQL отсутствуют, но есть в MS SQL:
ALL/ANY/SOME
Хранимые процедуры
курсоры
CONNECT
ALTER DATABASE
Общие табличные выражения
Тип XML
CREATE/ALTER/DROP ROLE
CREATE SCHEMA
EXCEPT
INTERSECT
UNION
Помимо прочего, ничего не нашел про партиционирование таблиц в MySQL — mrTwister обманул? Если уж инструкции CREATE TABLE, CREATE INDEX — не могут указывать местоположение таблицы/индекса на другом носителе, то о каком партиционировании речь.
Далее обнаружено, что отсутвуют в MySQL, но есть в MS SQL (и не только там):
1. Секционированные представления
2. Конструкции INSERT...SELECT, INSERT...EXECUTE
3. Например, в MS SQL я могу писать мощные запросы в предложениях UPDATE, DELETE. А в MySQL?
4. Агрегатные ф-ции с оконными ф-циями
Да и вообще сложилось унылое впечатление от синтаксиса MySQL — например: CREATE INDEX. Если в MySQL от силы 3 параметра, то в MS SQL их 20, а в Oracle и того больше.
Здравствуйте, mrTwister, Вы писали:
T>Здравствуйте, _d_m_, Вы писали:
___>> ___>>У меня select count на 3282892 строк за 3 сек.
T>Это и называется медленно. На MyISAM он бы выполнился мгновенно.
За сколько? Размер строки данной таблицы 126 байт.
А то вот, если у бабушки был бы "нефритовый стержень", то она была бы дедушкой.
Ну и мы жеж как-бы договорились — MyISAM — в топку, рассматриваем InnoDB. Где есть хоть какая-то функциональность СУБД: транзакции, подобие ACID и прочее. Так что тенденция к сливу прослеживается недвусмысленно.
Здравствуйте, mrTwister, Вы писали:
T>Здравствуйте, _d_m_, Вы писали:
___>>Специально скачал книгу в djvu формате "SQL Справочник. 2-е издание. Включает SQL Server, DB2, MySQL, Oracle и PostgeSQL". 832 страницы.
T>Выкинь эту книгу. Судя по всему её писали таккие же как ты: MySQL толком не видел, но говном поливаем.
___>>По поводу стандарта. В MySQL отсутствуют, но есть в MS SQL:
___>>ALL/ANY/SOME T>http://dev.mysql.com/doc/refman/5.0/en/any-in-some-subqueries.html
Добавили в 5-ом. Там книга про 4.х.
Но, все-таки — ALL нет
___>>Хранимые процедуры T>http://dev.mysql.com/doc/refman/5.1/en/stored-routines-syntax.html
Добавили в 5-ом. Ладно, поставим галочку. Хотя не факт что там нет граблей.
___>>курсоры T>http://dev.mysql.com/doc/refman/5.0/en/cursors.html
Убогенько, но ладно зачет.
___>>ALTER DATABASE T>http://dev.mysql.com/doc/refman/4.1/en/alter-database.html
Давай сравним. Почуствуй разницу, и пойми наконец — как далек MySQL от нормальной СУБД. Таких аналогий просто вагон.
MySQL:
ALTER DATABASE [db_name]
alter_specification ...
alter_specification:
[DEFAULT] CHARACTER SET [=] charset_name
| [DEFAULT] COLLATE [=] collation_name
MS SQL:
ALTER DATABASE database_name
{
| MODIFY NAME = new_database_name
| COLLATE collation_name
| <file_and_filegroup_options>
| <set_database_options>
}
[;]
<file_and_filegroup_options >::=
<add_or_modify_files>::=
<filespec>::=
<add_or_modify_filegroups>::=
<filegroup_updatability_option>::=
<set_database_options>::=
<optionspec>::=
<auto_option> ::=
<change_tracking_option> ::=
<cursor_option> ::=
<database_mirroring_option> ::=
<date_correlation_optimization_option> ::=
<db_encryption_option> ::=
<db_state_option> ::=
<db_update_option> ::=
<db_user_access_option> ::=
<external_access_option> ::=
<parameterization_option> ::=
<recovery_option> ::=
<service_broker_option> ::=
<snapshot_option> ::=
<sql_option> ::=
<termination> ::=
<file_and_filegroup_options >::=
<add_or_modify_files>::=
{
ADD FILE <filespec> [ ,...n ]
[ TO FILEGROUP { filegroup_name } ]
| ADD LOG FILE <filespec> [ ,...n ]
| REMOVE FILE logical_file_name
| MODIFY FILE <filespec>
}
<filespec>::=
(
NAME = logical_file_name
[ , NEWNAME = new_logical_name ]
[ , FILENAME = {'os_file_name' | 'filestream_path' } ]
[ , SIZE = size [ KB | MB | GB | TB ] ]
[ , MAXSIZE = { max_size [ KB | MB | GB | TB ] | UNLIMITED } ]
[ , FILEGROWTH = growth_increment [ KB | MB | GB | TB| % ] ]
[ , OFFLINE ]
)
<add_or_modify_filegroups>::=
{
| ADD FILEGROUP filegroup_name
[ CONTAINS FILESTREAM ]
| REMOVE FILEGROUP filegroup_name
| MODIFY FILEGROUP filegroup_name
{ <filegroup_updatability_option>
| DEFAULT
| NAME = new_filegroup_name
}
}
<filegroup_updatability_option>::=
{
{ READONLY | READWRITE }
| { READ_ONLY | READ_WRITE }
}
<auto_option> ::=
{
AUTO_CLOSE { ON | OFF }
| AUTO_CREATE_STATISTICS { ON | OFF }
| AUTO_SHRINK { ON | OFF }
| AUTO_UPDATE_STATISTICS { ON | OFF }
| AUTO_UPDATE_STATISTICS_ASYNC { ON | OFF }
}
<change_tracking_option> ::=
{
CHANGE_TRACKING {
= ON [ <change_tracking_option_list > ] |
<change_tracking_option_list> |
= OFF
}
}
<change_tracking_option_list> ::=
{
( <change_tracking_option> | <change_tracking_option_list> ,
<change_tracking_option> )
}
<change_tracking_option> ::=
{
AUTO_CLEANUP = { ON | OFF }
| CHANGE_RETENTION = { retention_period { DAYS | HOURS | MINUTES } ]
}
<cursor_option> ::=
{
CURSOR_CLOSE_ON_COMMIT { ON | OFF }
| CURSOR_DEFAULT { LOCAL | GLOBAL }
}
<database_mirroring_option>::=
<partner_option> | <witness_option> }
<partner_option> ::=
PARTNER { = 'partner_server'
| FAILOVER
| FORCE_SERVICE_ALLOW_DATA_LOSS
| OFF
| RESUME
| SAFETY { FULL | OFF }
| SUSPEND
| TIMEOUT integer
}
<witness_option> ::=
WITNESS { = 'witness_server'
| OFF
}
<date_correlation_optimization_option> ::=
{
DATE_CORRELATION_OPTIMIZATION { ON | OFF }
}
<db_encryption_option> ::=
ENCRYPTION { ON | OFF }
<db_state_option> ::=
{ ONLINE | OFFLINE | EMERGENCY }
<db_update_option> ::=
{ READ_ONLY | READ_WRITE }
<db_user_access_option> ::=
{ SINGLE_USER | RESTRICTED_USER | MULTI_USER }
<external_access_option> ::=
{
DB_CHAINING { ON | OFF }
| TRUSTWORTHY { ON | OFF }
}
<parameterization_option> ::=
{
PARAMETERIZATION { SIMPLE | FORCED }
}
<recovery_option> ::=
{
RECOVERY { FULL | BULK_LOGGED | SIMPLE }
| TORN_PAGE_DETECTION { ON | OFF }
| PAGE_VERIFY { CHECKSUM | TORN_PAGE_DETECTION | NONE }
}
<service_broker_option> ::=
{
ENABLE_BROKER
| DISABLE_BROKER
| NEW_BROKER
| ERROR_BROKER_CONVERSATIONS
| HONOR_BROKER_PRIORITY { ON | OFF}
}
<snapshot_option> ::=
{
ALLOW_SNAPSHOT_ISOLATION { ON | OFF }
| READ_COMMITTED_SNAPSHOT {ON | OFF }
}
<sql_option> ::=
{
ANSI_NULL_DEFAULT { ON | OFF }
| ANSI_NULLS { ON | OFF }
| ANSI_PADDING { ON | OFF }
| ANSI_WARNINGS { ON | OFF }
| ARITHABORT { ON | OFF }
| COMPATIBILITY_LEVEL = { 80 | 90 | 100 }
| CONCAT_NULL_YIELDS_NULL { ON | OFF }
| NUMERIC_ROUNDABORT { ON | OFF }
| QUOTED_IDENTIFIER { ON | OFF }
| RECURSIVE_TRIGGERS { ON | OFF }
}
<termination> ::=
{
ROLLBACK AFTER integer [ SECONDS ]
| ROLLBACK IMMEDIATE
| NO_WAIT
}
For information about partitioning support offered in commercial MySQL Server binaries, see MySQL Enterprise Server 5.1
___>>Далее обнаружено, что отсутвуют в MySQL, но есть в MS SQL (и не только там): ___>>1. Секционированные представления T>Для этого есть MySQL кластер
Да-да у этой поделки еще и кластер есть. И сколько стоит?
___>>2. Конструкции INSERT...SELECT, INSERT...EXECUTE T>http://dev.mysql.com/doc/refman/5.1/en/insert-select.html
Добавили в 5-ом. Ладно, поставим галочку. Хотя не факт что там нет граблей.
___>>3. Например, в MS SQL я могу писать мощные запросы в предложениях UPDATE, DELETE. А в MySQL? T>Можешь
Добавили в 5-ом. Ладно, поставим галочку. Хотя не факт что там нет граблей.
___>>4. Агрегатные ф-ции с оконными ф-циями T>http://dev.mysql.com/doc/refman/5.0/en/select.html T>Почитай про слово LIMIT
Чушь! Даже не знаешь о чем речь.
USE AdventureWorks;
GO
SELECT SalesOrderID, ProductID, OrderQty
,SUM(OrderQty) OVER(PARTITION BY SalesOrderID) AS 'Total'
,AVG(OrderQty) OVER(PARTITION BY SalesOrderID) AS 'Avg'
,COUNT(OrderQty) OVER(PARTITION BY SalesOrderID) AS 'Count'
,MIN(OrderQty) OVER(PARTITION BY SalesOrderID) AS 'Min'
,MAX(OrderQty) OVER(PARTITION BY SalesOrderID) AS 'Max'
FROM Sales.SalesOrderDetail
WHERE SalesOrderID IN(43659,43664);
GO
PS: Я конечно поставил зачеты кое-где исключительно на веру. А какие там грабли это надо самому пробовать.
Здравствуйте, mrTwister, Вы писали:
T> M>Я об этом и говорю — что бардак с движками не позволяет MySQL'ю даже иметь нормальный оптимизатор запросов
T> Ну дак _d_m_ очевидно решил, что на MSSQL select count(*) работает быстрее и с радостью пустился поливать говном MySQL
При чем тут d_m? Можешь перечитать ветку, начиная с моего сообщения про SELECT COUNT(*)
В MSSQL поведение оптимизатора и базы — детерминированое. В MySQL — нет.
Здравствуйте, _d_m_, Вы писали:
_> AB>Можешь описать простой use-case(ы) где жизненно необходимо точное (именно точное) знание количества строк? Пример с SELECT COUNT(*) очень наглядный для объяснения некоторых вещей, а я так до сих пор не могу придумать хорошего примера, когда нельзя пользоваться оценочным. Был бы благодарен. _> Сходу, что за 5 секунд в голову пришло — пэйджинг с навигацией по номеру страницы для последних страниц будет косячить.
5.0 — текущая рабочая лошадка (а вот Community Server 5.1 — пока что бета AFAIK). Не надо скатываться до уровня своего оппонента. С процедурами в 5.0 всё нормально (триггеры не юзал). Единственное, что меня по жизни бесит, — у разных серверов разные диалекты. Но это не претензия конкретно к мускулю.
___>>>1. Секционированные представления T>>Для этого есть MySQL кластер ___>Да-да у этой поделки еще и кластер есть. И сколько стоит?
Не надо скатываться до уровня своего оппонента. Что там и как на самом деле с кластерами, я не знаю — и ты похоже тоже.
Нда, забавно.
Вообще меня уже давно забавляют две вещи:
1. MySQL — на диво приличный движок. Один из самых удачных известных мне опенсорсных проектов; для коллективной поделки он работает очень хорошо. Весьма девелопер-френдли; во многих местах синтаксис сделан специально так, чтобы облегчить жизнь тем, кто привык к MS SQL (как я плевался в своё время с Interbase!). В общем и целом — зачёт.
2. Фанаты почему-то настаивают на сравнении его со столпами индустрии, которые лидируют в tpc.org, начали развиваться лет на 10-15 раньше мускула, и в разработке которых принимали фулл-тайм участие самые крутые чуваки из мира субдстроения.
Первое — замечательно, классно, здорово. Сравнивая мускул с потребностями какого-то конкретного проекта в большинстве случаев можно обнаружить если не 100%, то 95% покрытия — и за эти деньги это очень хорошо.
Но вот сравнивать его с DB2, Oracle, MS SQL — крайне противопоказано. Такое сравнение неизбежно продемонстрирует безнадёжную отсталость либо мускула, либо того, кто сравнивает.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Anton Batenev, Вы писали:
AB>Здравствуйте, _d_m_, Вы писали:
_>> У меня select count на 3282892 строк за 3 сек.
AB>Что-то как-то сильно шустро. Это на горячих кэшах?
Нет.
Размер таблицы 126 * 3282892 / 1024 / 1024 = 400 Мб. RAM-а 4Гб, но при этом еще больше 10-ка таких же активных баз. А в базе таблиц много.
Но есть маленькая хитрость Оптимизатор берет самый маленький индекс для этой таблицы и считает по нему. Ну там правда и серверок неплохой: HP Proliant DL380, 2 х Xeon 2Ггц 4 ядра, RAID контролер P400 c 256Мб кэшем, диски SAS — 10k об/мин, Win 2003 x64, MS SQL 2005 x64. Плюс кроме MS SQL на этом сервере больше ничего нет.
Здравствуйте, Sinclair, Вы писали:
S>Но вот сравнивать его с DB2, Oracle, MS SQL — крайне противопоказано. Такое сравнение неизбежно продемонстрирует безнадёжную отсталость либо мускула, либо того, кто сравнивает.
Здравствуйте, mrTwister, Вы писали:
___>>Хотя MySQL-ю до нормальных СУБД, как свинье до Луны.
T>Вот я и пытаюсь понять, почему "MySQL-ю до нормальных СУБД, как свинье до Луны". Пока что в пример приводили мелочи, которые все имеют workaround.
Обязательно бахнем! И не раз. Весь мир в труху! Но потом. (ДМБ)
