The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

В рамках проекта Drizzle начата разработка легковесного варианта MySQL

23.07.2008 23:18

Директор MySQL по архитектуре Брайан Эйкер (Brian Aker) представил проект Drizzle, в рамках которого создается упрощенный и более быстрый вариант MySQL, в котором будет убрана поддержка некоторых типов данных, хранимых процедур, триггеров, кэша запросов (query cache), представлений (view), операции GRANT и системы ACL, команды SHOW, предварительно подготовленных запросов (prepared statement) и других утяжеляющих работу MySQL возможностей. В качестве хранилища по умолчанию будет использован InnoDB.

Развитие проекта будет полностью делегировано комьюнити, по схеме подобной взаимодействию Fedora и RedHat. В качестве лицензии выбрана GPL v2.

Архитектура Drizzle построена на основе идеи микро-ядра и подключаемых в виде модулей дополнительных возможностей.

  1. Главная ссылка к новости (http://www.builderau.com.au/ne...)
  2. Анонс от Michael Widenius, одного из основателей проекта MySQL
  3. Drizzle FAQ
  4. Инструкция по сборке Drizzle из исходных текстов
  5. Wiki страница проекта
Лицензия: CC-BY
Тип: Интересно / К сведению
Короткая ссылка: https://opennet.ru/17090-mysql
Ключевые слова: mysql, sql, database
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (54) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Oles (?), 00:51, 24/07/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Бесполезный проект. Даже не могу представить что те, которых MySQL устраивает, по-чему то захотят его "облегчать".
     
     
  • 2.3, Аноним (3), 01:02, 24/07/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Нас (scribd.com) - устроит, facebook и fotolog (сегодня спрашивал у них) - тоже устроит :-)
     
     
  • 3.5, Oles (?), 01:43, 24/07/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >Нас (scribd.com) - устроит, facebook и fotolog (сегодня спрашивал у них) -
    >тоже устроит :-)

    Ради чего? На чём экономим?

     
     
  • 4.37, User294 (ok), 19:04, 26/07/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >Ради чего? На чём экономим?

    Если уж нужна легкая БД без крутых фич - тут по-моему выигрышно смотрится sqlite который юзают все кому не лень.Он вообще не клиент-сервер и вся библа - 300 кил кода.Вместе движком бд и поддержкой довольно большого набора SQL, база одним файлом.Итого самое оно для применений где фич обычного MySQL слишком много, IMHO.

     
     
  • 5.44, Гыгыка (?), 17:32, 02/02/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >>Ради чего? На чём экономим?
    > Если уж нужна легкая БД без крутых фич - тут по-моему выигрышно
    > смотрится sqlite который юзают все кому не лень.Он вообще не клиент-сервер
    > и вся библа - 300 кил кода.Вместе движком бд и поддержкой
    > довольно большого набора SQL, база одним файлом.Итого самое оно для применений
    > где фич обычного MySQL слишком много, IMHO.

    Для ОДИНОЧНОГО пользователя\процесса - да.
    Для МАЛЮСЕНЬКОГО сайта с МИЗЕРНОЙ посещаемостью - да.

    SQLite неспособна параллельно обрабатывать даже средне нагруженные сайты.
    Проверь сам что будет, если ты будешь одновременно читать из SQLite и писать. Тестани эдак на 10 читателях и 3 писателях хотя бы. Если не глуп, то поймешь, что SQLite - недоСУБД. Правда, ты очень удивишься, что и разработчики SQLite это не скрывают.

     
  • 3.6, Alrond (??), 03:49, 24/07/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Кстати, оффтоп, но поздравляю с новой, кажется интересной, работой.
    Как первый шаг, перевод на nginx вижу уже произошел :)
     
  • 3.10, tty01 (?), 07:52, 24/07/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Чем открывать файлы .scb?
     
  • 2.42, Гыгыка (?), 17:29, 02/02/2011 [^] [^^] [^^^] [ответить]  
  • +/
    А те - кого он не устраивает?
    Например, я реально не понимаю - за каким на сравнительно простых запросах и небольшом числе пользователей он там много жрет ресурсов
     

  • 1.2, Gambler (??), 00:56, 24/07/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Хм, возвращение к 3.x?
     
     
  • 2.43, Гыгыка (?), 17:29, 02/02/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Хм, возвращение к 3.x?

    С чего бы это?
    Развитый язык SQL - остается.

     

  • 1.4, pavlinux (ok), 01:23, 24/07/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Но останется под присмотром Sun?
     
  • 1.7, Jerzy (?), 06:09, 24/07/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    innocat + innogrep? :)
     
  • 1.8, tty01 (?), 07:03, 24/07/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Ха-ха. Нет, это просто смешно. Когда MySQL был 3.23, многие выбирали его из-за высокой скорости отдачи запросов, простоты установки, отсутствия триггеров, хранимых процедур. Сегодня MySQL оброс множеством функций, что делает его непригодным в ряде проектов, и поэтому создается облегченная версия MySQL - Drizzle.

    Вопрос - сколько пройдет времени, прежде чем появится облегченная версия Drizzle?

     
     
  • 2.45, Гыгыка (?), 17:34, 02/02/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Ха-ха. Нет, это просто смешно. Когда MySQL был 3.23, многие выбирали его
    > из-за высокой скорости отдачи запросов, простоты установки, отсутствия триггеров, хранимых
    > процедур. Сегодня MySQL оброс множеством функций, что делает его непригодным в
    > ряде проектов, и поэтому создается облегченная версия MySQL - Drizzle.
    > Вопрос - сколько пройдет времени, прежде чем появится облегченная версия Drizzle?

    Как выяснилось - первый официально стабильный релиз спустя 2 года

     

  • 1.9, idkfa (?), 07:27, 24/07/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    может стоило покурить sqlite чем шашкой махать сгоряча
     
     
  • 2.13, Аноним (-), 09:49, 24/07/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Тригеры в нем есть :) Не подходит :)
     
     
  • 3.14, Cosgor (?), 10:05, 24/07/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >Тригеры в нем есть :) Не подходит :)

    <cut>в котором будет убрана поддержка некоторых типов данных, хранимых процедур, триггеров </cut> :]       ^^^^^^^^^^^                                                 ^^^^^^^^

     
     
  • 4.46, Гыгыка (?), 17:35, 02/02/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >>Тригеры в нем есть :) Не подходит :)
    > <cut>в котором будет убрана поддержка некоторых типов данных, хранимых процедур, триггеров
    > </cut> :]       ^^^^^^^^^^^  
    >            
    >            
    >            
    >            
    >   ^^^^^^^^

    В SQLite тригеры есть.

     

  • 1.11, Все тот же аноним (?), 08:59, 24/07/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Чтобы что-то убрать, нужно сначала это по-человечески реализовать. И была безобразно кастрированная СУБД, а теперь вообще от СУБД останется одно название.
     
     
  • 2.47, Гыгыка (?), 17:38, 02/02/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Чтобы что-то убрать, нужно сначала это по-человечески реализовать. И была безобразно кастрированная
    > СУБД, а теперь вообще от СУБД останется одно название.

    С чего бы это?
    dBASE куда как проще, а тем не менее - самая настоящая СУБД.

    Вы специфику СУБД для веба не понимаете. Для большинства хостеров ну вовсе не нужен оверхед ресурсов, а подавляющему числу движков сайтов - ну вовсе не нужны те возможности, что создают этот оверхед.

     

  • 1.12, Аноним (12), 09:33, 24/07/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >Чтобы что-то убрать, нужно сначала это по-человечески реализовать. И была >безобразно кастрированная СУБД, а теперь вообще от СУБД останется одно название.

    идите в сад любезный - есть масса программ которым мускул нужен в режиме записная книжка. Это проги типа DC хабов - всевозможные небольшие самописные служебные программы и т.д.

    есть масса задача для которых не нужна полноценная СУБД

     
     
  • 2.15, Crazy Alex (?), 10:10, 24/07/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Так в таких программах действительно sqlite место
     
     
  • 3.48, Гыгыка (?), 17:39, 02/02/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Так в таких программах действительно sqlite место

    Не-а.
    Такие записные книжки, блоги и т.п. бывают иногда ну очень посещаемы.

     
  • 2.16, INM (??), 10:12, 24/07/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >>Чтобы что-то убрать, нужно сначала это по-человечески реализовать. И была >безобразно кастрированная СУБД, а теперь вообще от СУБД останется одно название.
    >
    >идите в сад любезный - есть масса программ которым мускул нужен в
    >режиме записная книжка. Это проги типа DC хабов - всевозможные небольшие
    >самописные служебные программы и т.д.
    >
    >есть масса задача для которых не нужна полноценная СУБД

    Тогда чем sqlite не устраивает?

     
     
  • 3.17, uldus (ok), 10:36, 24/07/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >Тогда чем sqlite не устраивает?

    У sqlite 4 большие проблемы:
    1. Решения на его основе не масштабируются
    2. Он совершенно не тянет нагрузку, т.е. по одному запросу выполняет нормально, а при необходимости обработки параллельных запросов не годится.
    3. у него нет средств кеширования данных, он каждый раз лезет на диск.
    4. Это не СУБД, а библиотека.


    Drizzle идеален для web-приложений, для которых производительность критична, а все перечисленное в новости совершенно не нужно. Создатели MySQL наконец особнали, что постоянное усложнение до добра не доведет, кося в сторону enterprise, они теряют главную нишу - web.

     
     
  • 4.19, Жирный Ачкарик (?), 10:54, 24/07/2008 [^] [^^] [^^^] [ответить]  
  • +/
    > Drizzle идеален для web-приложений, для которых производительность критична

    Без query cache? Бгыгы.

     
     
  • 5.35, Щекн Итрч (?), 16:35, 26/07/2008 [^] [^^] [^^^] [ответить]  
  • +/
    В жизни не тратил памяти на query cache.
    Под высокой нагрузкой он приносит только ущерб.
     
  • 4.21, Veter (??), 11:35, 24/07/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Вы бы попробовали, прежде чем такие утверждения делать.

    1. На кластере используйте репликацию, синхронную или асинхронную. На одном хосте в отличии от других баз при увеличении числа ядер производительность растет _линейно_.
    2. Нагрузку держит существенно лучше даже постгреса, не говоря про мускуль. Постгрес на железе типа пентиум Д с саташным винтом держит порядка 150-200 средней сложности транзакций в секунду, эскулайт минимум на порядок больше.
    3. Вы про кэширование чтения или записи? Если про чтение, есть shared cache, который следует включить для этой цели. Если про кэширование записи - после завершения транзакции данные принудительно сбрасываются на диск, хотя это можно отключить директивами PRAGMA.
    4. Библиотека тоже может быть СУБД. Только эта СУБД из класса встраиваемых.

     
     
  • 5.24, Phil Kulin (?), 12:46, 24/07/2008 [^] [^^] [^^^] [ответить]  
  • +/
    > Нагрузку держит существенно лучше даже постгреса, не говоря про мускуль.

    Прошу прощения, но мускуль пока ещё был всё же легче постгреса

    И ещё раз прошу прощения, а что у нас с конкурентными запросами в sqlite?

     
     
  • 6.26, INM (??), 12:52, 24/07/2008 [^] [^^] [^^^] [ответить]  
  • +/
    http://www.sqlite.org/faq.html
    http://www.sqlite.org/features.html
    Думаю найдете ответы на все свои вопросы.
     
     
  • 7.27, Phil Kulin (?), 12:55, 24/07/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >Думаю найдете ответы на все свои вопросы.

    Мы наверное с разных планет. Не нашёл ни одного положительного ответа. Подскажите, что я делаю не так?

     
  • 6.28, Veter (??), 13:28, 24/07/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >> Нагрузку держит существенно лучше даже постгреса, не говоря про мускуль.
    >
    >Прошу прощения, но мускуль пока ещё был всё же легче постгреса

    Мускуль легче, проще, хуже держит нагрузку и медленнее на комплексных запросах. Последнее зависит не от "легкости", а от планировщика. Тема не раз обсуждалась, найти результаты тестирования проблем не составит. Хотя замечу, что если у вас выборки без объединения таблиц, мускуль быстрее. При объединении нескольких таблиц быстрее постгрес. Зато мускуль админить проще, репликация есть, очень много пользователей и легко найти информацию.

    >И ещё раз прошу прощения, а что у нас с конкурентными запросами
    >в sqlite?

    Запросы на чтение могут выполняться одновременно, на запись - последовательно. Если вы хотите создать очередь запросов, используйте функцию sqlite3_busy_timeout. Замечу, что на саташных винтах очередь запросов на запись работает много эффективнее, чем куча конкурентных запросов к диску. Учитывая, что одна транзакция занимает от 500 микросекунд, можно выполнять сотни запросов на запись плюс тысячи на чтение в секунду. Учитывая возможность эскулайта присоединять к открытой базе другие базы (по умолчанию 10 баз, а лимит на 32-бит машине 30 баз), можно партишионировать базу (например, отдельная база на каждый филиал компании) и получать производительность еще выше, сохраняя возможность строить отчеты по данным из всех баз совместно.

    Если у вас нагрузка более сотен запросов на запись в секунду, можно создавать базу в ОЗУ. Например, хранение сессионной информации выгодно делать именно так, а при запуске/останове сервера приложений копировать базу с диска/на диск.

     
  • 5.29, uldus (ok), 13:32, 24/07/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >Вы бы попробовали, прежде чем такие утверждения делать.

    Я как-то пытался поднять RT на sqlite, рассудив, что для такой задачи MySQL будет как из пушки по воробьям. К тому времени как в базе накопилось около 1000 тикетов, что само по себе смехотворная цифра, размер базы был около 2 Мб, каждая операция занимала по несколько секунд. После того как заменили sqlite на MySQL, все стало летать, нагрузка на сервер упала до нуля. Вторая попытка была с поднятием какого-то web-форума (название из головы вылетело)  с базой на sqlite, все повторилось точь в точь, вначале все гладко, но как только увеличивается объем данных и начинают появляться параллельные запросы - тормозит по страшному.

     
     
  • 6.31, Veter (??), 15:06, 24/07/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >[оверквотинг удален]
    >Я как-то пытался поднять RT на sqlite, рассудив, что для такой задачи
    >MySQL будет как из пушки по воробьям. К тому времени как
    >в базе накопилось около 1000 тикетов, что само по себе смехотворная
    >цифра, размер базы был около 2 Мб, каждая операция занимала по
    >несколько секунд. После того как заменили sqlite на MySQL, все стало
    >летать, нагрузка на сервер упала до нуля. Вторая попытка была с
    >поднятием какого-то web-форума (название из головы вылетело)  с базой на
    >sqlite, все повторилось точь в точь, вначале все гладко, но как
    >только увеличивается объем данных и начинают появляться параллельные запросы - тормозит
    >по страшному.

    Даже не знаю, что вам сказать... чтоб не обидеть :-) По личному опыту - базы эскулайт до 100 гиг работают очень быстро. Большие базы не проверял, будет под рукой свободный винт на терабайт, проверю.

     
     
  • 7.32, uldus (ok), 15:29, 24/07/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >Даже не знаю, что вам сказать... чтоб не обидеть :-) По личному
    >опыту - базы эскулайт до 100 гиг работают очень быстро. Большие
    >базы не проверял, будет под рукой свободный винт на терабайт, проверю.

    Вполне может быть, что описанные мной проблемы SQLite наблюдаются только во FreeBSD или являются ошибкой в определенной версии, я использовал SQLite 3.2.x.


     
     
  • 8.33, Veter (??), 16:15, 24/07/2008 [^] [^^] [^^^] [ответить]  
  • +/
    В указанной вами версии блокировка конкурентного доступа на внутреннем мьютексе ... текст свёрнут, показать
     
     
  • 9.39, толик (?), 23:45, 27/07/2008 [^] [^^] [^^^] [ответить]  
  • +/
    gt оверквотинг удален Veter, ну не знаю даже что сказать Лайт этот тормоз нев... текст свёрнут, показать
     
  • 7.34, Умный (?), 18:36, 24/07/2008 [^] [^^] [^^^] [ответить]  
  • +/
    > Даже не знаю, что вам сказать... чтоб не обидеть :-)

    бакула на sqlite при нескольких лямах записей в базе и объёме в 5Гб никак не работала, тока винтом шуршала. Пришлось от sqlite отказаться. Да, кстати, а есть у sqlite аналог repair или ещё чего-нить чтобы целостность восстановить?

     
  • 5.38, толик (?), 23:31, 27/07/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >Вы бы попробовали, прежде чем такие утверждения делать.
    >
    >1. На кластере используйте репликацию, синхронную или асинхронную. На одном хосте в
    >отличии от других баз при увеличении числа ядер производительность растет _линейно_.

    ну пробовали. Я не понимаю чего такую пургу гнать?
    Лайт ваще однопоточный внутри - о чем ты тут рассказываеш?!
    Посмотри исходники или хотя бы доку почитай ламер  

    >2. Нагрузку держит существенно лучше даже постгреса, не говоря про мускуль. Постгрес
    >на железе типа пентиум Д с саташным винтом держит порядка 150-200
    >средней сложности транзакций в секунду, эскулайт минимум на порядок больше.

    да расскажи!  :-)  Может быть на тех ихних примерах в 1000 записей?
    Ваще пародия у них на сайте.

    Лайт загибается уже если в базе есть несколько тыс записей.
    Может ты просто гонял тупой запрос на одной таблице типа WHERE fld = X
    а ты попробуй прогнать что нибудь типа джойна на 5-10 таблицах или агрегацию на джойнах.
    Лайт в принципе не имеет блокировок записей! Так что как он тебе отработает паралельно что то ?

    Если кто то хочет увидеть настоящую скорость пацаны, попробуйте Valentina базочку.
    Она жарит mySQL/MS SQL/Oracle в 50-100 (!!!) раз. Сам не верил пока не проверил!
    Смотри здесь http://www.valentina-db.com

    Причем что в ней классно, она может работать и как встраиваемая - то есть бьет лайт, и как нормальный сервер с клиентами из под разных языков. Кстати похоже что делают ее наши хлопцы.

     
  • 4.49, Гыгыка (?), 17:40, 02/02/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >>Тогда чем sqlite не устраивает?
    > У sqlite 4 большие проблемы:
    > 1. Решения на его основе не масштабируются
    > 2. Он совершенно не тянет нагрузку, т.е. по одному запросу выполняет нормально,
    > а при необходимости обработки параллельных запросов не годится.
    > 3. у него нет средств кеширования данных, он каждый раз лезет на
    > диск.
    > 4. Это не СУБД, а библиотека.

    4. Попрошу не оскорблять. Есть весьма сурьезные библиотеки-СУБД. То же FireBird

     

  • 1.18, Аноним (12), 10:49, 24/07/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    От мне какраз такая легкая "записная книжка" очень нужна, так что я "за" такой проект
     
     
  • 2.20, ононим (?), 11:20, 24/07/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >От мне какраз такая легкая "записная книжка" очень нужна, так что я
    >"за" такой проект

    сделай эту записную книжку на LDAP

     
     
  • 3.50, Гыгыка (?), 17:41, 02/02/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >>От мне какраз такая легкая "записная книжка" очень нужна, так что я
    >>"за" такой проект
    > сделай эту записную книжку на LDAP

    livejournal.com ?

     
  • 2.22, Ноним (?), 11:37, 24/07/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >От мне какраз такая легкая "записная книжка" очень нужна, так что я
    >"за" такой проект

    Кури sqlite

     
     
  • 3.51, Гыгыка (?), 18:24, 02/02/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >>От мне какраз такая легкая "записная книжка" очень нужна, так что я
    >>"за" такой проект
    > Кури sqlite

    Йа-йа, натурлих. Особенно на реальном посещаемом веб-сайте.
    Пионерия, что с вас взять...

     

  • 1.25, zuborg (?), 12:50, 24/07/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Все понимаю, можно облегчить, согласен.
    Но Query cache то можно было оставить, иначе получится полное пэ
     
     
  • 2.52, Гыгыка (?), 18:25, 02/02/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Все понимаю, можно облегчить, согласен.
    > Но Query cache то можно было оставить, иначе получится полное пэ

    Они же как решение для облаков толкают.
    А query cache памяти ой как немало кушает.

     

  • 1.30, Аноним (12), 14:56, 24/07/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    форк?
     
  • 1.36, User294 (ok), 19:00, 26/07/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >и других утяжеляющих работу MySQL возможностей.

    И нахрена оно такое нужно когда sqlite его на данном поле по легковесности натянет как тузик грелку?

     
     
  • 2.53, Гыгыка (?), 18:26, 02/02/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >>и других утяжеляющих работу MySQL возможностей.
    > И нахрена оно такое нужно когда sqlite его на данном поле по
    > легковесности натянет как тузик грелку?

    Я Вам больше скажу - есть еще FoxPro...
    Очень быстрый.
    На ОДНОМ пользователе.

     

  • 1.40, дядя (?), 03:46, 20/12/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Может они еще исключат SQL из MySQL чтобы не утяжелял работу ? :)
     
     
  • 2.41, geekkoo (ok), 15:52, 05/03/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >Может они еще исключат SQL из MySQL чтобы не утяжелял работу ?
    >:)

    Кстате, офигенно правильная мысль.

     
     
  • 3.54, Гыгыка (?), 18:28, 02/02/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >>Может они еще исключат SQL из MySQL чтобы не утяжелял работу ?
    >>:)
    > Кстате, офигенно правильная мысль.

    Уже реализовано:

    Плуг-ин HandlerSocket для MySQL
    http://l-o-n-g.livejournal.com/153756.html

     
  • 2.55, Гыгыка (?), 18:28, 02/02/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Может они еще исключат SQL из MySQL чтобы не утяжелял работу ?
    > :)

    Этим другие проекты занимаются.
    А для Drizzle - полноценный SQL принципиально должен быть.

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2023 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру