к вопросу про ORM
Dec. 18th, 2014 01:39 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
sab123Комментируем
http://ivan-gandhi.livejournal.com/3005103.html
http://blogs.tedneward.com/2006/06/26/The%2BVietnam%2BOf%2BComputer%2BScience.aspx
Проблема в том, что программа пишется на двух языках, которые исполняются в разных местах, с корявым интерфейсом между ними. Было бы красиво писать запросы не на корявом SQLе, а прямо в терминах объектного языка. Строя конвейеры обработки. Но пока из конвейера не начинают извлекаться записи, не выполняя его, а сохраняя конвейер в символическом виде. И только когда оказывается, что из конвейера надо извлечь результат, то начать выполнение - передать его оптимизатору, который переставит вещи в более эффективном порядке, и начнет выполнять.
То есть, база данных должна предоставить интерфейс для выполнения произвольного кода (виртуальную машину), а "OORM" язык должен позволять компилировать его исходный текст в эту машину и передавать для исполнения базе. В-принципе, такая штука уже есть, называется "хранимые процедуры", и это один из типовых способов писания базоданных, когда просто абсолютно все обращения к базе идут через хранимые процедуры. Интересные вопросы сводятся к тому, насколько статичны эти хранимые процедуры, и насколько сложно совершать обмен объектами между ними и внешним миром.
Обобщенная вритуальная машина позволит не загружать хранимые процедуры статически, а создавать их по необходимости на лету (но это необязательно хорошо, один из смыслов хранимых процедур - не дать случайно испортить базу кривыми запросами). Второй умный момент, который OORM-язык может позволить - это автоматически распределять выполнение кода между машинами где живет база, машинами где живет интерфейс с внешним миром, и квозможно какими-то промежуточными машинами.
Заодно и применение для вложенных структур находится - если их хранить, то получается очевидное решение для проблемы хранения полиморфных данных. Можно даже устроить индексирование по типу объектов, хранить идентификатор типа в виде строки, где каждый символ - идентификатор под-класса под родителем. Соответственно, каждый класс со всеми его подклассами будет идентифицироваться уникальным префиксом.
Возвращаясь к первому вопросу - давно хочется получить от интерпретируемых языков возможность делать две вещи: (1) извлечь содержимое некоего блока как синтаксическое дерево, чтоб его можно было ковырять и куда-то передавать и (2) выполнять преобразования этого дерева через исполнение кода на этапе компиляции.
http://ivan-gandhi.livejournal.com/3005103.html
http://blogs.tedneward.com/2006/06/26/The%2BVietnam%2BOf%2BComputer%2BScience.aspx
Проблема в том, что программа пишется на двух языках, которые исполняются в разных местах, с корявым интерфейсом между ними. Было бы красиво писать запросы не на корявом SQLе, а прямо в терминах объектного языка. Строя конвейеры обработки. Но пока из конвейера не начинают извлекаться записи, не выполняя его, а сохраняя конвейер в символическом виде. И только когда оказывается, что из конвейера надо извлечь результат, то начать выполнение - передать его оптимизатору, который переставит вещи в более эффективном порядке, и начнет выполнять.
То есть, база данных должна предоставить интерфейс для выполнения произвольного кода (виртуальную машину), а "OORM" язык должен позволять компилировать его исходный текст в эту машину и передавать для исполнения базе. В-принципе, такая штука уже есть, называется "хранимые процедуры", и это один из типовых способов писания базоданных, когда просто абсолютно все обращения к базе идут через хранимые процедуры. Интересные вопросы сводятся к тому, насколько статичны эти хранимые процедуры, и насколько сложно совершать обмен объектами между ними и внешним миром.
Обобщенная вритуальная машина позволит не загружать хранимые процедуры статически, а создавать их по необходимости на лету (но это необязательно хорошо, один из смыслов хранимых процедур - не дать случайно испортить базу кривыми запросами). Второй умный момент, который OORM-язык может позволить - это автоматически распределять выполнение кода между машинами где живет база, машинами где живет интерфейс с внешним миром, и квозможно какими-то промежуточными машинами.
Заодно и применение для вложенных структур находится - если их хранить, то получается очевидное решение для проблемы хранения полиморфных данных. Можно даже устроить индексирование по типу объектов, хранить идентификатор типа в виде строки, где каждый символ - идентификатор под-класса под родителем. Соответственно, каждый класс со всеми его подклассами будет идентифицироваться уникальным префиксом.
Возвращаясь к первому вопросу - давно хочется получить от интерпретируемых языков возможность делать две вещи: (1) извлечь содержимое некоего блока как синтаксическое дерево, чтоб его можно было ковырять и куда-то передавать и (2) выполнять преобразования этого дерева через исполнение кода на этапе компиляции.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2014-12-18 11:35 pm (UTC)no subject
Date: 2014-12-19 12:34 am (UTC)no subject
Date: 2014-12-19 04:05 am (UTC)И обычные запросы только так могут завесить сервер.
no subject
Date: 2014-12-19 05:33 am (UTC)А как через хранимую процедуру сохранять много данных?
Ну типа тысячу объектов надо сохранить.
no subject
Date: 2014-12-19 02:45 pm (UTC)Но кратко, если именно через хранимую, то основных подходов два:
1) Передача таблиц как параметров.
2) XML и его десериализация внутри процедуры.