Здравствуйте, Plague, Вы писали:
P>В последнее время все больше и больше кажется, что что-то не так с SQL. Не с конкретной реализацией, а вообще.
С SQL — все так. В-первых, это язык запросов. Для задач более специализированных, почти в каждой БД есть более мощный язык. Во-вторых, если тебе нужна борьба со сложностью, считай инкапсуляция, то для этого есть и различные ORM с автоматическими построителями запросов, и те же встроенные в БД сохраняемые функции. Функций легко трансформируются в запросы. Ну а в третьих — есть трабла. Несмотря на всю декларативность, SQL имеет одно преимущество — он может рассказать СУБД не только что нужно сделать, но и как это нужно сделать. Существует множество причин почему программист может построить реляционный запрос лучше чем самый лучший современный оптимизатор. Например, то, что в реляционке не хватает всех требуемых знаний о семантике данных. И тут нравится или не нравится, SQL — нет альтернатив. А инкапсуляция, будет только мешать данной задаче.
Здравствуйте, cl-user, Вы писали:
CU>А если вы о том, что для оптимальной работы _вся_ база должна быть в памяти + прочие ограничения на "сложную логику", то с этого и надо было начинать. Для "общего употребления" не годится, ибо по "узкоспециализированным предписаниям".
Ну, не вся, но логика работы с очень большими базами прозрачна и опирается на дисковый кеш ОС. Это мне кажется, кстати, более логичным, чем изобретение своих кешей. И так на буквально каждом уровне все пытаются что-то кешировать и диск, и драйвер устройства, и файловая система и база данных. Итогом может быть торможение.
Хотел бы напомнить, что изначально речь шла об SQL, а не промышленных БД. Реляционными базами и SQL можно пользоваться самими по себе, как хеш-таблицами или списками. Очень удобно, знаете ли, оперировать данными в терминах таблиц и запросов.
CU>Естественно. В тех случаях когда _все_ данные _гарантированно_ не лезут в память, когда какая-то их часть уже может быть в кэше, всех или уже отобранных по подобному критерию... — т.е. когда "что делать" зависит от текущего состояния дел, которое в момент написания запроса неизвестно. И опять же — короче ваш "подробный" запрос не будет.
Звучит очень сложно. Наверно, это очень дорого писать мегаумные анализаторы и многоуровневые кеши на все случаи жизни. Гораздо легче прикупить сотню гигабайт оперативной памяти и дать легкий эффективный и прозрачный движок для БД. А всем, кому это не нравится (дяде Васе с овощного склада) показать на дверь.
CU>Ладно, можно "завязывать" — теперь я вас понял и посему претензий не имею
Здравствуйте, Quintanar, Вы писали:
Q>Ну, не вся, но логика работы с очень большими базами прозрачна и опирается на дисковый кеш ОС. Это мне кажется, кстати, более логичным, чем изобретение своих кешей.
Ну не надо считать разработчиков Oracle полными идиотами. Они там сделали возможность создавать тома вообще без FS — видать таки "собственное" кэширование было оптимальнее.
Q>И так на буквально каждом уровне все пытаются что-то кешировать и диск, и драйвер устройства, и файловая система и база данных. Итогом может быть торможение.
_Может быть_ и даст торможение, а может дать и выигрыш. Если ты не в состоянии управлять кэшем "нижнего уровня" — приходится самому дублировать некоторые функции, если использование кэша критично.
Q>Хотел бы напомнить, что изначально речь шла об SQL, а не промышленных БД. Реляционными базами и SQL можно пользоваться самими по себе, как хеш-таблицами или списками. Очень удобно, знаете ли, оперировать данными в терминах таблиц и запросов.
Не знаю. Вернее забыл с тех пор, как бросил FoxPro фиг знает какой версии и перешёл к базам с поддержкой SQL, многие из которых даже предоставляя _прямой_ доступ к таблицам предупреждали — пользуйтесь SQL — будет быстрее
Q>Звучит очень сложно. Наверно, это очень дорого писать мегаумные анализаторы и многоуровневые кеши на все случаи жизни.
Спросите у Oracle. Да и PostgreSQL в последнее время неплохо "подтянулся" — можете глянуть сразу в source.
Q>Гораздо легче прикупить сотню гигабайт оперативной памяти и дать легкий эффективный и прозрачный движок для БД.
Вот как раз это более походит на "промышленное использование". А ежели данных просто _много_, но используются они не слишком интенсивно (подозреваю ~95% использования всех БД — но это исключительно моя т.з.) — зачем добавлять память? И уж тем более на обычных end-user компах? Опять же другая "крайность" — однопользовательская маленькая база, но скорость опять не слишком критична: берите SQLite — и нет проблем. Зачем заниматься "битовыжиманием" там, где это не критично?
Q>А всем, кому это не нравится (дяде Васе с овощного склада) показать на дверь.
"Нет бога кроме Аллаха..."
CU>>Ладно, можно "завязывать" — теперь я вас понял и посему претензий не имею
Q>Прощаю всех, кого обидел?
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, Plague, Вы писали:
P>>PS. Мое негативное настроение повлияло, что есть БД (SQL Server 2005) в которой СОВСЕМ НЕТ вьюх и процедур, к которой можно делать только запросы и поэтому запросы получаются не в одну страницу.
L>Как это "СОВСЕМ НЕТ"?
Ну вот так... мм... скажем так:
База заказчика имеет около 800 таблиц с констрейнами и индексами, но в угоду, похоже, универсальности (т.к. их система работает минимум с 3мя видами SQL серверов), то в ней отсутствуют вьюхи, процедуры, триггеры... (отсутствие генераторов вообще удручает, а точнее не уникальность ключей в рамках БД, а только в рамках таблицы, т.к. есть ключи и есть некий GUID у многих таблиц, который тоже говорит об уникальности, но в рамках базы, да еще есть поле статуса записи, т.е. удалена или нет... чем-то напоминает Фокспро )
Весь доступ к БД у них уложен в некую объектную модель и таким образом идет доступ к базе, с авт. генерацией запросов и т.п. из-за чего иногда все "встает колом".
Из-за особенностей системы отчетов приходится делать большие запросы, которые внутри собирают все и вся.
Итого — получается запрос, который содержит в себе связку кучи таблиц, при этом с множеством описаний как и какие таблицы связывать, условиями статуса записи, условиями состояния записи и т.п., потому запросы состоят из 100-300 строк, примерно (чистым кодом, без пробелов, 3-8кб один запрос). Уменьшить получается только за счет использования CTE, получается некий реюз, да и только с помощью него можно нормально использовать рекурсивные структуры, которые присутствуют в БД, если же не уменьшать — через несколько дней тяжело понять что в запросах вообще происходит.
(при этом при разработке запросов предполагается, что используется текущая настройка базы и именно SQL Server 2005, иначе вааще повеситься можно, т.к. система еще и немного динамическая, т.е. администратор ПО может переназвать поле в табличке, а есть таблицы с метаинформацией...)
Вот повозившись со всем этим я подумал, что с SQL что-то не так, т.к. при написании больших запросов с "уточняющимися требованиями" и тонкой настройкой приходится их постоянно и сильно менять, а т.к. запросы не маленькие их изменение (можно сказать рефакторинг, т.к. иногда требуется переделать запрос, чтоб результат не изменился, но можно было в него добавить, скажем, дополнительное расчетное поле или сложное условие) является не простой задачей...
Оптимизация — отдельный случай, думаю, некая проблема в SQL, что не хватает некого разбиения запроса, или даже нескольких запросов на части, с целью упростить код, т.е. какой-то декомпозиции. Тот же CTE — только в рамках одного запроса. Конечно можно использовать вьюхи, но "лес" вьюх тоже не решение, т.к. с таким подходом тоже сталкивался, в котором вьюх слишком много, да и зачастую они слишком сложны для применения, т.е. использовать 4-5 таблиц проще и быстрее работает, чем 2 вьюхи, которые тянут внутри еще 10 ненужных для меня таблиц.
Еще, мне кажется, не хватает некого отдельного описания семантики данных и использования этого описания не только базой, но чтобы это учитывалось при написании запросов. К примеру у меня есть жесткая связка из 4х таблиц, где все связаны условиями FK, но в запросе надо описать все четыре таблицы и их связки. Я понимаю что таблицы могут иметь сложные связки по множеству полей и т.п., но это в разы более редкий случай.
Конечно, для конкретной системы можно написать DSL с SQL-like синтаксисом и генерацией вьюх и прочего, но больше меня интересует что же в действительности не так.
----------------------------------------------------------------
Еще интересно, может кто посоветует что почитать о "техниках" разработки на SQL. Например, способы именования таблиц и процедур, использования и именования алиасов с целью более легкой читабельности кода и т.п.
Здравствуйте, Plague, Вы писали:
P>Из-за особенностей системы отчетов приходится делать большие запросы, которые внутри собирают все и вся.
P>Итого — получается запрос, который содержит в себе связку кучи таблиц, при этом с множеством описаний как и какие таблицы связывать, условиями статуса записи, условиями состояния записи и т.п., потому запросы состоят из 100-300 строк, примерно (чистым кодом, без пробелов, 3-8кб один запрос)...
У меня есть подозрение, что я "мимо тазика", но у меня, если размер запроса превышал несколько строк, он, как правило, "генерился" функцией приложения, внутри которой можно и параметров напихать, и "реюзать" то, что хочется (естественно _построение_ запроса, а не его части), и "камментов" напихать и т.п. и т.д. Потери на парсинг запроса (по сравнению с сохранённым в базе) малы по сравнению со временем его работы.
Здравствуйте, cl-user, Вы писали:
CU>У меня есть подозрение, что я "мимо тазика", но у меня, если размер запроса превышал несколько строк, он, как правило, "генерился" функцией приложения, внутри которой можно и параметров напихать, и "реюзать" то, что хочется (естественно _построение_ запроса, а не его части), и "камментов" напихать и т.п. и т.д. Потери на парсинг запроса (по сравнению с сохранённым в базе) малы по сравнению со временем его работы.
Ну вот пример немного "отрефакторенного" запроса с добавленным учетом деревьев. Используется 12 таблиц, 4 параметра, два из которых — списки. =)
Что именно тут генерировать? Это некий примерный запрос для отчета. Тут выборка с учетом выбора элементов дерева, расставление и сортировка для системы отчетов, т.е. чтоб осталось только вывести данные.
Комменты удалил, таблицы переименовал. Этот запрос еще нормально читается. Есть те, что слабо читаются. Вот вопрос в том, как сделать более легким переписывание подобных запросов.
with
TREE1 (ouid, a_overhead) as
(
select e.ouid, a_overhead
from TABLE3 e
where e.ouid = #SOME_PARAM1#
union all
select e.ouid, e.a_overhead
from TABLE3 e
inner join TREE1 n on e.a_overhead = n.ouid
),
TREE2 (a_name, a_id, a_parent, level) as
(
select pc.a_name, pc.a_id, pc.a_parent, 1
from TABLE4 pc
where isnull(pc.a_status,10)<>70
and pc.a_id in (#SOME_PARAM2#)
union all
select pc.a_name, pc.a_id, pc.a_parent, level+1
from TABLE4 pc
inner join TREE2 n on pc.a_parent = n.a_id
where isnull(pc.a_status,10)<>70
)
select (select a_name1 from TABLE5 eod where wpc.a_reg_orgname = eod.ouid) "orgName",
pc.a_name "LK",
pc.a_id "nLK",
0 r,
pc.a_name "LK0",
null "PU",
count(distinct wc.personouid) "LD"
from TABLE1 wc
inner join TABLE6 wpc on wpc.ouid = wc.personouid
and wpc.a_reg_orgname in (select ouid from TREE1) and isnull(wpc.a_status,10)<>70
inner join TABLE8 prnc on prnc.a_id = wc.a_name
inner join TABLE4 pc on pc.a_id = prnc.a_cat and isnull(pc.a_status,10)<>70
and pc.a_id in (select a_id from TREE2)
where (((wc.A_DATE <= #SOME_PARAM4#) or (wc.A_DATE is null)) and ((wc.A_DATELAST is null) or (wc.A_DATELAST >= #SOME_PARAM3#)) and
(ISNULL((select max(wr.A_DATE)
from TABLE6 wpc
left join TABLE11 wlpr on wlpr.FROMID = wpc.ouid and isnull(wlpr.a_status,10)<>70
left join TABLE12 wr on wr.A_OUID = wlpr.TOID and isnull(wr.a_status,10)<>70
where wpc.OUID = wc.personouid),
#SOME_PARAM3#) >= #SOME_PARAM3#))
group by pc.a_id, pc.a_name
union all
select (select a_name1 from TABLE5 eod where wpc.a_reg_orgname = eod.ouid) "orgName",
null "LK",
pc.a_id "nLK",
rank() over(partition by pc.a_name order by sp.a_name) r,
pc.a_name "LK0",
sp.a_name "PU",
count(distinct wc.personouid) "LD"
from TABLE2 wasc
inner join TABLE1 wc on wc.personouid = wasc.personouid
inner join TABLE6 wpc on wpc.ouid = wc.personouid
and wpc.a_reg_orgname in (select ouid from TREE1) and isnull(wpc.a_status,10)<>70
inner join TABLE8 prnc on prnc.a_id = wc.a_name
inner join TABLE4 pc on pc.a_id = prnc.a_cat
and pc.a_id in (select a_id from TREE2) and isnull(pc.a_status,10)<>70
left join TABLE9 scp on scp.a_category = pc.a_id
left join TABLE10 sp on scp.a_preg = sp.ouid and isnull(sp.a_status,10)<>70
and wasc.categoryouid = sp.ouid
where (((wc.A_DATE <= #SOME_PARAM4#) or (wc.A_DATE is null)) and ((wc.A_DATELAST is null) or (wc.A_DATELAST >= #SOME_PARAM3#)) and
(ISNULL((select max(wr.A_DATE)
from TABLE6 wpc
left join TABLE11 wlpr on wlpr.FROMID = wpc.ouid and isnull(wlpr.a_status,10)<>70
left join TABLE12 wr on wr.A_OUID = wlpr.TOID and isnull(wr.a_status,10)<>70
where wpc.OUID = wc.personouid),
#SOME_PARAM3#) >= #SOME_PARAM3#))
and sp.a_name is not null
group by pc.a_id, pc.a_name, sp.a_name
order by pc.a_id, pc.a_name desc, r
зы: интересно, но ключевое слово PARTITION и функция RANK не подсвечиваются раскраской...
Здравствуйте, Plague, Вы писали:
P>Ну вот пример немного "отрефакторенного" запроса с добавленным учетом деревьев. Используется 12 таблиц, 4 параметра, два из которых — списки. =) P>Что именно тут генерировать? Это некий примерный запрос для отчета. Тут выборка с учетом выбора элементов дерева, расставление и сортировка для системы отчетов, т.е. чтоб осталось только вывести данные. P>Комменты удалил, таблицы переименовал. Этот запрос еще нормально читается. Есть те, что слабо читаются. Вот вопрос в том, как сделать более легким переписывание подобных запросов.
<skip sql>
Генерировать — всё Т.е. весь текст. Как "бить на отдельные части"? То что взаимосвязано (поля, таблицы, связи) — однозначно генерить, то что наиболее вероятно может измениться — отдельно генерить. Каждый подзапрос — тоже (хотя может быть и перебор). Кода получится в два раза больше, но если код осмысленный с осмысленными подсказками — править будет действительно на порядок легче, нежели "парсить" в голове готовый запрос и пытаться изменить.
Здравствуйте, cl-user, Вы писали:
CU>Генерировать — всё Т.е. весь текст. Как "бить на отдельные части"? То что взаимосвязано (поля, таблицы, связи) — однозначно генерить, то что наиболее вероятно может измениться — отдельно генерить. Каждый подзапрос — тоже (хотя может быть и перебор). Кода получится в два раза больше, но если код осмысленный с осмысленными подсказками — править будет действительно на порядок легче, нежели "парсить" в голове готовый запрос и пытаться изменить.
Генерировать? как ты это представляешь? (опустим то, что у меня кроме как к SQL доступа нет, но интересно) Не получится ли, что все ще сильней усложнится? Не легче ли будет сделать SQL-like DSL язык знающий специфику и особенности структуры, который будет генерировать SQL запрос?
Если не использовать DSL, то при использовании мэйнстримовых языков для генерации (как это делают, к примеру в PHP ) получится все гораздо сложнее, т.к. часть логики выборки будет содержаться в "генераторе", а часть в запросе. А что если кто-то будет делать вложенные генераторы и т.п.? не.. лучше пусть будут "чистые" и ёмкие запросы.
Здравствуйте, Plague, Вы писали:
P>Конечно, для конкретной системы можно написать DSL с SQL-like синтаксисом и генерацией вьюх и прочего
Ну а что? Вполне нормальное решение, не требующее от БД снижения универсальности из-за усложнения метаданных.
Вот, у нас в текущем проекте есть примерно такое:
USING Parus.Business.Octopus;
DECLARE @InstalledProduct AS InstalledProduct;
SELECT DISTINCT InstalledProductUpdate.ModelDataBasePackage.Master.Identity
FROM InstalledProductUpdate
WHERE InstalledProductUpdate.Master = @InstalledProduct;
Здравствуйте, Quintanar, Вы писали:
Q>Не жалуются. Во всяком случае, на Oracle менять никому и в кошмарном сне не приснится. Оракл — тормозня.
Вот ebay.com так не думает... =) и еще много кто и много где использует Oracle. Да он не быстр на маленьком объеме данных, но именно на большом объеме раскрывается потециал. Все-таки стоимостная оптимизация это весчъ! Правда, это не значит, что надо оставить БД на произвол судьбы, надо считать статистику и т.п., а БД сама решит как именно быстрей, т.к. связки inner join можно перебирать в любом порядке, но от порядка изменится порядок чтения записей и проверки условий, а главную роль будет играть количество прочитанных записей, т.е. учитывая статистику по таблице, количество записей и т.п., Сервер сокращает в разы количество чтений.
Но это только одна сторона, а есть еще не одна тысяча пользователей, которая сама пишет и читает что хочет...
Что-то, мне показалось, что описаный тобой подход в чем то смахивает на простоту Foxpro... там тоже все просто, четко и главное быстро...
Здравствуйте, Plague, Вы писали:
Q>>Не жалуются. Во всяком случае, на Oracle менять никому и в кошмарном сне не приснится. Оракл — тормозня. P>Вот ebay.com так не думает... =) и еще много кто и много где использует Oracle.
AFAIR, Ebay использует какую-то свою распределенную систему, где даже join'ы вручную оптимизируются.
Здравствуйте, Cyberax, Вы писали:
C>AFAIR, Ebay использует какую-то свою распределенную систему, где даже join'ы вручную оптимизируются. здесь можно посмотреть что у них и как
PS. Что-то странный у меня Сабж. Вроде ничего такого не писал. =)
Здравствуйте, AndrewVK, Вы писали:
AVK>Ну а что? Вполне нормальное решение, не требующее от БД снижения универсальности из-за усложнения метаданных. AVK>Вот, у нас в текущем проекте есть примерно такое: AVK>
Ну да, вот такое было бы супер! Но если вам потребовалось использовать DSL, то значит в SQL не хватает гибкости.
У вас используются собственные наработки или есть какие-то существующие наработки для разработки? )
В DSL есть еще бонус в том, что генерация конструкций под конкретный SQL сервер может не снижать эффективности его использования. Эдакая серебрянная пуля. =)))
Здравствуйте, Plague, Вы писали:
P>Ну да, вот такое было бы супер! Но если вам потребовалось использовать DSL, то значит в SQL не хватает гибкости.
Не совсем так. Дело не в гибкости SQL, а в наличии неких специфических метаданных.
P>У вас используются собственные наработки или есть какие-то существующие наработки для разработки? )
Здравствуйте, Plague, Вы писали:
P>Генерировать? как ты это представляешь? (опустим то, что у меня кроме как к SQL доступа нет, но интересно) Не получится ли, что все ще сильней усложнится? Не легче ли будет сделать SQL-like DSL язык знающий специфику и особенности структуры, который будет генерировать SQL запрос?
Я хотел об этом написать, но подумал — не так поймут
P>Если не использовать DSL, то при использовании мэйнстримовых языков для генерации (как это делают, к примеру в PHP ) получится все гораздо сложнее, т.к. часть логики выборки будет содержаться в "генераторе", а часть в запросе. А что если кто-то будет делать вложенные генераторы и т.п.? не.. лучше пусть будут "чистые" и ёмкие запросы.
Сорри, не догнал. Вся логика _построения_ запроса будет в генераторе (ну может быть ещё плюс в каких-то шаблонах — не суть важно). Вложенные генераторы конечно могут быть. Можно провести аналогию с сохранёнными вьюшками. Что не так?
Я просто не понял, что ты имеешь ввиду под словом "генератор"?
CU>Сорри, не догнал. Вся логика _построения_ запроса будет в генераторе (ну может быть ещё плюс в каких-то шаблонах — не суть важно). Вложенные генераторы конечно могут быть. Можно провести аналогию с сохранёнными вьюшками. Что не так?
.
2. Некая библиотека высокоуровневых объектов, посредсвом монипуляцией которыми идет неявный доступ к базе, типа:
Shops ss;
ss.createFilter("NAME", EQUAL, "myShopName");
foreach(Shop s in ss)
{
Customers cs = s.getCustomers();
cs.createFilter("type", NOT_EQUAL, "debtor");
foreach(Customer c in cs)
{
c.setReturnField("SURNAME");
}
}
Query q = createQuery(ss);
Result r = q.execute();
Это такой пример, в котором, на самом деле код не выполняется, а записывается последовательность того, что хочешь сделать в "конструкции", чтоб потом создать запрос в createQuery.
Я видел еще хуже примеры реализации, где подобным образом шел доступ к БД, но в динамике, т.е. нет конструирования запросов. В результате получалось, чтоб достучаться чего-либо выполнялось несколько запросов, а не один.
3. Сборка строк запросов явным образом, типа:
myString = "select * from MYTABLE t where t.id = " + idCode;
Угу, самый "приятный" вариант.
P>2. Некая библиотека высокоуровневых объектов, посредсвом монипуляцией которыми идет неявный доступ к базе, типа:
<skip code> P>Это такой пример, в котором, на самом деле код не выполняется, а записывается последовательность того, что хочешь сделать в "конструкции", чтоб потом создать запрос в createQuery.
Тоже не плохо для тех случаев, где нельзя применить первый вариант.
P>Я видел еще хуже примеры реализации, где подобным образом шел доступ к БД, но в динамике, т.е. нет конструирования запросов. В результате получалось, чтоб достучаться чего-либо выполнялось несколько запросов, а не один.
Бяка
P>3. Сборка строк запросов явным образом, типа: P>
P>myString = "select * from MYTABLE t where t.id = " + idCode;
P>
Для небольших или простых запросов и это сгодится. Но не для того примера, что ты приводил Хотя суть та-же: строить запрос динамически в зависимости от.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Plague, Вы писали:
P>>2. Некая библиотека высокоуровневых объектов, посредсвом монипуляцией которыми идет неявный доступ к базе, типа:
AVK>Подобные фокусы в случае C# ныне лучше делать при помощи expression tree.
В целом expression tree будет такого же объема, но вот будет ли он при этом проще выглядеть... не знаю...
Плюс, там в Expression tree проиходит компиляция, а пройтись по этому дереву можно? Т.е. пройтись и сгенерировать запрос, иначе весь смысл теряется, т.к. важна только структура кода.
)
