Разработчики MySQL начали работу над ее форком - Drizzle

Название некошерное. А так - очень интересно. Ждём ебилдов.

ну stored procedure оставили б хотя б, ща их в сайтах юзаем даж, иначе совсем задница будет, даж дерево записей нормальное не выбрать в один проход.

> Из MySQL планируется убрать views, triggers, prepared statements, stored procedures, query cache и другие фичи.

Системно мыслят, всё равно подобную функциональность в последнее время стало модно перекладывать на ORM и сопутствующие прослойки, а монстро-оракел какбэ и не нужна.

Другое дело, что проще отучить SQLite блокировать всю базу при записи, и ихний дризл тогда ваще будет не нужен.

>> Из MySQL планируется убрать views, triggers, prepared statements, stored procedures, query cache и другие фичи.

> Системно мыслят, всё равно подобную функциональность в последнее время стало модно перекладывать на ORM и сопутствующие прослойки, а монстро-оракел какбэ и не нужна.

но выглядит это интересно - они эти фичи в 5.0 добавили а теперь удалять собрались :-).

>планируется убрать views, triggers, prepared statements, stored procedures, query cache и другие фичи

давайте еще уберем PK,FK и будем пользоваться только bdb.

>prepared statements

для начала их бы реализовали полноценно. а то собсно убирать то и нечего :)

Dragon Fly MySQL :-)

>Системно мыслят, всё равно подобную функциональность в последнее время стало модно перекладывать на ORM и сопутствующие прослойки, а монстро-оракел какбэ и не нужна.

и как ORM без тригеров поживает?

> Другое дело, что проще отучить SQLite блокировать всю базу при записи, и ихний дризл тогда ваще будет не нужен.

вроде как отучили, или я ошибаюсь ?

>и как ORM без тригеров поживает?

??? Можете объяснить свой ход мысли?

А то я уже 8 лет используют ORM без всяких триггеров.

Закопали стюардессу...

Это скорее не форк, а отдельный прожект основанный на мускуле. а -то думал они не согласные тем что их сан купил...

>А то я уже 8 лет используют ORM без всяких триггеров.

ну вот пример: есть к примеру локальная база фильмов, соответственно есть табличка с фильмами (название, год выхода, описание), табличка с файлами (id_фильма, размер, продолжительность), табличка с актерами (имя), табличка для связи фильм-актер. теперь мне требуется сделать следующее: вывести список фильмов с названием, годом выпуска, общим размером и пролжительностью; вывести список актеров с количеством фильмов, в которых снимались. теперь оцените затраты на использование в таких задачах ORM и тригеров.

пускай еще движок SQL уберут

>ну stored procedure оставили б хотя б

Вместо того, чтобы из "stored procedures" сделать "precompiled stored procedures", и то что было убирают? ИМХО маразм...

Я тока не пойму, что там останется то когда они все это уберут?

txt | grep ?

>Из MySQL планируется убрать views, triggers, prepared statements, stored procedures, query cache и другие фичи.

А форкнули тройку?:))

>вывести список актеров с количеством фильмов, в которых снимались. теперь оцените затраты на использование в таких задачах ORM

Элементарно.

так они же недавно сделали полу-новый движок, Maria -- отказоустойчивый клон MyISAM

....И получиться недо-sqlite...

>Элементарно.

предоставьте пример, который будет работать хотя бы в два раза медленнее, чем если я буду наполнять таблицу с фильмами и актерами тригерами.

Ну, у меня ORM хорошо без триггеров живёт. Что, я где-то подводные камни не заметил? Ткни пальцем...

Видимо, людям захотелось поэкспериментировать. Что это за сервер баз данных без views, prepared statements, stored procedures...

> Я тока не пойму, что там останется то когда они все это уберут? txt | grep ?

+1

Ы. Флаг в руки. С таким набором фич их sqlite затопчет.

> предоставьте пример, который будет работать хотя бы в два раза медленнее, чем если я буду наполнять таблицу с фильмами и актерами тригерами.

А если по-правильному - такое действительно надо делать триггерами или все-таки materialized view хорошо бы?

Концептуально materialized view правильнее... проблема в том что сейчас любая доступная dbms полезет его весь пересчитывать...

Есть случаи, когда три простых запроса ного эффективнее одного сложного.

Кстати, как ты, вообще логику работы ORM в описанном тобой случае представляешь?

> stored procedures

После написания оных для мускуля надо I Группу инвалидности давать :-/

типа ура! ? (осторожно так).

>предоставьте пример, который будет работать хотя бы в два раза медленнее, чем если я буду наполнять таблицу с фильмами и актерами тригерами.

Не внял вопросу:

1. Просили вывести - то есть читать. 2. В представленной схеме не вижу зачем что-то наполнять триггерами. Или это делается чтобы по имени актера мрачном вызове хранимки вычислять запись и делать соответствующие вставки? 3. Вставка десятка записей в указанной базе данных - вещь редкая в контексте времени и имеет небольшое время выполнения - любая реализация будет иметь приемлемую производительность.

>Кстати, как ты, вообще логику работы ORM в описанном тобой случае представляешь?

как-как, в ORM придется обратиться к объекту фильм, для него найти соответствующие объекты "файл", посчитать их количество и размер. для актеров аналогично. Если я дальше захочу сортировать выводимый список по этим вычислимым атрибутам, то наступит полный ахтунг.

по поводу mview - здесь они не помогут: во-первых, они все-таки предназначены для DW а не для OLTP, во вторых не укладываются в логическую модель: вставляем в таблицу, а выбираем из mview

>как-как, в ORM придется обратиться к объекту фильм, для него найти соответствующие объекты "файл", посчитать их количество и размер. для актеров аналогично. Если я дальше захочу сортировать выводимый список по этим вычислимым атрибутам, то наступит полный ахтунг.

Ничего этого не будет в нормальном орме. Если ты выводишь список фильмом весь фрейм вывода (страница) будет поднята запросами количеством от 1 до 3х.

>ну stored procedure оставили б хотя б, ща их в сайтах юзаем даж, иначе совсем задница будет, даж дерево записей нормальное не выбрать в один проход.

Юзайте Hibernate или EJB3.

>Ничего этого не будет в нормальном орме

я кажется пример просил. даже если у Вас есть какой-то гипотетический ORM, который прверащает вывод любого списка в SQL с правильным group by, having и пр, в чем я очень сильно сомневаюсь, то все равно заполение нужных атрибутов тригерами, а потом обычная выборка быстрее на порядки.

>query cache Это конечно же излишество. Может, чтоило действительно _форкнуть_ MySQL?

> Ничего этого не будет в нормальном орме. Если ты выводишь список фильмом весь фрейм вывода (страница) будет поднята запросами количеством от 1 до 3х.

Да даже если одним.. как я понимаю будет что-то вроде

SELECT actor.primary_key actor.name, COUNT(actor_films) FROM actor NATURAL JOIN film GROUP BY actor.name, actor.primary_key WHERE <какое там условие на актеров у нас>;

И если актеры в списке плодовитые, то пиши пропало - все dbms полезут перебирать фильмы. *может быть* Oracle сумеет ограничиться быстрыми оценками по films.actor_id, остальные кого я знаю полезут в таблицу...

> query cache Это конечно же излишество. Может, чтоило действительно _форкнуть_ MySQL?

и разрешило взять все но выкинуть query cache ?

>SELECT actor.primary_key actor.name, COUNT(actor_films) FROM actor NATURAL JOIN film GROUP BY actor.name, actor.primary_key WHERE <какое там условие на актеров у нас>;

там связь many-to-many, в жойне будет три таблицы

> SELECT actor.primary_key actor.name, COUNT(actor_films) FROM actor NATURAL JOIN film GROUP BY actor.name, actor.primary_key WHERE <какое там условие на актеров у нас>;

энто че за диалект такой, где group by перед where идет? o_O

>> SELECT actor.primary_key actor.name, COUNT(actor_films) FROM actor NATURAL JOIN film GROUP BY actor.name, actor.primary_key WHERE <какое там условие на актеров у нас>;

> там связь many-to-many, в жойне будет три таблицы

ой, действительно... но ситуацию c производительностью это ни в коем случае не улучшит...

>я кажется пример просил

Hibernate/ObjectRelationalBridge/ крайний случай - iBatis.

>то все равно заполение нужных атрибутов тригерами, а потом обычная выборка быстрее на порядки.

Вся фигня в том что в орме не надо превращать этого в одну выборку. Как я сказал он сделает это тремя в самом простом случае - выберет фильмы, для сделаной выборки выберет прилинкованых актеров и прилинкованные файлы.

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

Я же писал выше - три простых запроса.

Пример реальный сейчас не приведу, так как из ОперыМини пишу перед сном заглянув с коммуникатора на ЛОР. Завтра с утра, если не поломает, приведу соответствующий код на моём ORM.

> Drizzle

они надеятся с таким названием на энтерпрайз? 0_o

Я согласен. Зачем делать сложный запрос, когда можно поднять всю базу и слинковать все дерево в памяти. В концепции ORM база данный вторична, она всего лишь хранилище, которая поддерживает, трасакции, что бы откатить, если че случится

О, наука!
Кастрированый быстрый mysql. Хотя, не каждому эти фичи нужны всегда.

а почему бы и нет?

>Вся фигня в том что в орме не надо превращать этого в одну выборку. Как я сказал он сделает это тремя в самом простом случае - выберет фильмы, для сделаной выборки выберет прилинкованых актеров и прилинкованные файлы.

простите великодушно, я безнадежно туп. Допустим Ваш кибернейт осилил сделать select name, year from films where year>2006 order by name, а потом забомбить select count(file),sum(size) from files where film_id in (...) group by film_id (насколько я понял ваш ORM делать жойны не умеет). а теперь представьте, что я решил свой список упорядочить по размеру и количеству файлов, с таким подходом вам примется полностью перелопатить две таблицы.

>Что быстрее - три простых запроса или один сложный с кучей тригеров - вопрос спорный и смотриться в каждом конкретном случае.

у меня не сложный запрос, а простой, поскольку count(file), sum(size) будут сразу храниться в таблице с фильмами и будут считаться тригерами. Если Вам не западло из ORM заполнять эти же поля (то есть полностью вынести логику из БД) и поэтому тригеры Вам не нужны, то прекрасно, только сопровождать код и базу будет на порядок сложнее.

>Я согласен. Зачем делать сложный запрос, когда можно поднять всю базу и слинковать все дерево в памяти.

теперь допустим, что размер БД, ну скажем гигабайт 10, в жаву столько не влезет при всем желании.

>(насколько я понял ваш ORM делать жойны не умеет)

Умеет но не в этом суть.

> а теперь представьте, что я решил свой список упорядочить по размеру и количеству файлов, с таким подходом вам примется полностью перелопатить две таблицы.

Зачем? Денормализация. В случае кризиса скорости сортировки по синтетическим значениям - то же самое делается добавлением физических аттрибутов с апдейтом их на уровне триггеров или на уровне орма. Подойдите проще - вам нужна работающая система - а не база нормализованная по самое нихочу которая умеет все включая ограбление корованов.

>Если Вам не западло из ORM заполнять эти же поля (то есть полностью вынести логику из БД) и поэтому тригеры Вам не нужны, то прекрасно, только сопровождать код и базу будет на порядок сложнее.

С какой радости? ОРМ это еще один уровень индирекшена. Для вса что принципиальный вопрос писать триггер на PL/блабла или вешать в орме "on update" на языке системы? Да можно сделать и тригерами базы - орму от этого плохо не будет. Не говоря уж о том что если взять гипотетическую систему с ОРМом - то в случае добавления к фильму файла - вызов метода модифицирующего клллекцию - можно написать перечет атрибута - это значительно проще чем писать тригер. Или замапить этот атрибут через выражение (правда это я уже фантазирую - не проверал умеет ли кто-то так поскольку с ормами последний раз имел дело 4 года назад - но принципиальных проблем сдесь нет).

Ну да, давайте все перенесем в application level или вообще забудем о базе данных - нах она вообще нужна?
Ъ-сайтописатели в СУБД вообще не нуждаюццо :ржачь: :D

Кстати, об ОРМ: интересно, а как организовать на ее уровне обработку событий таблицы? :) ORM - это Object-Relational Model или кто-то думает иначе?

Имхо, глупостями занимаюццо. Такая база годится только для мелких быдлокодерских проектов, которыми и так весь инет переполнен.

>Для вса что принципиальный вопрос писать триггер на PL/блабла или вешать в орме "on update" на языке системы?

для моих задач принципиально, поскольку с базой могут работать не только через сайт, туда данные могут подгружаться откуда угодно и как угодно, поэтому я предпочитаю считать то что мне нужно внутри базы. А те компонетны которые хотят выкинуть (вьхи, тригеры и процедуры) не такие уж и бесполезные.