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


SQL также не является решением - часть 2


С теми же целями Крис Дейт предлагал расширение языка 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.




Начало  Назад  Вперед