Здравствуйте, 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.