Mar. 23rd, 2014

egorius: (Default)

Часто приходится видеть, как разработчик, столкнувшись с задачей, первым делом берется за привычный процедурный инструмент, даже не вспомнив про мантру Кайта:

You should do it in a single SQL statement if at all possible.

Откуда такая мантра? Во-первых, процедурный подход оперирует циклами, а SQL — множествами. База данных может работать с множествами на порядок эффективнее, чем с помощью циклов; это лишь один способ из целого арсенала, которым располагает СУБД. Во-вторых, декларативный подход описывает желаемый результат, а процедурный — точный способ достижения этого результата. Поэтому декларативная программа зачастую оказывается короче и проще.

Почему же предпочтение отдается PL/SQL? Тут можно было бы порассуждать об эффективности, но, на мой взгляд, реальная причина проще: декларативный подход требует смены парадигмы программирования, а это дается нелегко.

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

Напомню, что произведением матрицы A(L×M) на матрицу B(M×N) является матрица С(L×N), элементы которой ci,j = Σk = 1...M  ai,k×bk,j. Для иллюстрации процедурного подхода возьмем следующие определения (я использовал язык Си):

int a[L][M];
int b[M][N];
int c[L][N];

Алгоритм традиционен и хорошо иллюстрирует вышеизложенную мысль про циклы:

int i, j, k;
for (i=0; i<L; i++)
  for (j=0; j<N; j++)
    for (k=0; k<M; k++)
      c[i][j] += a[i][k] * b[k][j];

А сможете ли вы сделать это на SQL? )

Profile

egorius: (Default)
egorius

March 2025

M T W T F S S
      1 2
34 567 89
1011 121314 1516
17181920212223
24252627 28 29 30
31      

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated May. 13th, 2025 01:02 pm
Powered by Dreamwidth Studios