Что не так с SQL?
От: Plague Россия  
Дата: 28.12.07 08:12
Оценка:
В последнее время все больше и больше кажется, что что-то не так с SQL. Не с конкретной реализацией, а вообще.
Вроде бы все замечательно, ну получаются запросы в 1-2 страницы текста — это нормально, но когда приходится изменить "чтоб немного по другому собирало", то приходится переписывать чуть ли не весь запрос. Безусловно, SQL в возможностях запросов данных довольно гибок, но вот костность в описательной структуре запроса удручает.
Что думает по этому поводу народ?
Re: Что не так с SQL?
От: deniok Россия  
Дата: 28.12.07 08:18
Оценка: +1
Здравствуйте, Plague, Вы писали:

P>В последнее время все больше и больше кажется, что что-то не так с SQL. Не с конкретной реализацией, а вообще.

P>Вроде бы все замечательно, ну получаются запросы в 1-2 страницы текста — это нормально, но когда приходится изменить "чтоб немного по другому собирало", то приходится переписывать чуть ли не весь запрос. Безусловно, SQL в возможностях запросов данных довольно гибок, но вот костность в описательной структуре запроса удручает.
P>Что думает по этому поводу народ?

Если ты видишь как свои "немного по-другому" формализовать, напиши DSL, генерирующий SQL
Re[2]: Что не так с SQL?
От: Курилка Россия http://kirya.narod.ru/
Дата: 28.12.07 08:32
Оценка: +1
Здравствуйте, deniok, Вы писали:

D>Здравствуйте, Plague, Вы писали:


P>>В последнее время все больше и больше кажется, что что-то не так с SQL. Не с конкретной реализацией, а вообще.

P>>Вроде бы все замечательно, ну получаются запросы в 1-2 страницы текста — это нормально, но когда приходится изменить "чтоб немного по другому собирало", то приходится переписывать чуть ли не весь запрос. Безусловно, SQL в возможностях запросов данных довольно гибок, но вот костность в описательной структуре запроса удручает.
P>>Что думает по этому поводу народ?

D>Если ты видишь как свои "немного по-другому" формализовать, напиши DSL, генерирующий SQL


А может стоит использовать язык другой, более гибкий и подходящий под задачу (вопрос, конечно, какую именно), скажем тот же K?
Re: Что не так с SQL?
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 28.12.07 08:52
Оценка: 5 (1) +1
Здравствуйте, Plague, Вы писали:

P>Что думает по этому поводу народ?


Не так с ним то, что в базовом SQL'92 крайне скудные возможности реюза. ИМХО следует стараться активнее использовать функции и CTE.
... << RSDN@Home 1.2.0 alpha rev. 725 on Windows Vista 6.0.6000.0>>
AVK Blog
Re[2]: Что не так с SQL?
От: Plague Россия  
Дата: 28.12.07 08:58
Оценка:
Здравствуйте, deniok, Вы писали:

D>Если ты видишь как свои "немного по-другому" формализовать, напиши DSL, генерирующий SQL


Если было бы все так просто... Конечно, понятно, что есть борьба и с производительностью БД, т.е. кроме требований получения данных надо собрать "оптимальный" запрос, т.е. чтоб работал приемлемо быстро (при заданных условиях). Итак, есть просто бескрайнее поле вариантов как именно сделать выборку данных, но на написание и опробование каждого уйдет уйма времени, поэтому несколько понимая как работает БД и по опыту собираешь так кажется более "оптимально". Но вдруг добавляется условие и встаешь перед дилеммой — переписать запрос, т.к. с учетом новых условий структура оптимального запроса должна быть несколько другой, ИЛИ сделать "подпорку" сделав очередной вложенный подзапрос и прочие такие не очень хорошие решения. %)

Понятно, что некоторые вещи можно решить использованием вьюх. Но по опыту работы иногда приходится от них отказываться, т.к. производительность запроса начинает желать лучшего. Да и когда количество вьюх не одна тысяча — задумываешься клепать ли новую... Так же дело в том на сколько вьюха должна быть простой, т.е. если вьюха сложная — ее тяжело использовать в сложных запросах из-за производительности (так как таких вьюх может быть использовано множество, да и они могут содержать сортировки и группировки, что дает нагрузку), т.е. легче отказаться от ее использования. Если она простая, то смысл использовать ее тоже под вопросом, т.к. на каждую комбинацию 2х-3х-4х таблиц не напишешь вьюху, т.е. количество вьюх стремительно расти.
В использовании вьюх вижу большой бонус в некой фильтрации данных, т.е. не просто сбор со всевозможными справочниками, а именно отбор данных с условиями.

DSL, конечно, прикольно было бы придумать. Т.е. описываешь на нем БД, а он уже собирает SQL-код для все БД.

PS. Мое негативное настроение повлияло, что есть БД (SQL Server 2005) в которой СОВСЕМ НЕТ вьюх и процедур, к которой можно делать только запросы и поэтому запросы получаются не в одну страницу. При этом в каждой таблице есть поле логического удаления записи, которое надо учитывать, множество таблиц связок и т.п., что нисколько не облегчает работу.
Re[2]: Что не так с SQL?
От: Plague Россия  
Дата: 28.12.07 09:04
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Не так с ним то, что в базовом SQL'92 крайне скудные возможности реюза. ИМХО следует стараться активнее использовать функции и CTE.

Да, CTE радует, т.к. можно вынести некий код из запроса как бы разделив, что значительно упрощает чтение и понимание. Даже комментарии нормально поставить к нему можно, т.к. когда есть гиганский запрос сложно объяснить в чем фишка соединения 15-20 таблиц. =)
Функции — согласен.
Re[2]: Что не так с SQL?
От: Plague Россия  
Дата: 28.12.07 09:20
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Не так с ним то, что в базовом SQL'92 крайне скудные возможности реюза. ИМХО следует стараться активнее использовать функции и CTE.

Единственная проблема CTE — это то, что реюз в рамках одного запроса, а хотелось бы более широкое использование, например в рамках процедуры или пакета.

PS. В Оракле в WITH можно использовать рекурсивный запрос? или нужно использовать CONNECT BY?
Re: Что не так с SQL?
От: Константин Л. Франция  
Дата: 28.12.07 09:31
Оценка:
Здравствуйте, Plague, Вы писали:

[]

Имхо там тупо не хватает что-то наподобие классов/свободных функций. Не знаю как объяснить, но чтобы можно было составлять нормальную композицию из каких-то запросов и тп
Re[3]: Что не так с SQL?
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 28.12.07 09:42
Оценка:
Здравствуйте, Plague, Вы писали:

AVK>>Не так с ним то, что в базовом SQL'92 крайне скудные возможности реюза. ИМХО следует стараться активнее использовать функции и CTE.

P>Единственная проблема CTE — это то, что реюз в рамках одного запроса, а хотелось бы более широкое использование, например в рамках процедуры или пакета.

Ну так inline функции это оно и есть.

P>PS. В Оракле в WITH можно использовать рекурсивный запрос? или нужно использовать CONNECT BY?


ХЗ. Я по Ораклу не специалист.
... << RSDN@Home 1.2.0 alpha rev. 725 on Windows Vista 6.0.6000.0>>
AVK Blog
Re: Что не так с SQL?
От: Quintanar Россия  
Дата: 28.12.07 15:09
Оценка: 5 (1) +1
Здравствуйте, Plague, Вы писали:

P>В последнее время все больше и больше кажется, что что-то не так с SQL. Не с конкретной реализацией, а вообще.

P>Вроде бы все замечательно, ну получаются запросы в 1-2 страницы текста — это нормально, но когда приходится изменить "чтоб немного по другому собирало", то приходится переписывать чуть ли не весь запрос. Безусловно, SQL в возможностях запросов данных довольно гибок, но вот костность в описательной структуре запроса удручает.
P>Что думает по этому поводу народ?

Это, наверно, из-за того, что SQL задумывался как простой язык для широкого круга пользователей (читай домохозяек), но на деле вышло, что использовать его стали иначе и, в основном, профессиональные программисты, которым эта простота совсем не нужна, если ради нее приходится жертвовать производительностью и выразительностью. Но что сделано, то сделано, остается только прикручивать к ядру SQL фичи, устраняющие некоторые его недостатки, добавлять спец языки типа tsql и прочее.
Есть, правда, диалекты SQL совмещенные с нормальным языком программирования (Q в kdb+), где у программиста есть вся власть над ядром БД, он всегда знает, что происходит и почему и ничего не оптимизируется автоматически. Т.е. можно сразу писать оптимальный запрос на основе знаний о структуре БД, не пользуясь никакими анализаторами. В результате получаем гибкость обычного языка программирования совмещенную с мощью SQL, в таких условиях запросы укорачиваются, а понятность программы возрастает.
Re[3]: Что не так с SQL?
От: Lloyd Россия  
Дата: 28.12.07 16:08
Оценка: +3
Здравствуйте, Plague, Вы писали:

P>PS. Мое негативное настроение повлияло, что есть БД (SQL Server 2005) в которой СОВСЕМ НЕТ вьюх и процедур, к которой можно делать только запросы и поэтому запросы получаются не в одну страницу.


Как это "СОВСЕМ НЕТ"?
Re[2]: Что не так с SQL?
От: cl-user  
Дата: 29.12.07 09:03
Оценка:
Здравствуйте, Quintanar, Вы писали:

Q>Есть, правда, диалекты SQL совмещенные с нормальным языком программирования (Q в kdb+), где у программиста есть вся власть над ядром БД, он всегда знает, что происходит и почему и ничего не оптимизируется автоматически.


А "не автоматическая" но и "не ручная" (а-ля "по запросу") оптимизация есть? Или я должен написать половину Оракла?

Q>Т.е. можно сразу писать оптимальный запрос на основе знаний о структуре БД, не пользуясь никакими анализаторами.


А если я вдруг захочу использовать оптимизаторы — "их там есть"?

Q>В результате получаем гибкость обычного языка программирования совмещенную с мощью SQL, в таких условиях запросы укорачиваются, а понятность программы возрастает.


Не понял, как может запрос укоротиться, если мне самому на основании данных "с потолка" придётся указывать: вот здесь делать индексный поиск, а вот здесь fullscan, а вот здесь ты сам проанализируй состав данных и реши какой тип поиска использовать... Да, ещё надо учитывать нахождение данных в кэше (а кто их знает, есть они там или нет...)

Да, для каких-то случаев возможно Ваш способ и будет "гибче и мощнее", но для каждого случая надо анализировать отдельно — какой подход что даст. Ибо SQL это не просто какой-то "язычёк", это, в первую очередь, математика. Плюс "тонны" человеко-лет по оптимизации обработки запросов. А Вы одним махом "на... всю оптимизацию!"
Re[3]: Что не так с SQL?
От: Quintanar Россия  
Дата: 29.12.07 12:03
Оценка:
Здравствуйте, cl-user, Вы писали:

CU>А "не автоматическая" но и "не ручная" (а-ля "по запросу") оптимизация есть? Или я должен написать половину Оракла?


Нет. Хотите — пишите.

CU>А если я вдруг захочу использовать оптимизаторы — "их там есть"?


А что вы будете оптимизировать?

CU>Не понял, как может запрос укоротиться, если мне самому на основании данных "с потолка" придётся указывать: вот здесь делать индексный поиск, а вот здесь fullscan, а вот здесь ты сам проанализируй состав данных и реши какой тип поиска использовать... Да, ещё надо учитывать нахождение данных в кэше (а кто их знает, есть они там или нет...)


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

CU>Да, для каких-то случаев возможно Ваш способ и будет "гибче и мощнее", но для каждого случая надо анализировать отдельно — какой подход что даст. Ибо SQL это не просто какой-то "язычёк", это, в первую очередь, математика. Плюс "тонны" человеко-лет по оптимизации обработки запросов. А Вы одним махом "на... всю оптимизацию!"


Еще раз повторяю, это не универсальная БД, а узкоспециализированная и требовательная к ресурсам. Свои задачи она полностью решает, программист может писать запросы сразу самым оптимальным в рамках БД способом без всяких там анализаторов и оптимизаторов. Когда нужно обрабатывать миллионы записей в секунду, оптимизаторы идут на юг.
Математикой пугать не надо, реляционная алгебра — это уровень спецкурса 10-го класса средней школы с математическим уклоном.

>>Плюс "тонны" человеко-лет по оптимизации обработки запросов.


Только до сих пор анализатор запроса — это вещь, жизненно необходимая для того, чтобы указать машине, что на самом деле нужно делать.
Re[4]: Что не так с SQL?
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 29.12.07 12:15
Оценка:
Здравствуйте, Quintanar, Вы писали:

CU>>А если я вдруг захочу использовать оптимизаторы — "их там есть"?


Q>А что вы будете оптимизировать?


Ну, например, если есть джойн, нужно принять решение, какую его часть нужно выбирать первой, а какую второй.
... << RSDN@Home 1.2.0 alpha rev. 725 on Windows Vista 6.0.6000.0>>
AVK Blog
Re[5]: Что не так с SQL?
От: Quintanar Россия  
Дата: 29.12.07 12:18
Оценка:
Здравствуйте, AndrewVK, Вы писали:

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


Это определяется порядком аргументов у функций, которые имеют смысл join. Если по foreign key — key, то вообще ничего явно указывать не нужно.
Re[6]: Что не так с SQL?
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 29.12.07 12:30
Оценка:
Здравствуйте, Quintanar, Вы писали:

Q>Это определяется порядком аргументов у функций, которые имеют смысл join.


Да, таким манером ты серьезную производительность получишь .
... << RSDN@Home 1.2.0 alpha rev. 725 on Windows Vista 6.0.6000.0>>
AVK Blog
Re[7]: Что не так с SQL?
От: Quintanar Россия  
Дата: 29.12.07 12:38
Оценка: :)
Здравствуйте, AndrewVK, Вы писали:

AVK>Да, таким манером ты серьезную производительность получишь .


Не жалуются. Во всяком случае, на Oracle менять никому и в кошмарном сне не приснится. Оракл — тормозня.
Re[3]: Что не так с SQL?
От: VladD2 Российская Империя www.nemerle.org
Дата: 29.12.07 13:01
Оценка:
Здравствуйте, Курилка, Вы писали:

К>А может стоит использовать язык другой, более гибкий и подходящий под задачу (вопрос, конечно, какую именно), скажем тот же K?


А может не надо к? А? (с чувством безутешной надежды в голосе)
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Что не так с SQL?
От: deniok Россия  
Дата: 29.12.07 14:24
Оценка: +1
Здравствуйте, VladD2, Вы писали:

VD>А может не надо к? А? (с чувством безутешной надежды в голосе)


Не хочешь злобный k — пользуй высокоуровневый q.
Re[4]: Что не так с SQL?
От: cl-user  
Дата: 03.01.08 11:14
Оценка: +1
Здравствуйте, Quintanar, Вы писали:

Q>Еще раз повторяю, это не универсальная БД, а узкоспециализированная и требовательная к ресурсам. Свои задачи она полностью решает, программист может писать запросы сразу самым оптимальным в рамках БД способом без всяких там анализаторов и оптимизаторов. Когда нужно обрабатывать миллионы записей в секунду, оптимизаторы идут на юг.


"Ещё раз" — это где? В этом топике не было.
А если вы о том, что для оптимальной работы _вся_ база должна быть в памяти + прочие ограничения на "сложную логику", то с этого и надо было начинать. Для "общего употребления" не годится, ибо по "узкоспециализированным предписаниям".

Q>Математикой пугать не надо, реляционная алгебра — это уровень спецкурса 10-го класса средней школы с математическим уклоном.


А в "узкоспециализированной" её (математики) сколько?

Q>Только до сих пор анализатор запроса — это вещь, жизненно необходимая для того, чтобы указать машине, что на самом деле нужно делать.


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

Ладно, можно "завязывать" — теперь я вас понял и посему претензий не имею
Re: Что не так с SQL?
От: GlebZ Россия  
Дата: 06.01.08 11:15
Оценка:
Здравствуйте, Plague, Вы писали:

P>В последнее время все больше и больше кажется, что что-то не так с SQL. Не с конкретной реализацией, а вообще.

С SQL — все так. В-первых, это язык запросов. Для задач более специализированных, почти в каждой БД есть более мощный язык. Во-вторых, если тебе нужна борьба со сложностью, считай инкапсуляция, то для этого есть и различные ORM с автоматическими построителями запросов, и те же встроенные в БД сохраняемые функции. Функций легко трансформируются в запросы. Ну а в третьих — есть трабла. Несмотря на всю декларативность, SQL имеет одно преимущество — он может рассказать СУБД не только что нужно сделать, но и как это нужно сделать. Существует множество причин почему программист может построить реляционный запрос лучше чем самый лучший современный оптимизатор. Например, то, что в реляционке не хватает всех требуемых знаний о семантике данных. И тут нравится или не нравится, SQL — нет альтернатив. А инкапсуляция, будет только мешать данной задаче.
Re[5]: Что не так с SQL?
От: Quintanar Россия  
Дата: 06.01.08 19:44
Оценка:
Здравствуйте, cl-user, Вы писали:

CU>А если вы о том, что для оптимальной работы _вся_ база должна быть в памяти + прочие ограничения на "сложную логику", то с этого и надо было начинать. Для "общего употребления" не годится, ибо по "узкоспециализированным предписаниям".


Ну, не вся, но логика работы с очень большими базами прозрачна и опирается на дисковый кеш ОС. Это мне кажется, кстати, более логичным, чем изобретение своих кешей. И так на буквально каждом уровне все пытаются что-то кешировать и диск, и драйвер устройства, и файловая система и база данных. Итогом может быть торможение.
Хотел бы напомнить, что изначально речь шла об SQL, а не промышленных БД. Реляционными базами и SQL можно пользоваться самими по себе, как хеш-таблицами или списками. Очень удобно, знаете ли, оперировать данными в терминах таблиц и запросов.

CU>Естественно. В тех случаях когда _все_ данные _гарантированно_ не лезут в память, когда какая-то их часть уже может быть в кэше, всех или уже отобранных по подобному критерию... — т.е. когда "что делать" зависит от текущего состояния дел, которое в момент написания запроса неизвестно. И опять же — короче ваш "подробный" запрос не будет.


Звучит очень сложно. Наверно, это очень дорого писать мегаумные анализаторы и многоуровневые кеши на все случаи жизни. Гораздо легче прикупить сотню гигабайт оперативной памяти и дать легкий эффективный и прозрачный движок для БД. А всем, кому это не нравится (дяде Васе с овощного склада) показать на дверь.

CU>Ладно, можно "завязывать" — теперь я вас понял и посему претензий не имею


Прощаю всех, кого обидел?
Re[6]: Что не так с SQL?
От: cl-user  
Дата: 08.01.08 08:03
Оценка:
Здравствуйте, Quintanar, Вы писали:

Q>Ну, не вся, но логика работы с очень большими базами прозрачна и опирается на дисковый кеш ОС. Это мне кажется, кстати, более логичным, чем изобретение своих кешей.


Ну не надо считать разработчиков Oracle полными идиотами. Они там сделали возможность создавать тома вообще без FS — видать таки "собственное" кэширование было оптимальнее.

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


_Может быть_ и даст торможение, а может дать и выигрыш. Если ты не в состоянии управлять кэшем "нижнего уровня" — приходится самому дублировать некоторые функции, если использование кэша критично.

Q>Хотел бы напомнить, что изначально речь шла об SQL, а не промышленных БД. Реляционными базами и SQL можно пользоваться самими по себе, как хеш-таблицами или списками. Очень удобно, знаете ли, оперировать данными в терминах таблиц и запросов.


Не знаю. Вернее забыл с тех пор, как бросил FoxPro фиг знает какой версии и перешёл к базам с поддержкой SQL, многие из которых даже предоставляя _прямой_ доступ к таблицам предупреждали — пользуйтесь SQL — будет быстрее

Q>Звучит очень сложно. Наверно, это очень дорого писать мегаумные анализаторы и многоуровневые кеши на все случаи жизни.


Спросите у Oracle. Да и PostgreSQL в последнее время неплохо "подтянулся" — можете глянуть сразу в source.

Q>Гораздо легче прикупить сотню гигабайт оперативной памяти и дать легкий эффективный и прозрачный движок для БД.


Вот как раз это более походит на "промышленное использование". А ежели данных просто _много_, но используются они не слишком интенсивно (подозреваю ~95% использования всех БД — но это исключительно моя т.з.) — зачем добавлять память? И уж тем более на обычных end-user компах? Опять же другая "крайность" — однопользовательская маленькая база, но скорость опять не слишком критична: берите SQLite — и нет проблем. Зачем заниматься "битовыжиманием" там, где это не критично?

Q>А всем, кому это не нравится (дяде Васе с овощного склада) показать на дверь.


"Нет бога кроме Аллаха..."

CU>>Ладно, можно "завязывать" — теперь я вас понял и посему претензий не имею


Q>Прощаю всех, кого обидел?


Я? Обидел?!!!!! Не, вы меня с кем-то перепутали
Re[4]: Что не так с SQL?
От: Plague Россия  
Дата: 09.01.08 10:56
Оценка:
Здравствуйте, 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. Например, способы именования таблиц и процедур, использования и именования алиасов с целью более легкой читабельности кода и т.п.
Re[2]: Что не так с SQL?
От: Plague Россия  
Дата: 09.01.08 10:59
Оценка:
Здравствуйте, GlebZ, Вы писали:

--- SKIP

Чтоб не повторятся, отписался тебе и Lloyd в ветке выше. :)
Автор: Plague
Дата: 09.01.08
Re[5]: Что не так с SQL?
От: cl-user  
Дата: 09.01.08 12:00
Оценка:
Здравствуйте, Plague, Вы писали:

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


P>Итого — получается запрос, который содержит в себе связку кучи таблиц, при этом с множеством описаний как и какие таблицы связывать, условиями статуса записи, условиями состояния записи и т.п., потому запросы состоят из 100-300 строк, примерно (чистым кодом, без пробелов, 3-8кб один запрос)...


У меня есть подозрение, что я "мимо тазика", но у меня, если размер запроса превышал несколько строк, он, как правило, "генерился" функцией приложения, внутри которой можно и параметров напихать, и "реюзать" то, что хочется (естественно _построение_ запроса, а не его части), и "камментов" напихать и т.п. и т.д. Потери на парсинг запроса (по сравнению с сохранённым в базе) малы по сравнению со временем его работы.
Re[6]: Что не так с SQL?
От: Plague Россия  
Дата: 09.01.08 12:42
Оценка:
Здравствуйте, 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 не подсвечиваются раскраской...
Re[7]: Что не так с SQL?
От: cl-user  
Дата: 09.01.08 12:59
Оценка:
Здравствуйте, Plague, Вы писали:

P>Ну вот пример немного "отрефакторенного" запроса с добавленным учетом деревьев. Используется 12 таблиц, 4 параметра, два из которых — списки. =)

P>Что именно тут генерировать? Это некий примерный запрос для отчета. Тут выборка с учетом выбора элементов дерева, расставление и сортировка для системы отчетов, т.е. чтоб осталось только вывести данные.
P>Комменты удалил, таблицы переименовал. Этот запрос еще нормально читается. Есть те, что слабо читаются. Вот вопрос в том, как сделать более легким переписывание подобных запросов.

<skip sql>

Генерировать — всё Т.е. весь текст. Как "бить на отдельные части"? То что взаимосвязано (поля, таблицы, связи) — однозначно генерить, то что наиболее вероятно может измениться — отдельно генерить. Каждый подзапрос — тоже (хотя может быть и перебор). Кода получится в два раза больше, но если код осмысленный с осмысленными подсказками — править будет действительно на порядок легче, нежели "парсить" в голове готовый запрос и пытаться изменить.
Re[8]: Что не так с SQL?
От: Plague Россия  
Дата: 09.01.08 13:34
Оценка:
Здравствуйте, cl-user, Вы писали:

CU>Генерировать — всё Т.е. весь текст. Как "бить на отдельные части"? То что взаимосвязано (поля, таблицы, связи) — однозначно генерить, то что наиболее вероятно может измениться — отдельно генерить. Каждый подзапрос — тоже (хотя может быть и перебор). Кода получится в два раза больше, но если код осмысленный с осмысленными подсказками — править будет действительно на порядок легче, нежели "парсить" в голове готовый запрос и пытаться изменить.


Генерировать? как ты это представляешь? (опустим то, что у меня кроме как к SQL доступа нет, но интересно) Не получится ли, что все ще сильней усложнится? Не легче ли будет сделать SQL-like DSL язык знающий специфику и особенности структуры, который будет генерировать SQL запрос?
Если не использовать DSL, то при использовании мэйнстримовых языков для генерации (как это делают, к примеру в PHP ) получится все гораздо сложнее, т.к. часть логики выборки будет содержаться в "генераторе", а часть в запросе. А что если кто-то будет делать вложенные генераторы и т.п.? не.. лучше пусть будут "чистые" и ёмкие запросы.
Re[5]: Что не так с SQL?
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 09.01.08 15:26
Оценка:
Здравствуйте, 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;
... << RSDN@Home 1.2.0 alpha rev. 725>>
AVK Blog
Re[8]: Аськой прибило
От: Plague Россия  
Дата: 09.01.08 21:31
Оценка:
Здравствуйте, Quintanar, Вы писали:

Q>Не жалуются. Во всяком случае, на Oracle менять никому и в кошмарном сне не приснится. Оракл — тормозня.

Вот ebay.com так не думает... =) и еще много кто и много где использует Oracle. Да он не быстр на маленьком объеме данных, но именно на большом объеме раскрывается потециал. Все-таки стоимостная оптимизация это весчъ! Правда, это не значит, что надо оставить БД на произвол судьбы, надо считать статистику и т.п., а БД сама решит как именно быстрей, т.к. связки inner join можно перебирать в любом порядке, но от порядка изменится порядок чтения записей и проверки условий, а главную роль будет играть количество прочитанных записей, т.е. учитывая статистику по таблице, количество записей и т.п., Сервер сокращает в разы количество чтений.

Но это только одна сторона, а есть еще не одна тысяча пользователей, которая сама пишет и читает что хочет...
Что-то, мне показалось, что описаный тобой подход в чем то смахивает на простоту Foxpro... там тоже все просто, четко и главное быстро...
Re[9]: Аськой прибило
От: Cyberax Марс  
Дата: 09.01.08 21:41
Оценка:
Здравствуйте, Plague, Вы писали:

Q>>Не жалуются. Во всяком случае, на Oracle менять никому и в кошмарном сне не приснится. Оракл — тормозня.

P>Вот ebay.com так не думает... =) и еще много кто и много где использует Oracle.
AFAIR, Ebay использует какую-то свою распределенную систему, где даже join'ы вручную оптимизируются.
Sapienti sat!
Re[10]: Аськой прибило
От: Plague Россия  
Дата: 10.01.08 07:08
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>AFAIR, Ebay использует какую-то свою распределенную систему, где даже join'ы вручную оптимизируются.

здесь можно посмотреть что у них и как

PS. Что-то странный у меня Сабж. Вроде ничего такого не писал. =)
Re[6]: Что не так с SQL?
От: Plague Россия  
Дата: 10.01.08 07:32
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Ну а что? Вполне нормальное решение, не требующее от БД снижения универсальности из-за усложнения метаданных.

AVK>Вот, у нас в текущем проекте есть примерно такое:
AVK>
AVK>USING Parus.Business.Octopus;

AVK>DECLARE @InstalledProduct AS InstalledProduct;

AVK>SELECT DISTINCT InstalledProductUpdate.ModelDataBasePackage.Master.Identity
AVK>FROM InstalledProductUpdate
AVK>WHERE InstalledProductUpdate.Master = @InstalledProduct;
AVK>


Ну да, вот такое было бы супер! Но если вам потребовалось использовать DSL, то значит в SQL не хватает гибкости.
У вас используются собственные наработки или есть какие-то существующие наработки для разработки? )

В DSL есть еще бонус в том, что генерация конструкций под конкретный SQL сервер может не снижать эффективности его использования. Эдакая серебрянная пуля. =)))
Re[7]: Что не так с SQL?
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 10.01.08 07:57
Оценка:
Здравствуйте, Plague, Вы писали:

P>Ну да, вот такое было бы супер! Но если вам потребовалось использовать DSL, то значит в SQL не хватает гибкости.


Не совсем так. Дело не в гибкости SQL, а в наличии неких специфических метаданных.

P>У вас используются собственные наработки или есть какие-то существующие наработки для разработки? )


У нас собственные.
... << RSDN@Home 1.2.0 alpha rev. 725>>
AVK Blog
Re[9]: Что не так с SQL?
От: cl-user  
Дата: 10.01.08 08:54
Оценка:
Здравствуйте, Plague, Вы писали:

P>Генерировать? как ты это представляешь? (опустим то, что у меня кроме как к SQL доступа нет, но интересно) Не получится ли, что все ще сильней усложнится? Не легче ли будет сделать SQL-like DSL язык знающий специфику и особенности структуры, который будет генерировать SQL запрос?


Я хотел об этом написать, но подумал — не так поймут

P>Если не использовать DSL, то при использовании мэйнстримовых языков для генерации (как это делают, к примеру в PHP ) получится все гораздо сложнее, т.к. часть логики выборки будет содержаться в "генераторе", а часть в запросе. А что если кто-то будет делать вложенные генераторы и т.п.? не.. лучше пусть будут "чистые" и ёмкие запросы.


Сорри, не догнал. Вся логика _построения_ запроса будет в генераторе (ну может быть ещё плюс в каких-то шаблонах — не суть важно). Вложенные генераторы конечно могут быть. Можно провести аналогию с сохранёнными вьюшками. Что не так?
Re[10]: Что не так с SQL?
От: Plague Россия  
Дата: 10.01.08 09:37
Оценка:
Здравствуйте, cl-user, Вы писали:

Я просто не понял, что ты имеешь ввиду под словом "генератор"?

CU>Сорри, не догнал. Вся логика _построения_ запроса будет в генераторе (ну может быть ещё плюс в каких-то шаблонах — не суть важно). Вложенные генераторы конечно могут быть. Можно провести аналогию с сохранёнными вьюшками. Что не так?


Я вижу три способа:
1. DSL, примерно как показано в сообщении AndrewVK
Автор: AndrewVK
Дата: 09.01.08
.
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;
Re[11]: Что не так с SQL?
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 10.01.08 14:40
Оценка:
Здравствуйте, Plague, Вы писали:

P>2. Некая библиотека высокоуровневых объектов, посредсвом монипуляцией которыми идет неявный доступ к базе, типа:


Подобные фокусы в случае C# ныне лучше делать при помощи expression tree.
... << RSDN@Home 1.2.0 alpha rev. 725>>
AVK Blog
Re[11]: Что не так с SQL?
От: cl-user  
Дата: 11.01.08 08:03
Оценка:
Здравствуйте, Plague, Вы писали:

P>Я вижу три способа:

P>1. DSL, примерно как показано в сообщении AndrewVK
Автор: AndrewVK
Дата: 09.01.08
.


Угу, самый "приятный" вариант.

P>2. Некая библиотека высокоуровневых объектов, посредсвом монипуляцией которыми идет неявный доступ к базе, типа:

<skip code>
P>Это такой пример, в котором, на самом деле код не выполняется, а записывается последовательность того, что хочешь сделать в "конструкции", чтоб потом создать запрос в createQuery.

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

P>Я видел еще хуже примеры реализации, где подобным образом шел доступ к БД, но в динамике, т.е. нет конструирования запросов. В результате получалось, чтоб достучаться чего-либо выполнялось несколько запросов, а не один.


Бяка

P>3. Сборка строк запросов явным образом, типа:

P>
P>myString = "select * from MYTABLE t where t.id = " + idCode;
P>


Для небольших или простых запросов и это сгодится. Но не для того примера, что ты приводил Хотя суть та-же: строить запрос динамически в зависимости от.
Re[12]: Что не так с SQL?
От: Plague Россия  
Дата: 11.01.08 13:49
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, Plague, Вы писали:


P>>2. Некая библиотека высокоуровневых объектов, посредсвом монипуляцией которыми идет неявный доступ к базе, типа:


AVK>Подобные фокусы в случае C# ныне лучше делать при помощи expression tree.

В целом expression tree будет такого же объема, но вот будет ли он при этом проще выглядеть... не знаю...

Плюс, там в Expression tree проиходит компиляция, а пройтись по этому дереву можно? Т.е. пройтись и сгенерировать запрос, иначе весь смысл теряется, т.к. важна только структура кода.
Re[13]: Что не так с SQL?
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 11.01.08 17:54
Оценка:
Здравствуйте, Plague, Вы писали:

AVK>>Подобные фокусы в случае C# ныне лучше делать при помощи expression tree.

P>В целом expression tree будет такого же объема

В смысле? Больше объема исходников? Нет конечно, существенно меньше, особенно на сложных запросах

P>, но вот будет ли он при этом проще выглядеть... не знаю...


Не знаю насчет проще, но, как минимум, компилятор проверит типы.

P>Плюс, там в Expression tree проиходит компиляция, а пройтись по этому дереву можно?


Вот как раз expression tree тем и характерен, что, в отличие от обычной лямбды, не компилируется.
... << RSDN@Home 1.2.0 alpha rev. 725 on Windows Vista 6.0.6000.0>>
AVK Blog
Re[14]: Что не так с SQL?
От: Plague Россия  
Дата: 14.01.08 07:45
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Вот как раз expression tree тем и характерен, что, в отличие от обычной лямбды, не компилируется.


Возможно, я смотрел не те примеры... в примерах он как раз компилируется... :hz:
Плюс, мы говорим, что должна присутвовать генерация SQL запроса, а я что-то себе не представляю как по Expression tree оно будет генерится...
Re[15]: Что не так с SQL?
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 14.01.08 08:45
Оценка:
Здравствуйте, Plague, Вы писали:

P>Возможно, я смотрел не те примеры... в примерах он как раз компилируется... :hz:


Наверно.

P>Плюс, мы говорим, что должна присутвовать генерация SQL запроса, а я что-то себе не представляю как по Expression tree оно будет генерится...


Ну вот как то Linq2SQL генерирует.
... << RSDN@Home 1.2.0 alpha rev. 725 on Windows Vista 6.0.6000.0>>
AVK Blog
Re[16]: Что не так с SQL?
От: Plague Россия  
Дата: 14.01.08 15:42
Оценка:
Здравствуйте, AndrewVK, Вы писали:

AVK>Ну вот как то Linq2SQL генерирует.

Да, глянул, прикольно, но все равно нет клево как DSL... =)
Re[11]: Аськой прибило
От: Cyberax Марс  
Дата: 16.01.08 06:24
Оценка:
Plague wrote:
> C>AFAIR, Ebay использует какую-то свою распределенную систему, где даже
> join'ы вручную оптимизируются.
> здесь можно посмотреть что у них и как
> <http://www.addsimplicity.com/downloads/eBaySDForum2006-11-29.pdf&gt;
Ну да, они там с базы почти всю нагрузку снимают — никакой ссылочной
целостности, триггеров, бизнес-логики и минимальные транзакции.
Posted via RSDN NNTP Server 2.1 beta
Sapienti sat!
Re: Что не так с SQL?
От: Sinclair Россия https://github.com/evilguest/
Дата: 17.01.08 04:01
Оценка: 11 (3)
Здравствуйте, Plague, Вы писали:

P>В последнее время все больше и больше кажется, что что-то не так с SQL. Не с конкретной реализацией, а вообще.

P>Вроде бы все замечательно, ну получаются запросы в 1-2 страницы текста — это нормально, но когда приходится изменить "чтоб немного по другому собирало", то приходится переписывать чуть ли не весь запрос. Безусловно, SQL в возможностях запросов данных довольно гибок, но вот костность в описательной структуре запроса удручает.
P>Что думает по этому поводу народ?
Лично я думаю, что в SQL все-таки маловато выразительности, что и приводит к раздуванию текстов и ухудшению читаемости.
Основные проблемы:
1. Главное препятствие декомпозиции — отсутствие в стандарте параметризованных view. В итоге, вместо того, чтобы легким манием руки приджойнить EmployeeOrders(Name) мы пишем join EmployeeOrders where EmployeeName = Name.
2. Второе препятствие декомпозиции — отсутствие в стандарте способа задания открытых view. В итоге совершенно невозможно написать ничего подобного этому:
create view InProgress(TaskTable @tablename) as
select * from @tableName where status in ("open", "assigned", "verifying")

И применять ко всем подходящим таблицам.

3. Невозможность использовать алиасы для скалярных выражений. В order by можно хотя бы указать цифру, но в остальных местах приходится честно переписывать все нужные выражения. Ну вот нахрена вот это все:
select DatePart(w, saleDate) as WeekNumber, Sum(orderTotal) as WeekTotal from orders
 where DatePart(w, saleDate) between @startWeek and @endWeek
 group by DatePart(w, saleDate)
 order by 1 desc

? Да, есть альтернатива:
select WeekNumber, WeekTotal from
(select DatePart(w, saleDate) as WeekNumber, Sum(orderTotal) as WeekTotal from orders
 group by DatePart(w, saleDate)
)
 where WeekNumber between @startWeek and @endWeek
 order by 1 desc

Но она ненамного лучше. И это еще короткий список полей. В чуть более реалистичном случае экономии на алиасах практически не будет из-за нудных перечислений под Select.

4. Жутко многословный синтаксис джойнов. Нет, я понимаю всю красоту идеи, но 99% джойнов — это equality join по foreign key. Синтаксис этого никак не отражает. Поддержка упрощенного синтаксиса FK-джойнов была бы офигенным улучшением, сокращающим большинство запросов на порядок. Примерно так:
select o.*, ow.Name from orders o
join constraint Owner as ow// === inner join Employee on Employee.ID = Order.EmployeeID

Это я предполагаю, что в таблице Orders есть именованный constraint:
foreign key constraint Owner(EmployeeID) references Employee(ID)

Или вообще вот так:
select o.*, o.Owner.Name from orders o

Т.е. употребление конструкции o.Owner автоматически приджойнивает таблицу, указанную в соответствующем FK.

Других идей у меня пока нет.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[2]: Что не так с SQL?
От: Lloyd Россия  
Дата: 17.01.08 06:35
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>3. Невозможность использовать алиасы для скалярных выражений. В order by можно хотя бы указать цифру, но в остальных местах приходится честно переписывать все нужные выражения. Ну вот нахрена вот это все:

S>
S>select DatePart(w, saleDate) as WeekNumber, Sum(orderTotal) as WeekTotal from orders
S> where DatePart(w, saleDate) between @startWeek and @endWeek
S> group by DatePart(w, saleDate)
S> order by 1 desc
S>

S>? Да, есть альтернатива:
S>
S>select WeekNumber, WeekTotal from
S>(select DatePart(w, saleDate) as WeekNumber, Sum(orderTotal) as WeekTotal from orders
S> group by DatePart(w, saleDate)
S>)
S> where WeekNumber between @startWeek and @endWeek
S> order by 1 desc
S>

S>Но она ненамного лучше. И это еще короткий список полей. В чуть более реалистичном случае экономии на алиасах практически не будет из-за нудных перечислений под Select.

Можно еще with для этого использовать.
... << RSDN@Home 1.2.0 alpha rev. 786>>
Re[3]: Что не так с SQL?
От: Sinclair Россия https://github.com/evilguest/
Дата: 17.01.08 08:48
Оценка:
Здравствуйте, Lloyd, Вы писали:
L>Можно еще with для этого использовать.
Принципиальной разницы это не обеспечивает.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[4]: Что не так с SQL?
От: Lloyd Россия  
Дата: 17.01.08 08:57
Оценка:
Здравствуйте, Sinclair, Вы писали:

L>>Можно еще with для этого использовать.

S>Принципиальной разницы это не обеспечивает.

Это позволяет использовать alias.
... << RSDN@Home 1.2.0 alpha rev. 786>>
Re[5]: Что не так с SQL?
От: Sinclair Россия https://github.com/evilguest/
Дата: 17.01.08 11:20
Оценка:
Здравствуйте, Lloyd, Вы писали:

L>Это позволяет использовать alias.

Это принципиально только для рекурсивных запросов. Попробуй переписать мой пример с CTE и убедишься, что это всего лишь перестановка мест слагаемых.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[6]: Что не так с SQL?
От: Lloyd Россия  
Дата: 17.01.08 11:27
Оценка:
Здравствуйте, Sinclair, Вы писали:

L>>Это позволяет использовать alias.

S>Это принципиально только для рекурсивных запросов. Попробуй переписать мой пример с CTE

Переписал
WITH XXX(WeekNumber, orderTotal) AS
(
    DatePart(w, saleDate), orderTotal from orders
)
SELECT WeekNumber, SUM(orderTotal) AS WeekTotal 
FROM XXX
WHERE WeekNumber between @startWeek and @endWeek
GROUP BY WeekNumber
ORDER BY WeekNumber



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

Не убедился.
... << RSDN@Home 1.2.0 alpha rev. 786>>
Re[2]: Что не так с SQL?
От: Quintanar Россия  
Дата: 17.01.08 11:31
Оценка:
Здравствуйте, Sinclair, Вы писали:

Есть варианты SQL без этих проблем. Например Q.

S>1. Главное препятствие декомпозиции — отсутствие в стандарте параметризованных view. В итоге, вместо того, чтобы легким манием руки приджойнить EmployeeOrders(Name) мы пишем join EmployeeOrders where EmployeeName = Name.


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

S>2. Второе препятствие декомпозиции — отсутствие в стандарте способа задания открытых view. В итоге совершенно невозможно написать ничего подобного этому:

S>
S>create view InProgress(TaskTable @tablename) as
S>select * from @tableName where status in ("open", "assigned", "verifying")
S>

S>И применять ко всем подходящим таблицам.

Эта задача решается функциями:
InProgress:{select from x where status in `open`assigned`verifying

S>3. Невозможность использовать алиасы для скалярных выражений. В order by можно хотя бы указать цифру, но в остальных местах приходится честно переписывать все нужные выражения. Ну вот нахрена вот это все:

S>
S>select DatePart(w, saleDate) as WeekNumber, Sum(orderTotal) as WeekTotal from orders
S> where DatePart(w, saleDate) between @startWeek and @endWeek
S> group by DatePart(w, saleDate)
S> order by 1 desc
S>

S>? Да, есть альтернатива:
S>
S>select WeekNumber, WeekTotal from
S>(select DatePart(w, saleDate) as WeekNumber, Sum(orderTotal) as WeekTotal from orders
S> group by DatePart(w, saleDate)
S>)
S> where WeekNumber between @startWeek and @endWeek
S> order by 1 desc
S>

S>Но она ненамного лучше. И это еще короткий список полей. В чуть более реалистичном случае экономии на алиасах практически не будет из-за нудных перечислений под Select.

Тут, я так понял, идет речь и чисто текстовом алиасе, поскольку WeekNumber в select совсем не тот, что DatePart(..) в where. Набор данных они обозначают разный. В Q таких алиасов нет, но можно использовать функции, если выражение сложное или забить, поскольку group все равно нет.
[quote]
f:{DatePart(w,x)}
desc select WeekTotal: sum orderTotal by WeekNumber:f[saleDate] from orders where f[saleDate] within (startWeek;endWeek)

or

desc select from (select WeekTotal:sum orderTotal by WeekNumber:DatePart(w,saleDate)) where WeekNumber within (startWeek;endWeek)
[/quote]

S>4. Жутко многословный синтаксис джойнов. Нет, я понимаю всю красоту идеи, но 99% джойнов — это equality join по foreign key. Синтаксис этого никак не отражает. Поддержка упрощенного синтаксиса FK-джойнов была бы офигенным улучшением, сокращающим большинство запросов на порядок. Примерно так:

S>
S>select o.*, ow.Name from orders o
S>join constraint Owner as ow// === inner join Employee on Employee.ID = Order.EmployeeID
S>

S>Это я предполагаю, что в таблице Orders есть именованный constraint:
S>
S>foreign key constraint Owner(EmployeeID) references Employee(ID)
S>

S>Или вообще вот так:
S>
S>select o.*, o.Owner.Name from orders o
S>

S>Т.е. употребление конструкции o.Owner автоматически приджойнивает таблицу, указанную в соответствующем FK.

Именно так и сделано в Q:
Если у t1 ключ a и еще есть столбец b, а у t2 есть foreign key a ссылающийся на t1.a и столбец с, то можно писать так:
select c, a.b from t2 where a.b>10
Re[7]: Что не так с SQL?
От: Sinclair Россия https://github.com/evilguest/
Дата: 17.01.08 11:42
Оценка:
Здравствуйте, Lloyd, Вы писали:


L>Переписал

L>
L>WITH XXX(WeekNumber, orderTotal) AS
L>(
L>    DatePart(w, saleDate), orderTotal from orders
L>)
L>SELECT WeekNumber, SUM(orderTotal) AS WeekTotal 
L>FROM XXX
L>WHERE WeekNumber between @startWeek and @endWeek
L>GROUP BY WeekNumber
L>ORDER BY WeekNumber
L>


L>Не убедился.

Ну и в чем разница-то между твоим и этим:
SELECT WeekNumber, SUM(orderTotal) AS WeekTotal 
FROM (SELECT DatePart(w, saleDate) as WeekNumber, orderTotal from orders) XXX
WHERE WeekNumber between @startWeek and @endWeek
GROUP BY WeekNumber
ORDER BY WeekNumber

??? Один select поменяли на один with. Ажно две буквы сэкономили! Дупа-то в том, что нам только ради введения WeekNumber пришлось вводить отдельный select statement.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[2]: Что не так с SQL?
От: . Великобритания  
Дата: 17.01.08 12:09
Оценка:
Sinclair wrote:

> Т.е. употребление конструкции o.Owner *автоматически* приджойнивает

> таблицу, указанную в соответствующем FK.
Вроде всё такое HQL умеет.
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re: Что не так с SQL?
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 19.01.08 03:55
Оценка:
P>Вроде бы все замечательно, ну получаются запросы в 1-2 страницы текста — это нормально, но когда приходится изменить "чтоб немного по другому собирало", то приходится переписывать чуть ли не весь запрос. Безусловно, SQL в возможностях запросов данных довольно гибок, но вот костность в описательной структуре запроса удручает.

В таких случаях лучше сначала задуматься о структуре базы.
Имхо SQL весел тем, что сложность и производительность в нём обычно исчисляются порядками.
Т. е. если не разогнал/упростил на пару-тройку порядков, то и не стоило браться за оптимизацию.
... << RSDN@Home 1.2.0 alpha rev. 787>>
Re[6]: Что не так с SQL?
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 19.01.08 04:42
Оценка:
Q>Звучит очень сложно. Наверно, это очень дорого писать мегаумные анализаторы и многоуровневые кеши на все случаи жизни. Гораздо легче прикупить сотню гигабайт оперативной памяти и дать легкий эффективный и прозрачный движок для БД. А всем, кому это не нравится (дяде Васе с овощного склада) показать на дверь.

А если объёмы данных дорастут до терабайта?
... << RSDN@Home 1.2.0 alpha rev. 787>>
Re[5]: Что не так с SQL?
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 19.01.08 04:58
Оценка:
Ужас какой.
В таких случаях, на сколько я знаю, для отчётов изобретаются промежуточные хранилища данных, оптимизированные именно для построения отчётов. Как производить синхронизацию таких хранилищ (как впрочем любых денормализованных данных) — отдельная песня.
... << RSDN@Home 1.2.0 alpha rev. 787>>
Re[7]: Что не так с SQL?
От: Quintanar Россия  
Дата: 19.01.08 16:23
Оценка:
Здравствуйте, VGn, Вы писали:

VGn>А если объёмы данных дорастут до терабайта?


Террабайт — это, в принципе, не много.
Re[8]: Что не так с SQL?
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 19.01.08 20:38
Оценка:
Q>Террабайт — это, в принципе, не много.

Для оперативной памяти?
... << RSDN@Home 1.2.0 alpha rev. 787>>
Re[9]: Что не так с SQL?
От: Quintanar Россия  
Дата: 20.01.08 10:05
Оценка:
Здравствуйте, VGn, Вы писали:

Q>>Террабайт — это, в принципе, не много.


VGn>Для оперативной памяти?


Нет, для БД. У нас пара десятков террабайт БД и 64 гигабайт памяти для нее, в принципе, хватает.
Re[2]: Что не так с SQL?
От: Cyberax Марс  
Дата: 20.01.08 19:16
Оценка: :)
Здравствуйте, Sinclair, Вы писали:

S>Или вообще вот так:

S>
S>select o.*, o.Owner.Name from orders o
S>

S>Т.е. употребление конструкции o.Owner автоматически приджойнивает таблицу, указанную в соответствующем FK.
Будешь смеяться, но именно так сделано в HQL (Hibernate Query Language). Это одна из фич, которая делает запросы с тремя-четырьмя уровнями join'ов читабельными.
Sapienti sat!
Re[10]: Что не так с SQL?
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 21.01.08 03:22
Оценка:
Q>Нет, для БД. У нас пара десятков террабайт БД и 64 гигабайт памяти для нее, в принципе, хватает.

Стандартный сервер БД
Разговор был о хранении данных в оперативной памяти.
... << RSDN@Home 1.2.0 alpha rev. 787>>
Re[2]: Что не так с SQL?
От: VladD2 Российская Империя www.nemerle.org
Дата: 23.01.08 12:20
Оценка:
Здравствуйте, Sinclair, Вы писали:

Мне кажется проблему декомпозиции можно было бы решить куда проще. Надо было просто добавить возможность задания переменных. Причем, чтобы не ломать декларативный дух SQL-я, они должны быть (как в ФЯ) доступны только для чтения. Если еще добавить возможность описания фунций и оператор if (но с семантикой как у опертора ?: в С), то проблем с декомпозицией не было бы. В прочем, фунции наверно это и есть более математическо (что ли) название для параметрезованных вьюх. В общем, нужно брать классику. ФП тут подошло бы на ура.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: Что не так с SQL?
От: Sinclair Россия https://github.com/evilguest/
Дата: 23.01.08 12:52
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Sinclair, Вы писали:


VD>Мне кажется проблему декомпозиции можно было бы решить куда проще. Надо было просто добавить возможность задания переменных. Причем, чтобы не ломать декларативный дух SQL-я, они должны быть (как в ФЯ) доступны только для чтения.

А какой тип будет у этой переменной?
Можно же делать примерно так:
create view allCustomers# as ... 
GO
select * from allCustomers# a1 join allCustomers# a2 on ...



VD> Если еще добавить возможность описания фунций и оператор if (но с семантикой как у опертора ?: в С), то проблем с декомпозицией не было бы. В прочем, фунции наверно это и есть более математическо (что ли) название для параметрезованных вьюх. В общем, нужно брать классику. ФП тут подошло бы на ура.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[4]: Что не так с SQL?
От: deniok Россия  
Дата: 23.01.08 13:37
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, VladD2, Вы писали:


VD>>Здравствуйте, Sinclair, Вы писали:


VD>>Мне кажется проблему декомпозиции можно было бы решить куда проще. Надо было просто добавить возможность задания переменных. Причем, чтобы не ломать декларативный дух SQL-я, они должны быть (как в ФЯ) доступны только для чтения.

S>А какой тип будет у этой переменной?
Полиморфный, с ограничением общности. В твоем примере
create view InProgress(TaskTable @tablename) as
select * from @tableName where status in ("open", "assigned", "verifying")

@tablename должна выставлять интерфейс HasField status (ну синтаксис какой-то другой, понятно). Тут он, кстати, из применения выводится.
Re[3]: Что не так с SQL?
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 23.01.08 14:28
Оценка:
VD>Мне кажется проблему декомпозиции можно было бы решить куда проще. Надо было просто добавить возможность задания переменных. Причем, чтобы не ломать декларативный дух SQL-я, они должны быть (как в ФЯ) доступны только для чтения. Если еще добавить возможность описания фунций и оператор if (но с семантикой как у опертора ?: в С), то проблем с декомпозицией не было бы. В прочем, фунции наверно это и есть более математическо (что ли) название для параметрезованных вьюх. В общем, нужно брать классику. ФП тут подошло бы на ура.

Вообще уже давно есть: курсоры, в оракле ещё есть pipelined functions, и if есть, только немного с другой семантикой. Главная проблема, что в нынешнем виде это всё жутко неудобно, недостаточно по функциональности и неунифицировано (в смысле нестандартно).
... << RSDN@Home 1.2.0 alpha rev. 787>>
Re[3]: Что не так с SQL?
От: Andrei N.Sobchuck Украина www.smalltalk.ru
Дата: 24.01.08 08:45
Оценка: -3 :)
Здравствуйте, VladD2, Вы писали:

VD>Мне кажется проблему декомпозиции можно было бы решить куда проще. Надо было просто добавить возможность задания переменных. Причем, чтобы не ломать декларативный дух SQL-я, они должны быть (как в ФЯ) доступны только для чтения. Если еще добавить возможность описания фунций и оператор if (но с семантикой как у опертора ?: в С), то проблем с декомпозицией не было бы. В прочем, фунции наверно это и есть более математическо (что ли) название для параметрезованных вьюх. В общем, нужно брать классику. ФП тут подошло бы на ура.


Оператор if "с семантикой опертора ?: в С" в SQL есть. Большинство современных диалектов позволяют делать подзапросы (это то, что ты назвал "функции"). Это принципиальный функционал. А объявления /неизменяемых/ переменных и декларация функций это банальный синтаксический сахар Т.е. нужно только для слабых духом
http://www.smalltalk.ru << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я ненавижу Hibernate
Автор: Andrei N.Sobchuck
Дата: 08.01.08
!
Re[2]: Что не так с SQL?
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 24.01.08 11:33
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>1. Главное препятствие декомпозиции — отсутствие в стандарте параметризованных view. В итоге, вместо того, чтобы легким манием руки приджойнить EmployeeOrders(Name) мы пишем join EmployeeOrders where EmployeeName = Name.


А функции чем не подходят?

S>2. Второе препятствие декомпозиции — отсутствие в стандарте способа задания открытых view. В итоге совершенно невозможно написать ничего подобного этому:

S>
S>create view InProgress(TaskTable @tablename) as
S>select * from @tableName where status in ("open", "assigned", "verifying")
S>

S>И применять ко всем подходящим таблицам.

В MSSQL 2008 вроде бы подобное есть, но насчет эффективности ХЗ.

S>3. Невозможность использовать алиасы для скалярных выражений. В order by можно хотя бы указать цифру, но в остальных местах приходится честно переписывать все нужные выражения.


Т.е. нужно что то типа let в LINQ?

S>4. Жутко многословный синтаксис джойнов. Нет, я понимаю всю красоту идеи, но 99% джойнов — это equality join по foreign key. Синтаксис этого никак не отражает. Поддержка упрощенного синтаксиса FK-джойнов была бы офигенным улучшением, сокращающим большинство запросов на порядок. Примерно так:

S>Или вообще вот так:
S>
S>select o.*, o.Owner.Name from orders o
S>

S>Т.е. употребление конструкции o.Owner автоматически приджойнивает таблицу, указанную в соответствующем FK.

Это в нашем DSL тоже есть, собственно идея на поверхности лежит. Но тут есть засада в том случае, если FK допускает null. Нормально разресолвить это можно только при помощи статического null-анализа и выкидывания исключения, если возможно обращение по null.
... << RSDN@Home 1.2.0 alpha rev. 725 on Windows Vista 6.0.6000.0>>
AVK Blog
Re[3]: Что не так с SQL?
От: Sinclair Россия https://github.com/evilguest/
Дата: 24.01.08 12:04
Оценка:
Здравствуйте, AndrewVK, Вы писали:
AVK>А функции чем не подходят?
Нестандартностью.
S>>И применять ко всем подходящим таблицам.

AVK>В MSSQL 2008 вроде бы подобное есть, но насчет эффективности ХЗ.

Эффективность всего этого должна быть нормальной, потому что в итоге все равно получается некий "плоский" запрос, который уходит к оптимизатору.
AVK>Т.е. нужно что то типа let в LINQ?
Типа того. Хотя я бы предпочел сам Linq Я имею в виду всякие бодрые трансформации запроса на ходу. А то меня (и оптимизатор) со страшной силой бесят все эти
where ((@startDate is null) or (orderDate>@startDate)


S>>Т.е. употребление конструкции o.Owner автоматически приджойнивает таблицу, указанную в соответствующем FK.


AVK>Это в нашем DSL тоже есть, собственно идея на поверхности лежит. Но тут есть засада в том случае, если FK допускает null.

Да, тут проблема, т.к. непонятно, outer или inner join имел в виду программист. Скорее всего таки outer, т.к. при inner строчки с FK в null будут таинственным образом пропадать.
AVK>Нормально разресолвить это можно только при помощи статического null-анализа и выкидывания исключения, если возможно обращение по null.
Вот тут я не понимаю. Зачем чего-то статически резолвить?
Это же сахар:
select o.*, Owner.Name from orders o
outer join Employee on Employee.ID = Order.EmployeeID

тут же не будет никаких исключений, верно? Точно так же будет себя вести и Owner.Address.Name в случае более длинных штук. Отрулить обратно к иннеру всегда можно дополнением
where Owner is not null
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[4]: Что не так с SQL?
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 24.01.08 12:17
Оценка:
Здравствуйте, Sinclair, Вы писали:

AVK>>А функции чем не подходят?

S>Нестандартностью.

Их разве в sql'03 нет?

AVK>>В MSSQL 2008 вроде бы подобное есть, но насчет эффективности ХЗ.

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

Не факт.

AVK>>Т.е. нужно что то типа let в LINQ?

S>Типа того.

+1

S> Хотя я бы предпочел сам Linq Я имею в виду всякие бодрые трансформации запроса на ходу. А то меня (и оптимизатор) со страшной силой бесят все эти

S>
S>where ((@startDate is null) or (orderDate>@startDate)
S>


Ну, это уже не столько к SQL вопросы, сколько вообще к архитектуре сегодняшних РСУБД

AVK>>Это в нашем DSL тоже есть, собственно идея на поверхности лежит. Но тут есть засада в том случае, если FK допускает null.

S>Да, тут проблема, т.к. непонятно, outer или inner join имел в виду программист.

Именно. Причем в некоторых случаях он мог ене иметь ни того. ни другого, а скорее даже выдачу ошибки, если там реально где то null попался.

S> Скорее всего таки outer, т.к. при inner строчки с FK в null будут таинственным образом пропадать.


Ну вот я пока у себя сделал outer, но результат при этом тоже не особо очевидным получается

AVK>>Нормально разресолвить это можно только при помощи статического null-анализа и выкидывания исключения, если возможно обращение по null.

S>Вот тут я не понимаю. Зачем чего-то статически резолвить?
S>Это же сахар:
S>
S>select o.*, Owner.Name from orders o
S>outer join Employee on Employee.ID = Order.EmployeeID
S>

S>тут же не будет никаких исключений, верно?

Да, но здесь мы явно показываем семантику того, что хотим увидеть. А выражение Owner.Name предполагает все таки обязательное наличие Owner, иначе семантика получается бредовой. Можно было бы просто при попытке использовать такое по FK без NOT NULL ругаццо, но остается ситуация вроде:
select Owner.Name from orders where Owner is not null
... << RSDN@Home 1.2.0 alpha rev. 725 on Windows Vista 6.0.6000.0>>
AVK Blog
Re[5]: Что не так с SQL?
От: Sinclair Россия https://github.com/evilguest/
Дата: 24.01.08 12:38
Оценка:
Здравствуйте, AndrewVK, Вы писали:
AVK>Их разве в sql'03 нет?
Я че-то не проследил. Так что может быть претензию можно и снять.

S>> Хотя я бы предпочел сам Linq Я имею в виду всякие бодрые трансформации запроса на ходу. А то меня (и оптимизатор) со страшной силой бесят все эти

S>>
S>>where ((@startDate is null) or (orderDate>@startDate)
S>>


AVK>Ну, это уже не столько к SQL вопросы, сколько вообще к архитектуре сегодняшних РСУБД

Не-не-не. Это к тому, что запрос строится слишком жестким образом. С ним можно работать только как с целым. Хотя... Если будут переменные типа "SQL запрос", которые дешево создавать и модифицировать, то как раз можно добиться многого. Типа
if @startDate is not null
then 
  define a as 
  select * from a where orderDate>@startDate



AVK>Именно. Причем в некоторых случаях он мог ене иметь ни того. ни другого, а скорее даже выдачу ошибки, если там реально где то null попался.

Ну, это уже что-то из области не-РСУБД. Вся семантика аутер джойнов для нормального человека малопонятна.


AVK>Да, но здесь мы явно показываем семантику того, что хотим увидеть. А выражение Owner.Name предполагает все таки обязательное наличие Owner, иначе семантика получается бредовой. Можно было бы просто при попытке использовать такое по FK без NOT NULL ругаццо, но остается ситуация вроде:

AVK>
AVK>select Owner.Name from orders where Owner is not null
AVK>

Можно покопать в сторону чего-то типа operator lifting в C# 2.0. Я имею в виду, что семантика Owner.Name может быть и такой: (Owner == null ? Owner.Name : (string?) null).
Можно оставить выброс исключения, а предложенное поведение повесить на что-то кроме точки. Ну там типа ?.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[6]: Что не так с SQL?
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 24.01.08 13:04
Оценка:
Здравствуйте, Sinclair, Вы писали:

AVK>>Их разве в sql'03 нет?

S> Я че-то не проследил. Так что может быть претензию можно и снять.

Ну, мои познания в деталях ограничиваются sql'92 и немножко sql'99

AVK>>Ну, это уже не столько к SQL вопросы, сколько вообще к архитектуре сегодняшних РСУБД

S>Не-не-не. Это к тому, что запрос строится слишком жестким образом. С ним можно работать только как с целым. Хотя... Если будут переменные типа "SQL запрос", которые дешево создавать и модифицировать, то как раз можно добиться многого. Типа
S>
S>if @startDate is not null
S>then 
S>  define a as 
S>  select * from a where orderDate>@startDate
S>


Это уже ближе к императивным расширениям SQL, т.е. совсем другой разговор. В этом случаем можно спокойно пользовать C# совместно с SQL-CLR, в том числе и с Linq2Sql.

S>Ну, это уже что-то из области не-РСУБД. Вся семантика аутер джойнов для нормального человека малопонятна.


Отнюдь. Ты сейчас представляешь себе это ввиде джойна. Однако это не правомерно, это отдельная конструкция языка. И семантику ее надо делать не исходя из того, что это джойн, а исключительно с точки зрения собственной конструкции. А с этой точки зрения поведение, аналогичное outer join является крайне неочевидным. А РСУБД это, или не РСУБД, это уже второй вопрос, реляционная алгебра не идол, на нее давно уже никто не молется.

S>Можно покопать в сторону чего-то типа operator lifting в C# 2.0. Я имею в виду, что семантика Owner.Name может быть и такой: (Owner == null ? Owner.Name : (string?) null).


Неочевидно. Особенно если это какой нибудь Owner.Person.Address.City.Name.

S>Можно оставить выброс исключения, а предложенное поведение повесить на что-то кроме точки. Ну там типа ?.


А каков физический смысл подобного поведения (которое идентично outer join)?
... << RSDN@Home 1.2.0 alpha rev. 725 on Windows Vista 6.0.6000.0>>
AVK Blog
Re[4]: Что не так с SQL?
От: VladD2 Российская Империя www.nemerle.org
Дата: 24.01.08 14:09
Оценка: +3
Здравствуйте, Sinclair, Вы писали:

S>А какой тип будет у этой переменной?


Это уже детали.

S>Можно же делать примерно так:

S>
S>create view allCustomers# as ... 
S>GO
S>select * from allCustomers# a1 join allCustomers# a2 on ... 
S>


Лучше так:
def query1 = select * from customers where <some conditions>
def query2(x, y) = select ... from query1 where someTable.x = x and someTable.y = y
select query2(123, "yes")


В общем, главная мысль в том, что разные T-SQL и P-SQL пошли по неверному пути. Они расширяют красивый деларатив SQL императивными конструкциями, причем в кривешем исполнении. Вместо этого можно было снабдив SQL всего тремя фичами сделать красиво решение позволяющее решать не только проблему декомпозиции сложных запросов, но и делающее SQL полным по Тьюренгу языком.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: Что не так с SQL?
От: Quintanar Россия  
Дата: 24.01.08 15:08
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>В общем, главная мысль в том, что разные T-SQL и P-SQL пошли по неверному пути. Они расширяют красивый деларатив SQL императивными конструкциями, причем в кривешем исполнении. Вместо этого можно было снабдив SQL всего тремя фичами сделать красиво решение позволяющее решать не только проблему декомпозиции сложных запросов, но и делающее SQL полным по Тьюренгу языком.


Правильно, без боли на ужаснейшие бейсик-like выражения из PlSQL смотреть нельзя. Лучше расширять его через функцинальные фичи. Пример — Q.
Re[5]: Что не так с SQL?
От: Plague Россия  
Дата: 24.01.08 18:33
Оценка: -1
Здравствуйте, VladD2, Вы писали:

S>>Можно же делать примерно так:

S>>
S>>create view allCustomers# as ... 
S>>GO
S>>select * from allCustomers# a1 join allCustomers# a2 on ... 
S>>


VD>Лучше так:

VD>
VD>def query1 = select * from customers where <some conditions>
VD>def query2(x, y) = select ... from query1 where someTable.x = x and someTable.y = y
VD>select query2(123, "yes")
VD>


А чем не нравится оператор WITH (в MSSQL 2005) и WITH (в Oracle)? У него вижу проблему только в том, что WITH работает только для одного запроса, т.е. упростит только один запрос.

VD>В общем, главная мысль в том, что разные T-SQL и P-SQL пошли по неверному пути. Они расширяют красивый деларатив SQL императивными конструкциями, причем в кривешем исполнении. Вместо этого можно было снабдив SQL всего тремя фичами сделать красиво решение позволяющее решать не только проблему декомпозиции сложных запросов, но и делающее SQL полным по Тьюренгу языком.


В общем виде в MS SQL есть средство, что пользовательская функция может возвращать результат запроса и принимать параметры для него, что является мощной заменой вьюхам. (В оракле такого нет, вроде, можно только курсор возвращать ) Единственно возникает вопрос — а на сколько это хорошая замена вьюхам и вложенным запросам?

на счет IF:
WITH EXPR AS
(SELECT /*ТУТ УСЛОВИЕ*/ FROM DUAL)
select * from EXPR e, TABLE_1 where e.result = 0
union all 
select * from EXPR e, TABLE_2 where e.result <> 0

или даже заинлайнить условие...

но, по моей практике, такое встречается не часто...
... << RSDN@Home 1.2.0 alpha rev. 787>>
Re[6]: Что не так с SQL?
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 24.01.08 20:34
Оценка:
Здравствуйте, Plague, Вы писали:

P>Единственно возникает вопрос — а на сколько это хорошая замена вьюхам и вложенным запросам?


Если говорить об inline-функциях — прекрасное. Единственная дырка — нет сущности между глобальной функцией и локальным CTE. Да и CTE, ИМХО, синтаксически не очень удачно.
... << RSDN@Home 1.2.0 alpha rev. 725 on Windows Vista 6.0.6000.0>>
AVK Blog
Re[7]: Что не так с SQL?
От: Plague Россия  
Дата: 25.01.08 09:42
Оценка: -1
Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, Plague, Вы писали:


P>>Единственно возникает вопрос — а на сколько это хорошая замена вьюхам и вложенным запросам?


AVK>Если говорить об inline-функциях — прекрасное. Единственная дырка — нет сущности между глобальной функцией и локальным CTE. Да и CTE, ИМХО, синтаксически не очень удачно.


Да, к сожалению... В Оракле есть пакеты, что сильно уменьшает количество "видимых" процедур, да и так в Оракле можно создавать вложенные процедуры.
Но вот, что нет подобных функций, что возвращают Таблицы, как парамтризированные вьюхи...
... << RSDN@Home 1.2.0 alpha rev. 787>>
Re[8]: Что не так с SQL?
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 25.01.08 14:35
Оценка:
P>Но вот, что нет подобных функций, что возвращают Таблицы, как парамтризированные вьюхи...

http://www.akadia.com/services/ora_pipe_functions.html

выглядит императивно, но работает функционально.
Большой минус — оптимизатор запросов идёт лесом.
... << RSDN@Home 1.2.0 alpha rev. 787>>
Re[6]: Что не так с SQL?
От: VladD2 Российская Империя www.nemerle.org
Дата: 25.01.08 14:38
Оценка:
Здравствуйте, Plague, Вы писали:

P>А чем не нравится оператор WITH (в MSSQL 2005) и WITH (в Oracle)? У него вижу проблему только в том, что WITH работает только для одного запроса, т.е. упростит только один запрос.


1. Это хреново выглядит и читается.
2. Это не стандартные расширения.
3. У Оракла нельзя зада параметры.
4. По уму функцию должно быть можно задать как локально (для пакета запросов), так и на уровне БД, так чтобы ее можно было использовать многкратно. Собственно второе тоже кое как реализовано во многих серверах, но опять же через зад автогеном и опять же это нестандартные расширения.

P>В общем виде в MS SQL есть средство, что пользовательская функция может возвращать результат запроса и принимать параметры для него,


MS SQL это частное решение, а речь идет о SQL как о стандарте.
К тому же MS SQL имеет массу других кривых решений появившихся сильно раньше и массу ограничений.

P> что является мощной заменой вьюхам. (В оракле такого нет, вроде, можно только курсор возвращать ) Единственно возникает вопрос — а на сколько это хорошая замена вьюхам и вложенным запросам?


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

Если бы в начале проектирования SQL-ы ввели бы синтаксис immutable-присвоения, фунции и if, то нужны в большинстве примочек, появившихся за эти годы в диалектах SQL-я, попросту не поднадобилось бы. Те же вьюхи были бы банальным частным случаем.

P>на счет IF:

P>
P>WITH EXPR AS
P>(SELECT /*ТУТ УСЛОВИЕ*/ FROM DUAL)
P>select * from EXPR e, TABLE_1 where e.result = 0
P>union all 
P>select * from EXPR e, TABLE_2 where e.result <> 0
P>

P>или даже заинлайнить условие...

P>но, по моей практике, такое встречается не часто...


Кривотень какая-то. Аналоги ифу конечно есть. Я не пойму зачем надо было делать все раком?

В прочем, я рассуждаю сейчас, когда есть масса научных наработок в области языкостроения, а тогда все это было изобретательство.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Что не так с SQL?
От: VladD2 Российская Империя www.nemerle.org
Дата: 25.01.08 14:38
Оценка: +1
Здравствуйте, VGn, Вы писали:

VGn>Вообще уже давно есть: курсоры, в оракле ещё есть pipelined functions, и if есть, только немного с другой семантикой.


Ага. Если бы не было этих только и было бы это все не в Оракле, а в стандарте SQL. То было бы хорошо.

Курсоры это худшее что можно было придумать. Другой if тоже не катит.

VGn> Главная проблема, что в нынешнем виде это всё жутко неудобно, недостаточно по функциональности и неунифицировано (в смысле нестандартно).


Дык. О том и речь. А могло бы быть просто и фунционально. Просто люди что развивали SQL, развивали его по наитию. Они просто не знали, что то чем они занимаются сто раз проработано до них. Вот и нагородили монструзных колсов на глинянных ногах вроде T-SQL и PSQL.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: Что не так с SQL?
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 25.01.08 15:43
Оценка: +1
Здравствуйте, VladD2, Вы писали:

VD>2. Это не стандартные расширения.


Стандартные. CTE, AFAIK, появился в SQL'99

VD>MS SQL это частное решение, а речь идет о SQL как о стандарте.

VD>К тому же MS SQL имеет массу других кривых решений появившихся сильно раньше и массу ограничений.

Стандарт тоже имеет массу кривоты, из-за чего его никто на 100% не реализует.
... << RSDN@Home 1.2.0 alpha rev. 725 on Windows Vista 6.0.6000.0>>
AVK Blog
Re[9]: Что не так с SQL?
От: Quintanar Россия  
Дата: 25.01.08 20:54
Оценка:
Здравствуйте, VGn, Вы писали:

P>>Но вот, что нет подобных функций, что возвращают Таблицы, как парамтризированные вьюхи...


VGn>http://www.akadia.com/services/ora_pipe_functions.html


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

VGn>Большой минус — оптимизатор запросов идёт лесом.

Типичный пример работы через задницу автогеном. Столь жутких способов достижения столь простых результатов я давно не видел.
Re[9]: Что не так с SQL?
От: Plague Россия  
Дата: 26.01.08 13:42
Оценка:
Здравствуйте, VGn, Вы писали:

P>>Но вот, что нет подобных функций, что возвращают Таблицы, как парамтризированные вьюхи...


VGn>http://www.akadia.com/services/ora_pipe_functions.html


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

VGn>Большой минус — оптимизатор запросов идёт лесом.

В том то и дело, что нафиг оно нужно без оптимизатора запросов? Ведь если использовать повсеместно, то скорость будет никакая...
Конечно, можно сделать так:

CREATE OR REPLACE TYPE myRecord 
AS OBJECT
(
  A   INT,
  B   DATE,
  C   VARCHAR2(25)
)

CREATE OR REPLACE TYPE myRecordType
   AS TABLE OF myRecord
   
create function test
  return myRecordType
  PIPELINED
  as
  begin
     for i in (select * from mytable)
     loop
         pipe row(myRecord(i.a+1, i.b-1, i.c||'!'));
     end loop;
     return;
  end;
  
-- А потом использовать:
SELECT * FROM TABLE(test());

Согласись, выглядит ужастно!

А у MS SQL, похоже, инлайн функции, возвращающие таблицу-результат запроса, могут быть параметризируемыми и позиционируются как хорошая замена вьюхам.
К сож. я не знаю как проверить как использует их оптимизатор.
... << RSDN@Home 1.2.0 alpha rev. 787>>
Re[7]: Что не так с SQL?
От: Plague Россия  
Дата: 26.01.08 13:42
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>1. Это хреново выглядит и читается.

Ну... это лучше чем 2 и более подзапроса... я использовал и на самом деле несколько лучше становится для больших запросов, т.к. они становятся знгачительно полегче...
VD>2. Это не стандартные расширения.
стандартные, исключая только то, что у MS SQL используется для деревьев рекурсия, а у оракла CONNECT BY
VD>3. У Оракла нельзя зада параметры.
Эээ.. а где там и у MS SQL параметры?

VD>4. По уму функцию должно быть можно задать как локально (для пакета запросов), так и на уровне БД, так чтобы ее можно было использовать многкратно. Собственно второе тоже кое как реализовано во многих серверах, но опять же через зад автогеном и опять же это нестандартные расширения.

согласен.

VD>К тому же MS SQL имеет массу других кривых решений появившихся сильно раньше и массу ограничений.

+1

VD>Если бы в начале проектирования SQL-ы ввели бы синтаксис immutable-присвоения, фунции и if, то нужны в большинстве примочек, появившихся за эти годы в диалектах SQL-я, попросту не поднадобилось бы. Те же вьюхи были бы банальным частным случаем.

+1
... << RSDN@Home 1.2.0 alpha rev. 787>>
Re[10]: Что не так с SQL?
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 26.01.08 16:17
Оценка: 2 (1)
Здравствуйте, Plague, Вы писали:

P>А у MS SQL, похоже, инлайн функции, возвращающие таблицу-результат запроса, могут быть параметризируемыми и позиционируются как хорошая замена вьюхам.

P>К сож. я не знаю как проверить как использует их оптимизатор.

Которые inline — использует, я проверял. А вот которые нет — испольует плохо. Даже если не-inline функция идентична inline во всем, кроме синтаксиса заголовка, план запросов отличается не в пользу первой.
... << RSDN@Home 1.2.0 alpha rev. 725 on Windows Vista 6.0.6000.0>>
AVK Blog
Re[11]: Что не так с SQL?
От: Plague Россия  
Дата: 27.01.08 15:18
Оценка:
Получается так, что если взять пакеты как в PL/SQL и инлайн функции как в T-SQL, то может получится отличная штука!
Ну, и вложенные функции в том числе... =)
... << RSDN@Home 1.2.0 alpha rev. 787>>
Re[7]: Что не так с SQL?
От: Plague Россия  
Дата: 28.01.08 11:35
Оценка: +2
Еще чего не хватает — это нормального понимания алиасов полей, т.е. они существую только для именования результатов полей и не учавствуют, например в order и having by...
Да и в самом списке было бы не плохо, типа:

select sum(a) sum_a, case when sum_a > 0 then 'больше' else 'меньше' end 
from foo
group by b
having by sum_a <> 0
order by sum_a
... << RSDN@Home 1.2.0 alpha rev. 787>>
Re: Что не так с SQL?
От: s_tarassov www.arbinada.com
Дата: 18.02.08 14:39
Оценка:
Здравствуйте, Plague, Вы писали:

P>В последнее время все больше и больше кажется, что что-то не так с SQL. Не с конкретной реализацией, а вообще.

P>Вроде бы все замечательно, ну получаются запросы в 1-2 страницы текста — это нормально, но когда приходится изменить "чтоб немного по другому собирало", то приходится переписывать чуть ли не весь запрос. Безусловно, SQL в возможностях запросов данных довольно гибок, но вот костность в описательной структуре запроса удручает.
P>Что думает по этому поводу народ?

Создай над сиквелом свою проблемную надстройку.
Как вариант, с помощью макроязыка.
Re[2]: Что не так с SQL?
От: Plague Россия  
Дата: 19.02.08 12:35
Оценка:
Здравствуйте, s_tarassov, Вы писали:

_>Создай над сиквелом свою проблемную надстройку.

Зачастую не все так просто. Например, если писать под Оракл, думаю, чтоб не потерять всю силу и гибкость PL/SQL, то нужно генерировать код не в динамике, а скажем, предварительно написать приложение на некотором языке (MySuperPL/SQL и т.п. ), а потом компилировать в PL/SQL. Т.е., конечно, возможно только частичная перекомпиляция, только изменяемых вещей. Как выше сказали, что существующим реализациям чего-то, да не хватает...
В оракле есть пакеты, но нет "инлайн" функций и т.п. Нет достаточно гибкого описания взаимосвязи между таблицами, что могло бы повлиять на облегчение программирования (кста, такой шаг сделан в 1С, вроде, там язык запросов на уровне объектов, конечно, простоват, но тем не менее есть. Уберсложные запросы — хрен соберешь, но вот средней сложности и очевидные собирать в разы проще, имхо.).

_>Как вариант, с помощью макроязыка.

Ну... те проблемы, которые решает этот макроязык PL/SQL решает достаточно хорошо.
Да и в целом, я не достаточно понял что SPM дает кроме дополнительного синтаксиса, усложнения и увеличения кода...
... << RSDN@Home 1.2.0 alpha rev. 787>>
Re[3]: Что не так с SQL?
От: s_tarassov www.arbinada.com
Дата: 19.02.08 13:31
Оценка:
Здравствуйте, Plague, Вы писали:
_>>Как вариант, с помощью макроязыка.
P>Ну... те проблемы, которые решает этот макроязык PL/SQL решает достаточно хорошо.
Макроязык нужен, когда не хватает выразительных средств базового языка.
Если такой проблемы нет, значит — нет.

P>Да и в целом, я не достаточно понял что SPM дает кроме дополнительного синтаксиса, усложнения и увеличения кода...

Например, вот эта проблема решается
P>В оракле есть пакеты, но нет "инлайн" функций
Re[4]: Что не так с SQL?
От: Plague Россия  
Дата: 19.02.08 14:28
Оценка: -1
Здравствуйте, s_tarassov, Вы писали:

P>>Да и в целом, я не достаточно понял что SPM дает кроме дополнительного синтаксиса, усложнения и увеличения кода...

_>Например, вот эта проблема решается
P>>В оракле есть пакеты, но нет "инлайн" функций

Разница в том, что SPM не встроен в Oracle, а значит будет пристуствовать статическая компиляция. Перекомпиляция каждый раз 1000 функций — дело не благодарное. Если же будет попытка в динамике собирать запросы и т.п. — пойдут лесом многие оптимизации Оракла, да и вообще от динамики только проблемы видел.
... << RSDN@Home 1.2.0 alpha rev. 787>>
Re[5]: Что не так с SQL?
От: s_tarassov www.arbinada.com
Дата: 19.02.08 14:55
Оценка: -1
Здравствуйте, Plague, Вы писали:
P>>>Да и в целом, я не достаточно понял что SPM дает кроме дополнительного синтаксиса, усложнения и увеличения кода...
_>>Например, вот эта проблема решается
P>>>В оракле есть пакеты, но нет "инлайн" функций
P>Разница в том, что SPM не встроен в Oracle, а значит будет пристуствовать статическая компиляция. Перекомпиляция каждый раз 1000 функций — дело не благодарное.

Не каждый раз, а только при изменении "инлайн"-функции
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.