Здравствуйте, 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 неприемлимо.
