Второе дыхание SQL. Техническое ессе.

[Dmitry67]

Дальние перспективы развития баз данных. Disclaimer : я не читаю литературу посвязенную далеким прогнозам. Пока хватает того что будет через год или два. Поэтому мозг у меня чист как белый лист и не affected чужими прогнозами. Так что если кто данной темой интересовался, интересно будет сравнить

В настоящее время многие считают язык SQL старомодным. Программисты, пишущие на современных ОО языках программирования как правило не любят, когда стройная концепция ОО начинает ‘прогибаться’ под реляционную базу данных.

То и дело возникают возгалсы – ура ! пришли OODB. Увы, это направление дискредетировало даже имя OODB, так что теперь предпочитают говорить о post-relational db.

Или ура – придет Yukon и можно будет забить на SQL и писать на C#. Еще один миф. Ну кое кто так и сделает… и даст много работы DBA, которые потом это будут заставлять работать с нормальной скоростью. Но OODB – это отдельная большая тема

Мысль же автора здесь – SQL не только не исчерпал свой потенциал, но скоро переживет свое второе рождение. Попытаюсь обосновать

Давным давно, когда я еще учился в знаменитой 30 школе, преподаватель программирования со смешной фамилией Мелведь (а был еще и Карп. Ему вырезали и принесли статью с заголовком ‘карп просится на сковородку’ ) заявил : Никогда не будет процессоров делающих более миллиарда тактов в секунду !

Время показало что он не прав. Но не прав в цифре, но не в принципе. Действительно, законы природы не дадут сделать процессор быстрее 10Ghz. А к этой величине мы идем слишком быстро, и я думаю многие помнят как клавиша Turbo переключала на экранчике частоту 6 и 12 Мhz.

Мы упремся в этот тупик около 2006-2007гг

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

Понятно что программировать для таких структур сложнее. Для этого есть специальные языки. И сам подход к программированию сильно отличается. Почти все придется переписывать… Почти все, кроме …

Конечно ! SQL ! Старый добрый SQL является языком со скрытой массивной паралелльностью. Уже сейчас оптимизаторы генерят параллельные планы. Все что потребуется – это правильный генератор плана выполнения. Как протокол IP из преданий старины глубокой пришел в наши дни, пережив несколько поколений технологий, так и SQL, как ни странно, окажется die hard нового века.

Итак, процессоров становится все больше и больше. В пределе на каждую запись приходится один процессор. И когда мы говорим update TAB set n=n+1 where COND, все процессоры получают одну и ту же каманду, независимо проверяют условие COND, и быстро производят изменение.

Цена Table scan становится равной одному абстрактному такту базы, а индексы становятся не нужны (искать нужный процессор не быстрее чем отослать команду всем).

В реальности конечно каждый процессор будет зранить много записей. Сколько ? База 1T при 32768 процессорах делится в размере 30M/процессор. А значит, процессор может все держать в памяти ! А как потеря питания ? Очевидно, у него должна быть батарейка, чтобы успеть сбросить это 30M, точнее, модифицированную часть, в свою энергонезависимую память.

Итак, мы получили database cell в виде процессора, маленькой специализорованной OS, быстрой памяти и памяти энергонезависимой. Сама система набирается из тысяч таких ячеек. Мы увидим (2009-2010г) базу данных в виде аппаратного комплекса. Предком таких систем являются сейчас disk arrays, которые постепенно ‘умнеют’

Само условие поиска может быть довольно сложным. Так как индексов нет, то мы просто можем проверить его в лоб. Вот и пришел конец full text search… Скорее всего поиск будет вестить не в plain rows, а в XML (тотлько плотно упакованных) документах.

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

Вот просто некоторые мысли.

[Palych]

… Скорее всего поиск будет вестить не в plain rows, а в XML (тотлько плотно упакованных) документах.

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

Вот просто некоторые мысли.

При таком раскладе не видно места для SQL. Мне кажется чтобы поддерживать перечисленное SQL должен так измениться, что ето будет уже не SQL.
Я думаю здесь на место индексов должны прийти ассоциативные связи. Как в нейронных сетях, тольдо более детерминированные и управляемые...
И соответственно - язык запросов, который сможет етим управлять. Только думается мне что кроме наличия слова SELECT у него не будет ничего общего с SQL...

[A. Fig Lee]

Вот просто некоторые мысли.

2. Что пьем?

В настоящее время многие считают язык SQL старомодным. Программисты, пишущие на современных ОО языках программирования....

1. SQL - query language, не программирования.

[Sergey___K]

SQL отомрет, как и традиционные реляционные БД. XPath/XQuery и всякая другая лабуда на базе XML будут везде. XML для данных и для кода и для UI. Вот только "прологоподобный" XSLT не понятно куда девать.
Индексы будут, ибо удобно.

[Dmitry67]

SQL отомрет, как и традиционные реляционные БД.

Год ?

[SVK]

Давным давно, когда я еще учился в знаменитой 30 школе,

[Off-topic]
Dmitry67, а есть еще на Привете кто из 30 школы? Среди моих знакомых - это два непересекающихся подмножества...
[/Off-topic]

[Sergey___K]

SQL отомрет, как и традиционные реляционные БД.

Год ?

Не скажу я год. Не знаю. Через одну версию после Юкона. Начиная с того момента, когда XQuery подобное вытеснит T-SQL, XML станет стандарнтым форматом возвращаемых датасетов. Грубо говоря, когда единственным коннективити c SQL Server'ом и другими серверами БД будет WebServices прямо на сервере.

[vc]

SQL отомрет, как и традиционные реляционные БД.

Год ?

Не скажу я год. Не знаю. Через одну версию после Юкона. Начиная с того момента, когда XQuery подобное вытеснит T-SQL, XML станет стандарнтым форматом возвращаемых датасетов. Грубо говоря, когда единственным коннективити c SQL Server'ом и другими серверами БД будет WebServices прямо на сервере.

It's beyond being funny, it's sad ...

VC

[sp123]

SQL отомрет, как и традиционные реляционные БД. XPath/XQuery и всякая другая лабуда на базе XML будут везде. XML для данных и для кода и для UI. Вот только "прологоподобный" XSLT не понятно куда девать.
Индексы будут, ибо удобно.

Не соглашусь. Back to the future. Иерархические базы существовали еще при царе Горохе и существуют до сих пор, а XML - не более чем вырожденный случай данного подхода и модный buzzword в резюме. К табличному представлению в свое время люди перешли из соображений удобства в ущерб производительности - элементарно затрахались с "реорганизациями базы" и написаниями тогдашних "XQueries". XML как способ организации данных в базе - это обратный переход, но с еще бОльшим ущербом для той же производительности - все ныне существующие парсеры и преобразователи типа XSLT в этом смысле чудовищны. Конечно, со времением индусы немерянно проимпрувят это дело и создадут еще один CODASYL. Да, во многих случаях XML удобен при описании кода, конфигураций чего бы то ни было, пересылке плоских файлов тудымо-сюдымо и все такое. Но с точки зрения хранения/поиска - не факт. Любой XML c заранее неизвестным количеством уровней вложенности может быть представлен в виде двух реляционных таблиц, одна из которых ссылается по ключу сама на себя; статичный XML раскладывается в серию тех же самых реляционных таблиц по одной штуке на уровень. Надуманно все.

[zVlad]

The biggest and most important difference between RDB and all other models (hierarchical, networking, and XML – which I am not familiar with, maybe it is not database model at all) is that RDB has theoretical background and SQL – language for mathematics’ method to manipulate with data organized as relationships.
I would compare RDB and SQL with, say, Pifagor’s theorem. How can one argue to that theorem and say it is obsolete?
RDB and SQL will exist as a core of informational systems until totally another method of data operating will be invented. On existing computer’s platforms I see no competitors for RDB and SQL in their areas.

[Sergey___K]

It's beyond being funny, it's sad ...

Сожалею.

Не соглашусь. Back to the future

Ну, топик был не в том, что лучше и что хуже, а то, как будет. Мне может что-то нравится и не нравиться, не об моих предпочтениях идет речь. Про производительность вспоминают после "общей стоимости владения" или как один из ее факторов. То, что затраты на XML обработку охрененные понятно. Я просто хочу напомнить, что в свое время даты и числа в DBF файлах хранились, как строки и вызывали серъезное негодование у "прогрессивной общественности". (MS Word -овский документ казался чудовищным с его размерами. И много чего.)

Но с точки зрения хранения/поиска - не факт ...Любой XML c заранее ...

Я не хочу сейчас обсуждать, как можно представить XML. Хранить данные можно по всякому. Суть в том, в каком виде оно процессится и представляется наружу. Бизнесу/индустрии может быть удобнее все иметь в одном формате и обрабатывать все одинаково.

Кое что уже есть и сейчас
http://msdn.microsoft.com/webservices/default.aspx?pull=/library/en-us/dnsql90/html/sql2005websvc.asp

Если не зацикливаться на хорошо-плохо, глядеть на всю картину с точки зрения "не специалиста по оптимизации данных" , то все ложится на свои места. Тогда, заодно, можно понять, на кой ляд C# и прочий .Net вводится как средство написания хранимых процедур.

Я бы, даже, рискуя опять опечалить некоторых, могу предположить, что Web Server и дата сервер сольются в одно "тело", выдаюшее HTML и обрабатывающее code behind. И оперировать они будут данными слитыми с их представлениями.

[tengiz]

...is that RDB has theoretical background and SQL – language for mathematics’ method to manipulate with data organized as relationships. I would compare RDB and SQL with, say, Pifagor’s theorem. How can one argue to that theorem and say it is obsolete?

SQL, к сожалению, в этой компании формально чистых вещей и строгих теорем оказался по чистому недоразумению. SQL - это такая ж те теорема Пифагора, как и Вижуал Бейзик - язык программирования. Реляционная алгебра, котрая является намного более формальным языком манипулирования множествами строк, не так, к сожелению удобна для не очень подготовленных пользователей. SQL, являющися слившимися в экзтазе QUEL - (Query Language) и Structured English Query Language (SEQUEL), и наконец, после потери нескольких букв в аббревиатуре ставший тем, что знают все, но по привычке продолжают произностиь SEQUEL, с самого начала предназначался для конечных пользователей-чайников. Со всеми вытекающими последствиями для строгости и формальной чистоты. Конечно, великая и могучая IBM, а затем и ANSI/ISO комитет титаническими усилиями придали его современному варианту более-менее удобоваримый вид. Но Пифагор бы отравился ядом от такого сравнения.

[Dmitry67]

1 Я просто хочу напомнить, что в свое время даты и числа в DBF файлах хранились, как строки и вызывали серъезное негодование у "прогрессивной общественности".

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

1 Ужас
Слава богу что в SQL они хранятся в бинарном виде

2 Гы
С чего Вы это взяли ? Про Юкон почитали ???
Гы. Еще три раза Гы

[Sergey___K]

С чего Вы это взяли ? Про Юкон почитали

Ага!

[Strannik223]

SQL отомрет, как и традиционные реляционные БД. XPath/XQuery и всякая другая лабуда на базе XML будут везде. XML для данных и для кода и для UI. Вот только "прологоподобный" XSLT не понятно куда девать.
Индексы будут, ибо удобно.

XML это всего навсего стандартный способ представления данных. Причем очень базового уровня, по аналогии со связью "транспортного". Попробуйте воспроизвести документ Ворда из xml не зная схемы! Это то же самое что умение декодировать TCP не дает возможности читать письма пока не понимаешь SMTP.

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

<added>
Иерархические структуры и сейчас можно эмулировать в плоских таблицах, но я говорю о естественном для клиента представлении иерархий, которые внутри сервера скорее всего останутся плоскими таблицами
</added>

И скорее всего эта информация будет хранится в виде традиционных таблиц с реляционными связями.

То есть sql станет фундаментом для более высокоуровнего языка запросов, но уж никак не умрет.

[zVlad]

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

Я не знаю, Tengiz, откуда у Вас такие ассоциации взялись, лично мне кажется сравнение SQL и RDB с Пифагоровской теоремой вполне уместным - не зря же Кодд был удостоен наград, достойных Пифагора! Сравнение же с Вижуал Бейсик вообще не уместно.
Tengiz, поглядите непредвзято вокруг себя - много ли НАСТОЯЩИХ ТЕХНОЛОГИЙ создано в программировании? Ну хотя бы за последние 20-ть лет? Да, названий много, но ведь все это не более чем bait - приманка . Грустно от всего этого, не так ли?

[tengiz]

Я не знаю, Tengiz, откуда у Вас такие ассоциации взялись, лично мне кажется сравнение SQL и RDB с Пифагоровской теоремой вполне уместным - не зря же Кодд был удостоен наград, достойных Пифагора!Сравнение же с Вижуал Бейсик вообще не уместно.

Кодд не имеет никакого отношения к SQL, насколько я понимаю. Реляционная теория и реляционная алгебра так же далеки от SQL, как латынь от фени, если позволите мне такую гиберполу. Специально подчёркиваю - реляционная теория и реляционная алгебра Пифагору возможно понравились бы. От SQL бы ему стало плохо.

[tengiz]

Для хохмы набрал в гугле два слова - codd sql: http://www.google.com/search?hl=en&ie=U ... q=codd+sql Первая же ссылка выдаёт

Codd thought sql was an abomination, Date still thinks so.

Не откажу себе в удовольствии предложить свой перевод:

Кодд считал, что sql - это позор, Дейт до сих пор продолжает так считать.

[Merle]

The biggest and most important difference between RDB and all other models (hierarchical, networking, and XML – which I am not familiar with, maybe it is not database model at all) is that RDB has theoretical background and SQL – language for mathematics’ method to manipulate with data organized as relationships.

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

[flip_flop]

Действительно, законы природы не дадут сделать процессор быстрее 10Ghz.

[Dmitry67]

Действительно, законы природы не дадут сделать процессор быстрее 10Ghz.

А чаво ?
Елехтроны так быстро бегать не умеють

[zVlad]

Для хохмы набрал в гугле два слова - codd sql: http://www.google.com/search?hl=en&ie=U ... q=codd+sql ......

Ссылка так сказать из разряда ОБС.
Так или иначе SQL - весьма логичный и естественный язык. В нем нет надуманных конструкций. Он универсален и расширяем. Это залог его долгого существование и конкуретноспособности.

[zVlad]

.......... Конечно, великая и могучая IBM, а затем и ANSI/ISO комитет титаническими усилиями придали его современному варианту более-менее удобоваримый вид. Но Пифагор бы отравился ядом от такого сравнения.

Самое время потолковать об альтернативах. Мне например известен лишь QBE как альтернатива. В горячо любимом мною QMF есть третий способ написания запросов - Prompted-SQL, но его нельзя называть языком как таковым.
Кто может поведать больше?

[tengiz]

Так или иначе SQL - весьма логичный и естественный язык. В нем нет надуманных конструкций. Он универсален и расширяем. Это залог его долгого существование и конкуретноспособности.

Точно - как и вижуал бейзика, который живуч как чёрт. Насчёт ОБС ссылки - вот названия статей самого Кодда:

E. F. Codd: Fatal Flaws in SQL - Part ONE. CMG Transactions 1(1): 29-33 (1989)
E. F. Codd: Fatal Flaws in SQL - Part Two. CMG Transactions 1(1): 35-37 (1989)

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

Причина по которой SQL не пользуется большим почётом у специалистов - резкий контраст между формальной строгостью реляционной терории и тем, что получилось из SQL.

[tengiz]

Кто может поведать больше?

Смотри в корень - реляционная алгебра или реляционное исчисление.