Разбивая SQL, даже если только синтаксический сахар

есть ли способ распределить кода SQL, так что это более читабельным и проверяемым?

мой код SQL часто становится длинной сложной серией вложенных соединений, внутренних соединений и т. д. это трудно написать и трудно отладить. Напротив, в процедурном языке, таком как Javascript или Java, можно было бы отщипнуть дискретные элементы как отдельные функции, которые вы бы назвали по имени.

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

например, концептуально сложный запрос может быть легко описан в псевдокоде следующим образом:

(getCustomerProfile) 
left join 
(getSummarizedCustomerTransactionHistory) 
using (customerId) 
left join
(getGeographicalSummaries) 
using (region, vendor)
...

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

  • стилус: CSS::
  • CoffeeScript: Javascript::
  • язык макросов SAS: SAS язык::
  • ? следующих объектов : SQL

и если конкретный вкус SQL имеет значение, большинство моя работа находится в PostgresQL.

http://lambda-the-ultimate.org/node/2440

повторное использование кода и модульность в SQL

противоречат ли базы данных и функциональное программирование?

12
abstraction sql

2 ответов

в большинстве баз данных вы можете делать то, что хотите, используя CTEs (общие табличные выражения):

with CustomerProfile as (
      getCustomerProfile
     ),
     SummarizedCustomerTransactionHistory as (
      getSummarizedCustomerTransactionHistory
     ),
     GeographicalSummaries as (
      getGeographicalSummaries
     )
select <whatever>

это работает для одного запроса. Он имеет то преимущество, что вы можете определить CTE один раз, но использовать его несколько раз. Кроме того, я часто определяю CTE под названием const имеет постоянные значения.

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

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

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

и SQL не является языком идей для абстракции. С хорошей практикой, соглашениями об именах и стилем отступов вы можете сделать его полезным. Я очень скучаю по некоторым вещам из" реальных " языков, таких как макросы, обработка ошибок (почему ошибки данных так трудно идентифицировать и обрабатывать вне меня), последовательные методы для общей функциональности (может кто-то сказать, групповая строка конкатенация), и некоторые другие особенности. Тем не менее, поскольку он ориентирован на данные и легко распараллеливается, он более полезен для меня, чем большинство других языков.

4

проблема здесь в том, что вам нужно думать о данных в реляционном ключе. Я не считаю, что этот тип абстракции правильно вписывается в реляционную модель. С точки зрения модульности SQL, это то, для чего предназначены хранимые процедуры и/или функции. Обратите внимание, что они имеют те же характеристики, что и методы в Java. Вы можете абстрагироваться таким образом. Другой способ-абстрагировать данные, о которых вы заботитесь, в материализованные представления. Сделав это, вы можете поместить обычный вид (см. виртуальная функция) поверх этих материализованных представлений, которые позволяют протестировать структуру данных, не касаясь "сырых" таблиц.

1