URL: https://www.opennet.ru/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 46694
[ Назад ]

Исходное сообщение
"7 причин по которым качество MySQL никогда не будет прежним"

Отправлено opennews , 13-Дек-08 23:35 
"7 Reasons why MySQL Quality will never be the same (http://www.mysqlperformanceblog.com/2008/12/10/7-reasons-mys.../)" - 7 причин по которым качество MySQL никогда не будет как во времена MySQL 3.23:


-  Рост числа разработчиков, усложнение кода, при изначальном немодульном дизайне.
-  Увеличение сложности проекта, связанное с наращиванием функциональности.
-  Увеличение базы пользователей и соответственно числа сообщений об ошибках.
-  Наличие редкоиспользуемых возможностей, некоторые функции остаются слабо протестированными.
-  Система трекинга ошибок раньше позволяла не обращать внимание на мелочи.
-  Смещение интересов в пользу Enterprise, уменьшение интенсивности Community сборок, что приводит к оседанию в релизах ошибок на длительное время.
-  Запутанность взаимоотношений с Innodb/Oracle, что приводит к замедлению исправления ошибок, связанных с Innodb.


От части ошибки в MySQL не так страшны из-за того, что большинство приложений используют лишь небольшой, хорошо отлаженный, костяк возможностей.

URL: http://www.mysqlperformanceblog.com/2008/12/10/7-reasons-mys.../
Новость: http://www.opennet.ru/opennews/art.shtml?num=19375


Содержание

Сообщения в этом обсуждении
"7 причин по которым качество MySQL никогда не будет прежним"
Отправлено metallic , 13-Дек-08 23:35 
3-ий пункт повеселил, типа раньше багрепортом меньше слали, значит багов меньше было?

"7 причин по которым качество MySQL никогда не будет прежним"
Отправлено vadiml , 13-Дек-08 23:38 
> при изначальном немодульном дизайне.

Автор код 5й версии видел? Монолитом там и не пахнет.

> Увеличение базы пользователей и соответственно числа сообщений об ошибках.

вообще-то это наоборот позволяет лучше вылизать код

> Запутанность взаимоотношений с Innodb/Oracle

для этого в 6й версии будет новый движок

> Система трекинга ошибок раньше позволяла не обращать внимание на мелочи.

ну а тут и слов нет....


"7 причин по которым качество MySQL никогда не будет прежним"
Отправлено geekkoo , 15-Дек-08 06:57 
>[оверквотинг удален]
>Автор код 5й версии видел? Монолитом там и не пахнет.
>
>> Увеличение базы пользователей и соответственно числа сообщений об ошибках.
>
>вообще-то это наоборот позволяет лучше вылизать код
>
>> Запутанность взаимоотношений с Innodb/Oracle
>
>для этого в 6й версии будет новый движок
>

Это когда ещё будет ... Они 5.1 вылизать никак не могут, а тут аж 6-я версия.
>> Система трекинга ошибок раньше позволяла не обращать внимание на мелочи.
>
>ну а тут и слов нет....


"7 причин по которым качество MySQL никогда не будет прежним"
Отправлено vitek , 14-Дек-08 00:18 
7 причин почему такие новости бессмысленны.
p.s.:
случайно заглянул.

"7 причин по которым качество MySQL никогда не будет прежним"
Отправлено Аноним , 14-Дек-08 00:43 
5. профессионализм в деталях. (C) Юрий Александрович

"7 причин по которым качество MySQL никогда не будет прежним"
Отправлено дядя , 14-Дек-08 00:59 
Может с усложнением проекта наконец-то сделают нормальный оптимизатор, а не как сейчас - взваливать эту работу на пользователя.

"7 причин по которым качество MySQL никогда не будет прежним"
Отправлено Света , 14-Дек-08 02:08 
А язык C разве не причина?

"7 причин по которым качество MySQL никогда не будет прежним"
Отправлено Vital , 14-Дек-08 02:31 
а что нам предложит мега-программист Света?

"7 причин по которым качество MySQL никогда не будет прежним"
Отправлено korjjj , 14-Дек-08 10:26 
звучит почти как "великий маг тьмы"

"7 причин по которым качество MySQL никогда не будет прежним"
Отправлено Keeper , 14-Дек-08 10:39 
Срочно переписать всё на лиспе. o_O

"7 причин по которым качество MySQL никогда не будет прежним"
Отправлено User294 , 14-Дек-08 11:14 
>Срочно переписать всё на лиспе. o_O

Лучше на Brainfuck сразу :)


"7 причин по которым качество MySQL никогда не будет прежним"
Отправлено СуперАноним , 14-Дек-08 11:25 
Конечно, использовать в проекте ОО язык. Наверное, конкретно C++. И, в общем-то, правильное предложение будет для лучшей управляемости кодом (Гради Буч не врёт).

PS Зря вы все Свету подкалываете, она иногда дельные мысли высказывает.


"7 причин по которым качество MySQL никогда не будет прежним"
Отправлено vitek , 14-Дек-08 12:16 
а может хоть одну субд уровня mysql и выше да чтобы на С++ назовёте?

а Свете вообще грех такое писать, т.к. "С" от "Света", а "С++" от "толстая Света".


"7 причин по которым качество MySQL никогда не будет прежним"
Отправлено mahoro , 14-Дек-08 15:48 
Вы будете удивлены, но там и так используется как раз С++.

"7 причин по которым качество MySQL никогда не будет прежним"
Отправлено vitek , 14-Дек-08 16:15 
точно :-)
$ ldd /usr/sbin/mysqld
    linux-gate.so.1 =>  (0xb7f50000)
    librt.so.1 => /lib/tls/i686/cmov/librt.so.1 (0xb7f01000)
    libz.so.1 => /usr/lib/libz.so.1 (0xb7eeb000)
    libwrap.so.0 => /lib/libwrap.so.0 (0xb7ee1000)
    libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb7edd000)
    libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb7ec4000)
    libcrypt.so.1 => /lib/tls/i686/cmov/libcrypt.so.1 (0xb7e92000)
    libnsl.so.1 => /lib/tls/i686/cmov/libnsl.so.1 (0xb7e79000)
    libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb7d8a000)
    libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb7d63000)
    libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7d54000)
    libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7bf6000)
    /lib/ld-linux.so.2 (0xb7f36000)

"7 причин по которым качество MySQL никогда не будет прежним"
Отправлено Vital , 14-Дек-08 17:45 
полагаю это только для API

"7 причин по которым качество MySQL никогда не будет прежним"
Отправлено Аноним , 15-Дек-08 13:48 
>> 7 причин по которым качество MySQL никогда не будет прежним

8. Все течет, все меняется.

(Кстати, ничего ведь не сказано, что значит прежнее - лучше или хуже =))