После двух лет альфа и бета тестирования анонсирован (http://blog.drizzle.org/2011/03/15/drizzle-2011-03-12-ga-tar.../) первый стабильный релиз СУБД Drizzle (http://blog.drizzle.org/2011/03/15/drizzle-2011-03-12-ga-tar.../), готовый для повседневного использования. Проект Drizzle был основан в июле 2008 года с целью создания упрощенного и более быстрого варианта MySQL, в котором убрана поддержка утяжеляющих работу MySQL возможностей, которые планируется реализовать в виде плагинов. БД позиционируется как высоконадежная и поддерживающая ACID-транзакции. В качестве хранилища используется InnoDB и PBXT (http://www.opennet.ru/opennews/art.shtml?num=19478). Исходные тексты проекта переписаны на языке C++ и распространяются в рамках лицензии GPLv2. Инициатором проекта является Брайан Эйкер (Brian Aker), бывший директор MySQL AB по архитектуре, но управление разработкой Drizzle целиком находится в руках независимого сообщества.
По сравнению (http://do...URL: http://blog.drizzle.org/2011/03/15/drizzle-2011-03-12-ga-tar.../
Новость: http://www.opennet.ru/opennews/art.shtml?num=29937
Это все очень хорошо! Но как же MySQL?
> Это все очень хорошо! Но как же MySQL?А что MySQL? Работает себе и работает. Все ОК с MySQL.
Есть Drizzle и есть MariaDB. Забудьте про название MySQL.
марийодб уже стало интерпрайз решением?
> марийодб уже стало интерпрайз решением?мускуль когда-то был «интерпрайз решением»? O_O
> мускуль когда-то был «интерпрайз решением»? O_OПод мускулем крутятся далеко не только странички Васи Пупкина.
> Есть Drizzle и есть MariaDB.Что-то я не вижу указанных приложений ни в репозитории RHEL & K ни в Debian-е. Они вообще существуют в живой природе? Или пока что сугубо в лаборатории?
Может в RHEL их и не добавили, а вот в gentoo они существуют. drizzle в официальном репозитории, mariadb в оверлее mysql* dev-db/drizzle [ Masked ]
Latest version available: 7.2011.03.11
Latest version installed: [ Not Installed ]
Size of files: 10,519 kB
Homepage: http://drizzle.org
Description: Database optimized for Cloud and Net applications
License: GPL-2* dev-db/mariadb
Latest version available: 5.1.53
Latest version installed: 5.1.53
Size of files: 24,080 kB
Homepage: http://askmonty.org/
Description: MariaDB is a MySQL fork with 3rd-party patches and additional storage engines merged.
License: GPL-2
Как раз в Дебиане они есть:#aptitude search drizzle
p libdrizzle-dbg - library for the Drizzle and MySQL protocols, debug symbols
p libdrizzle-dev - library for the Drizzle and MySQL protocols, development files
p libdrizzle-doc - library for the Drizzle and MySQL protocols, API documentation
p libdrizzle0 - library for the Drizzle and MySQL protocols
p python-drizzle - Python binding to libdrizzle
p python-drizzle-dbg - Python binding to libdrizzle - debug symbols
p python3-drizzle - Python3 binding to libdrizzle
p python3-drizzle-dbg - Python3 binding to libdrizzle - debug symbols# aptitude show libdrizzle0
Пакунок: libdrizzle0
Стан: встановлений
Версія: 0.8-1
Пріоритет: Додаткові (Extra)
Розділ: libs
Супроводжуючий: Monty Taylor <mordred@inaugust.com>
Розмір в розпакованому стані: 131 k
Залежить: libc6 (>= 2.1.3)
Опис: library for the Drizzle and MySQL protocols
libdrizzle is library implementing the Drizzle and MySQL protocols. It has been designed to be light on memory usage, thread safe, and provide full access
to server side methods.
This package the Drizzle client library.
Домівка: http://launchpad.net/libdrizzle
> Как раз в Дебиане они есть:Да, в дебе оказывается есть. Искал по mariadb не нашел.
Офф, но украинский язык как обычно, взорвал мозг. "Пакунок", хм.
А это и есть тот мускуль, который так нужен (по преимуществу сайтостроителям, но и не только)Потому что дальше начинается пародия на нежно любимый pgsql, и вот она то, - пародия, - не нужна никак.
> А это и есть тот мускуль, который так нужен (по преимуществу сайтостроителям, но и не только)MySQL без ALTER? Ну-ну. Удачи в бою и инкрементальном апдейте схемы базы..
тут скорее не "удалена", а "пока не реализована"
если будет сильный спрос на это, то поддержка может быть реализована,
тем более что практически весь функционал реализован через плагины.
И далее "если будет сильный спрос на это, то поддержка может быть реализована" по всем пунктам хотелок пользователей ))
> А это и есть тот мускуль, который так нужен (по преимуществу сайтостроителям, но и не только)Да, и отказ от prepared statements - это сильно. SQL Injection следит за тобой. Пристально. Особенно в контексте веб-сайта.
>Да, и отказ от prepared statements - это сильно. SQL Injection следит за тобой. Пристально. Особенно в контексте веб-сайта.В нормальных веб-фреймворках вроде Django или Rails об этом заботиться не надо. На сегодняшний день SQL Injection это проблема прежде всего для индусов PHP-шников.
Вы пытаетесь сказать что Django или Rails настолько тупые, что не могут использовать prepared statement API конкретного SQL сервера? Или что они магически добавили поддержку Drizzle задолго до его релиза? Или что под PHP нет фреймворков с ORM?
И кстати индусы от ORM замечательно порождают каскады SQL запросов там, где индусы от чистого PHP делают всего один запрос с join.
> И кстати индусы от ORM замечательно порождают каскады SQL запросов там, где индусы от чистого PHP делают всего один запрос с join.Где-то я это уже слышал. C vs Assembler. Портабельный компактный код vs "зато дешевле".
> И кстати индусы от ORM замечательно порождают каскады SQL запросов там, где индусы от чистого PHP делают всего один запрос с join.Тот же Yii (его ORM) прекрасно генерирует JOIN запросы. Хотя вроде не должно. Он же на пыхыпы.. А ить поди ж ты.
> Вы пытаетесь сказать что Django или Rails настолько тупые, что не могут
> использовать prepared statement API конкретного SQL сервера? Или что они магически
> добавили поддержку Drizzle задолго до его релиза?Drizzle сделан таким образом, что для любого программера "пять секунд" сделать "поддрежку Drizzle" для Rails, Django и Symfony "тупо" клонировав "поддержку Mysql".
Собственно, то, что не вошло (не поддержуется) Drizzle -- как раз в большинстве своём не поддержуется (не используется) нормальными фреймворками.
> В нормальных веб-фреймворках вроде Django или Rails об этом заботиться не надо.
> На сегодняшний день SQL Injection это проблема прежде всего для индусов
> PHP-шников.ORM и SQL Injection - это как бы ортогональные друг другу вещи. Наличие первого отнюдь не исключает наличие второго. В первую очередь все зависит от того, как и через какое место ORM общается с API конкретной базы. Это даже без учета того, что зачастую ORMы позволяют выполнение прямых SQL запросов для 'особых случаев'. И как правило такие случаи нет нет да найдутся.
>> В нормальных веб-фреймворках вроде Django или Rails об этом заботиться не надо.
>> На сегодняшний день SQL Injection это проблема прежде всего для индусов
>> PHP-шников.
> ORM и SQL Injection - это как бы ортогональные друг другу вещи.
> Наличие первого отнюдь не исключает наличие второго. В первую очередь все
> зависит от того, как и через какое место ORM общается с
> API конкретной базы. Это даже без учета того, что зачастую ORMы
> позволяют выполнение прямых SQL запросов для 'особых случаев'. И как правило
> такие случаи нет нет да найдутся.Вообще-то, сама идеология MVC подразумевает НЕ ВОЗМОЖНОСТЬ SQL Injection -- так как ВСЯ РАБОТА С БД должна происходить на уровне модели.
Конечно, Вы в состоянии ручками "машрутизировать" запрос таким образом, что SQL Injection будет возможен, но тут нужно весьма постараться, чего явно не хватает для тех, в чью голову может прийти сия не простая идея! И, в любом случае, это будет нарушение самой концепции MVC.
> Вообще-то, сама идеология MVC подразумевает НЕ ВОЗМОЖНОСТЬ SQL Injection -- так как
> ВСЯ РАБОТА С БД должна происходить на уровне модели.
> Конечно, Вы в состоянии ручками "машрутизировать" запрос таким образом, что SQL Injection
> будет возможен, но тут нужно весьма постараться, чего явно не хватает
> для тех, в чью голову может прийти сия не простая идея!
> И, в любом случае, это будет нарушение самой концепции MVC.Идеология - да, возможно. Но на практике мне может понадобиться построить хитрожопую выборку, которую модель в конкретном фреймворке может и не покрыть. Или же сделать это жутко неоптимально. Идеология идеологией, но работать тоже нужно.
Опять же, повторюсь, ORM (модель в MVC) и SQL Injection - это все-таки не зависящие друг от друга вещи. Вот есть у меня модель UserProfile и есть текстовое поле userName. Очень грубо говоря:
$x = new UserProfile;
$x->userName = $_POST['userName'];
$x->save();Какой SQL запрос будет выполнен в конечном итоге? Как он будет выглядеть? Будет ли использоваться для передачи userName prepared statement или же будут предприняты попытки экранирования пользовательского ввода? Естественно, что как таковой паттерн MVC или ORM не дает ответа на эти вопросы. Все это уже зависит от конкретной реализации. И никто не мешает в конкретном фреймворке накосячить так, что через конечный SQL запрос я смогу исполнить свой подставляемый извне SQL код. Хотя внешне с точки зрения приложения все вроде бы как бы и через модель и пр.
>> Опять же, повторюсь, ORM (модель в MVC) и SQL Injection - это все-таки не зависящие друг от друга вещи.Стоит заметить, что любой вебовский MVC не есть MVC в силу того, что контроллер не исполняет возложенных на него этой моделью функций. Когда говорят про MVC модель для вебприложений, то сильно лукавят.
> Стоит заметить, что любой вебовский MVC не есть MVC в силу того,
> что контроллер не исполняет возложенных на него этой моделью функций. Когда
> говорят про MVC модель для вебприложений, то сильно лукавят.Тут скорее вопрос - что первично: модель или контроллер? :) Ну или даже нет. Модель суть объект, который есть часть иерархии объектов, которые представляют структуру данных конечного приложения. В свою очередь, контроллер так или иначе оперирует конкретными объектами модели для доступа к требуемым данным (не обязательно персистентным т.е. находящимся в базе). Иерархия моделей представляет структуру данных. [иерархия] контроллеров - производимые над ними действия. В чем противоречие паттерну MVC? По крайней мере как я его себе понимаю.
PS: Косноязычно как-то вышло..
>Идеология - да, возможно. Но на практике мне может понадобиться построить хитрожопую выборку, которую модель в конкретном фреймворке может и не покрыть.Элементарно, ватсон. Устанавливаете соответсвующий пакет питона/руби и будет у вас возможность из фреймворка задействовать хоть prepared statements, хоть PL/SQL или PL/pgSQL.
> Элементарно, ватсон. Устанавливаете соответсвующий пакет питона/руби и будет у вас возможность из фреймворка задействовать хоть prepared statements, хоть PL/SQL или PL/pgSQL.Это если низлежащий RDBMS поддерживает соотв. ф-ть. Ну а если нет - селяви.
>>Да, и отказ от prepared statements - это сильно. SQL Injection следит за тобой. Пристально. Особенно в контексте веб-сайта.
> В нормальных веб-фреймворках вроде Django или Rails об этом заботиться не надо.
> На сегодняшний день SQL Injection это проблема прежде всего для индусов
> PHP-шников.В нормальнных PHP-CMF, например Symfony2.0, аналогично.
Если добавить, например, связку Symfony-NetBeans -- то получается вообще интересно.
В чем тут суть... есть вэб-сервер, есть sql-сервер, но для работы с IDE не плохо иметь "лайт" версию базы данных для экспериментов, причем эта "лайт-версия" желательна максимально приближенной по структуре с "продакш"-версией.
Вот именно для этих целей Drizzle -- оптимальный вариант, даже если "продакш"-версия -- что-то на уровне PG/SQL.
> В чем тут суть... есть вэб-сервер, есть sql-сервер, но для работы с IDE не плохо иметь "лайт" версию базы данных для экспериментов, причем эта "лайт-версия" желательна максимально приближенной по структуре с "продакш"-версией. Вот именно для этих целей Drizzle -- оптимальный вариант, даже если "продакш"-версия -- что-то на уровне PG/SQL.Ээээ... А обычный MySQL или PgSQL то чем не устраивают в качестве лайт-версии :-? Вроде легче и проще ещё поискать нужно. Мы ж не про ораклу сейчас прости господи не к ночи будет сказано обсуждаем..
Идея хорошая. Но название не могли получше придумать? название в современном мире - половина успеха.
Дождь,неблагозвучность названия на русском разработчиков не волнует вероятно, они возможно даже и не знают )
> Дождь,
> неблагозвучность названия на русском разработчиков не волнует вероятно, они возможно даже
> и не знают )Никто (BSD-лицензия!) не мешает сделать форк с благозвучным (багозвучным) названием.
Правильный спросить "язык не могли получше придумать".
Какое ж, блин, название неприятное.
>По сравнению с MySQL в Drizzle удалена поддержка…слушайте, а что осталось-то? мультиклиентность ещё удалят пусть — и попробуют сказать, чем оно лучше SQLite.
> слушайте, а что осталось-то? мультиклиентность ещё удалят пусть — и попробуют сказать, чем оно лучше SQLite.Если сравнивать со скулайтом то, как минимум, вменяемая работа с базой в многопоточном приложении, прозрачный сетевой доступ к базе и пр. Боюсь, чтобы сравнивать кастрированного MySQL со скулайтом от него нужно отрезать слишком много.
ты это… читать умеешь, а? не, я помню, что не умеешь, вопрос риторический. я и сказал, что если это отрезать (или с SQLite привинтить, что я, например, делал) — оно даже SQLite проиграет. зато на C++.