Конец архитектурной эпохи

SQL также не является решением


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

Переосмысление количества одновременно существующих языков и их сложности будет обладать колоссальным положительным побочным эффектом. В настоящее время SQL – это унаследованный язык со многими известными серьезными недостатками, ряд из которых отмечался Крисом Дейтом еще два десятка лет тому назад [Dat84]. Следующая попытка разработки языков может оказаться более удачной.

При переосмыслении языков доступа к данным авторам вспоминается яростная дискуссия 1970-х гг. С одной стороны, имелись сторонники подъязыков данных, для которых могли бы иметься интерфейсы с любыми языками программирования. Это привело к появлению интерфейсов с высокими накладными расходами, таких как JDBC и ODBC. Кроме того, эти интерфейсы очень трудно использовать из традиционного языка программирования. С другой стороны, некоторые члены сообщества баз данных предлагали намного более привлекательные возможности доступа к базам данных, встраиваемые в языки программирования. Типичными представителями этих языковых средств в 1970-е гг. являлись Pascal R [Sch80] и Rigel [RS79]. В обоих этих средствах обеспечивалась полная интеграция со средствами языков программирования, такими как организация логики управления, локальные переменные и т.д.
С теми же целями Крис Дейт предлагал расширение языка PL/1 [Dat76].

Как видно, ни один из этих языков не вошел в широкую практику, и победу одержало направление поъязыков данных. Сообщество баз данных средства разработало невероятно безобразные средства сопряжения языков программирования с подъязыком баз данных, и результатом являются низко производительные системы, происходящие из прошедшей эпохи. Поэтому авторы статьи выступают за полный отказ от подъязыков данных в пользу встраивания в языки программирования средств доступа к данным.

В сообществе языков программирования наблюдается бурное развитие «малых языков», таких как Python, Perl, Ruby и PHP. Идея состоит в том, чтобы для решения любой конкретной задачи можно было использовать язык, наиболее подходящий именно в этом случае. Малые языки привлекательны еще и тем, что их легче изучать, чем языки общего назначения. При взгляде со стороны это явление кажется симптомом конца эпохи «безразмерности» в мире языков программирования.

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

В настоящее время любимым примером этого подхода у авторов является Ruby-on-Rails. Эта система основана на малом языке Ruby, расширенном интегрированной поддержкой доступа к данным и манипулирования ими на основе паттерна программирования «model-view-controller». Ruby-on-Rails компилируется в стандартный JDBC, но вся сложность этого интерфейса скрывается.

Поэтому авторы планируют отказаться от применения языка C++ для программирования хранимых процедур в среде H-Store и перейти к использованию Ruby-on-Rails. Конечно, подсистема поддержки времени исполнения Ruby-on-Rails должна быть скомпонована в одном адресном пространстве совместно с СУБД, и ее необходимо изменить, чтобы вызовы служб СУБД производились с использованием высокопроизводительных локальных вызовов процедур, а не JDBC.


Содержание раздела