В последнее время все больше и больше кажется, что что-то не так с SQL. Не с конкретной реализацией, а вообще.
Вроде бы все замечательно, ну получаются запросы в 1-2 страницы текста — это нормально, но когда приходится изменить "чтоб немного по другому собирало", то приходится переписывать чуть ли не весь запрос. Безусловно, SQL в возможностях запросов данных довольно гибок, но вот костность в описательной структуре запроса удручает.
Что думает по этому поводу народ?
Здравствуйте, Plague, Вы писали:
P>В последнее время все больше и больше кажется, что что-то не так с SQL. Не с конкретной реализацией, а вообще. P>Вроде бы все замечательно, ну получаются запросы в 1-2 страницы текста — это нормально, но когда приходится изменить "чтоб немного по другому собирало", то приходится переписывать чуть ли не весь запрос. Безусловно, SQL в возможностях запросов данных довольно гибок, но вот костность в описательной структуре запроса удручает. P>Что думает по этому поводу народ?
Если ты видишь как свои "немного по-другому" формализовать, напиши DSL, генерирующий SQL
Здравствуйте, deniok, Вы писали:
D>Здравствуйте, Plague, Вы писали:
P>>В последнее время все больше и больше кажется, что что-то не так с SQL. Не с конкретной реализацией, а вообще. P>>Вроде бы все замечательно, ну получаются запросы в 1-2 страницы текста — это нормально, но когда приходится изменить "чтоб немного по другому собирало", то приходится переписывать чуть ли не весь запрос. Безусловно, SQL в возможностях запросов данных довольно гибок, но вот костность в описательной структуре запроса удручает. P>>Что думает по этому поводу народ?
D>Если ты видишь как свои "немного по-другому" формализовать, напиши DSL, генерирующий SQL
А может стоит использовать язык другой, более гибкий и подходящий под задачу (вопрос, конечно, какую именно), скажем тот же K?
Здравствуйте, deniok, Вы писали:
D>Если ты видишь как свои "немного по-другому" формализовать, напиши DSL, генерирующий SQL
Если было бы все так просто... Конечно, понятно, что есть борьба и с производительностью БД, т.е. кроме требований получения данных надо собрать "оптимальный" запрос, т.е. чтоб работал приемлемо быстро (при заданных условиях). Итак, есть просто бескрайнее поле вариантов как именно сделать выборку данных, но на написание и опробование каждого уйдет уйма времени, поэтому несколько понимая как работает БД и по опыту собираешь так кажется более "оптимально". Но вдруг добавляется условие и встаешь перед дилеммой — переписать запрос, т.к. с учетом новых условий структура оптимального запроса должна быть несколько другой, ИЛИ сделать "подпорку" сделав очередной вложенный подзапрос и прочие такие не очень хорошие решения. %)
Понятно, что некоторые вещи можно решить использованием вьюх. Но по опыту работы иногда приходится от них отказываться, т.к. производительность запроса начинает желать лучшего. Да и когда количество вьюх не одна тысяча — задумываешься клепать ли новую... Так же дело в том на сколько вьюха должна быть простой, т.е. если вьюха сложная — ее тяжело использовать в сложных запросах из-за производительности (так как таких вьюх может быть использовано множество, да и они могут содержать сортировки и группировки, что дает нагрузку), т.е. легче отказаться от ее использования. Если она простая, то смысл использовать ее тоже под вопросом, т.к. на каждую комбинацию 2х-3х-4х таблиц не напишешь вьюху, т.е. количество вьюх стремительно расти.
В использовании вьюх вижу большой бонус в некой фильтрации данных, т.е. не просто сбор со всевозможными справочниками, а именно отбор данных с условиями.
DSL, конечно, прикольно было бы придумать. Т.е. описываешь на нем БД, а он уже собирает SQL-код для все БД.
PS. Мое негативное настроение повлияло, что есть БД (SQL Server 2005) в которой СОВСЕМ НЕТ вьюх и процедур, к которой можно делать только запросы и поэтому запросы получаются не в одну страницу. При этом в каждой таблице есть поле логического удаления записи, которое надо учитывать, множество таблиц связок и т.п., что нисколько не облегчает работу.
Здравствуйте, AndrewVK, Вы писали:
AVK>Не так с ним то, что в базовом SQL'92 крайне скудные возможности реюза. ИМХО следует стараться активнее использовать функции и CTE.
Да, CTE радует, т.к. можно вынести некий код из запроса как бы разделив, что значительно упрощает чтение и понимание. Даже комментарии нормально поставить к нему можно, т.к. когда есть гиганский запрос сложно объяснить в чем фишка соединения 15-20 таблиц. =)
Функции — согласен.
Здравствуйте, AndrewVK, Вы писали:
AVK>Не так с ним то, что в базовом SQL'92 крайне скудные возможности реюза. ИМХО следует стараться активнее использовать функции и CTE.
Единственная проблема CTE — это то, что реюз в рамках одного запроса, а хотелось бы более широкое использование, например в рамках процедуры или пакета.
PS. В Оракле в WITH можно использовать рекурсивный запрос? или нужно использовать CONNECT BY?
Имхо там тупо не хватает что-то наподобие классов/свободных функций. Не знаю как объяснить, но чтобы можно было составлять нормальную композицию из каких-то запросов и тп
Здравствуйте, 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>>
Здравствуйте, Plague, Вы писали:
P>В последнее время все больше и больше кажется, что что-то не так с SQL. Не с конкретной реализацией, а вообще. P>Вроде бы все замечательно, ну получаются запросы в 1-2 страницы текста — это нормально, но когда приходится изменить "чтоб немного по другому собирало", то приходится переписывать чуть ли не весь запрос. Безусловно, SQL в возможностях запросов данных довольно гибок, но вот костность в описательной структуре запроса удручает. P>Что думает по этому поводу народ?
Это, наверно, из-за того, что SQL задумывался как простой язык для широкого круга пользователей (читай домохозяек), но на деле вышло, что использовать его стали иначе и, в основном, профессиональные программисты, которым эта простота совсем не нужна, если ради нее приходится жертвовать производительностью и выразительностью. Но что сделано, то сделано, остается только прикручивать к ядру SQL фичи, устраняющие некоторые его недостатки, добавлять спец языки типа tsql и прочее.
Есть, правда, диалекты SQL совмещенные с нормальным языком программирования (Q в kdb+), где у программиста есть вся власть над ядром БД, он всегда знает, что происходит и почему и ничего не оптимизируется автоматически. Т.е. можно сразу писать оптимальный запрос на основе знаний о структуре БД, не пользуясь никакими анализаторами. В результате получаем гибкость обычного языка программирования совмещенную с мощью SQL, в таких условиях запросы укорачиваются, а понятность программы возрастает.
Здравствуйте, Plague, Вы писали:
P>PS. Мое негативное настроение повлияло, что есть БД (SQL Server 2005) в которой СОВСЕМ НЕТ вьюх и процедур, к которой можно делать только запросы и поэтому запросы получаются не в одну страницу.
Здравствуйте, Quintanar, Вы писали:
Q>Есть, правда, диалекты SQL совмещенные с нормальным языком программирования (Q в kdb+), где у программиста есть вся власть над ядром БД, он всегда знает, что происходит и почему и ничего не оптимизируется автоматически.
А "не автоматическая" но и "не ручная" (а-ля "по запросу") оптимизация есть? Или я должен написать половину Оракла?
Q>Т.е. можно сразу писать оптимальный запрос на основе знаний о структуре БД, не пользуясь никакими анализаторами.
А если я вдруг захочу использовать оптимизаторы — "их там есть"?
Q>В результате получаем гибкость обычного языка программирования совмещенную с мощью SQL, в таких условиях запросы укорачиваются, а понятность программы возрастает.
Не понял, как может запрос укоротиться, если мне самому на основании данных "с потолка" придётся указывать: вот здесь делать индексный поиск, а вот здесь fullscan, а вот здесь ты сам проанализируй состав данных и реши какой тип поиска использовать... Да, ещё надо учитывать нахождение данных в кэше (а кто их знает, есть они там или нет...)
Да, для каких-то случаев возможно Ваш способ и будет "гибче и мощнее", но для каждого случая надо анализировать отдельно — какой подход что даст. Ибо SQL это не просто какой-то "язычёк", это, в первую очередь, математика. Плюс "тонны" человеко-лет по оптимизации обработки запросов. А Вы одним махом "на... всю оптимизацию!"
Здравствуйте, cl-user, Вы писали:
CU>А "не автоматическая" но и "не ручная" (а-ля "по запросу") оптимизация есть? Или я должен написать половину Оракла?
Нет. Хотите — пишите.
CU>А если я вдруг захочу использовать оптимизаторы — "их там есть"?
А что вы будете оптимизировать?
CU>Не понял, как может запрос укоротиться, если мне самому на основании данных "с потолка" придётся указывать: вот здесь делать индексный поиск, а вот здесь fullscan, а вот здесь ты сам проанализируй состав данных и реши какой тип поиска использовать... Да, ещё надо учитывать нахождение данных в кэше (а кто их знает, есть они там или нет...)
Потому, что kdb+ отходит от чистого SQL и фиксирует порядок записей, ты и так знаешь как будет проходить поиск. Если таблица отсортирована, то методом деления пополам, если нет, то полный проход.
CU>Да, для каких-то случаев возможно Ваш способ и будет "гибче и мощнее", но для каждого случая надо анализировать отдельно — какой подход что даст. Ибо SQL это не просто какой-то "язычёк", это, в первую очередь, математика. Плюс "тонны" человеко-лет по оптимизации обработки запросов. А Вы одним махом "на... всю оптимизацию!"
Еще раз повторяю, это не универсальная БД, а узкоспециализированная и требовательная к ресурсам. Свои задачи она полностью решает, программист может писать запросы сразу самым оптимальным в рамках БД способом без всяких там анализаторов и оптимизаторов. Когда нужно обрабатывать миллионы записей в секунду, оптимизаторы идут на юг.
Математикой пугать не надо, реляционная алгебра — это уровень спецкурса 10-го класса средней школы с математическим уклоном.
>>Плюс "тонны" человеко-лет по оптимизации обработки запросов.
Только до сих пор анализатор запроса — это вещь, жизненно необходимая для того, чтобы указать машине, что на самом деле нужно делать.
Здравствуйте, Курилка, Вы писали:
К>А может стоит использовать язык другой, более гибкий и подходящий под задачу (вопрос, конечно, какую именно), скажем тот же K?
А может не надо к? А? (с чувством безутешной надежды в голосе)
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Quintanar, Вы писали:
Q>Еще раз повторяю, это не универсальная БД, а узкоспециализированная и требовательная к ресурсам. Свои задачи она полностью решает, программист может писать запросы сразу самым оптимальным в рамках БД способом без всяких там анализаторов и оптимизаторов. Когда нужно обрабатывать миллионы записей в секунду, оптимизаторы идут на юг.
"Ещё раз" — это где? В этом топике не было.
А если вы о том, что для оптимальной работы _вся_ база должна быть в памяти + прочие ограничения на "сложную логику", то с этого и надо было начинать. Для "общего употребления" не годится, ибо по "узкоспециализированным предписаниям".
Q>Математикой пугать не надо, реляционная алгебра — это уровень спецкурса 10-го класса средней школы с математическим уклоном.
А в "узкоспециализированной" её (математики) сколько?
Q>Только до сих пор анализатор запроса — это вещь, жизненно необходимая для того, чтобы указать машине, что на самом деле нужно делать.
Естественно. В тех случаях когда _все_ данные _гарантированно_ не лезут в память, когда какая-то их часть уже может быть в кэше, всех или уже отобранных по подобному критерию... — т.е. когда "что делать" зависит от текущего состояния дел, которое в момент написания запроса неизвестно. И опять же — короче ваш "подробный" запрос не будет.
Ладно, можно "завязывать" — теперь я вас понял и посему претензий не имею
.
