Комментарии 42
Черт, звучит впечатляюще!
Скачал, буду смотреть…
Скачал, буду смотреть…
Прошу прощение, давно не заглядывал в .NET, а в чем отличие от Linq (X/D, путаюсь в них)? Насколько я понимаю, это нечто среднее между Linq и Protocol Buffers (от Google)? Как обстоят дела с производительностью?
Ну, LINQ — он должен с чем-то работать, сам по себе он данные хранить не может. Нужна база, например, SQL. К тому же, делать запросы к массивам в LINQ — еще то удовольствие.
Google, вроде, JOIN'ы не делает — по крайней было так до недавнего времени. Да и со сложностью объектов там — отдельная история. Да и .NET вряд ли входит в список любимых платформ Гугла. :-)
Производительность — на уровне. По крайней мере, сравнение с другими объектными базами или мапперами — далеко не в их пользу. :-) Конечно, многое зависит от сложности объектов, типов запросов — но одно правило работает точно: чем ближе объект к реальному использованию (читай — чем сложнее объект), тем эффективнее работает Eloquera — по сравнению со стандартными SQL-базами, где 5-10 JOIN'ов могут выполняться сотни миллисекунд или даже секунды.
Google, вроде, JOIN'ы не делает — по крайней было так до недавнего времени. Да и со сложностью объектов там — отдельная история. Да и .NET вряд ли входит в список любимых платформ Гугла. :-)
Производительность — на уровне. По крайней мере, сравнение с другими объектными базами или мапперами — далеко не в их пользу. :-) Конечно, многое зависит от сложности объектов, типов запросов — но одно правило работает точно: чем ближе объект к реальному использованию (читай — чем сложнее объект), тем эффективнее работает Eloquera — по сравнению со стандартными SQL-базами, где 5-10 JOIN'ов могут выполняться сотни миллисекунд или даже секунды.
поддержка LINQ / EF есть?
Вы определенно читаете мысли! :-) Да, разработка над LINQ/EF поддержкой идет довольно активно. Возможно, этот интерфейс выйдет отдельным релизом для разработчиков.
Кстати, как Вы думаете, «чистый» LINQ, без EF, по принципу LINQ-to-SQL — уже не жилец? Этот вопрос дискутируется у нас довольно долго (и я сторонник EF — если что :-)). Спасибо.
Кстати, как Вы думаете, «чистый» LINQ, без EF, по принципу LINQ-to-SQL — уже не жилец? Этот вопрос дискутируется у нас довольно долго (и я сторонник EF — если что :-)). Спасибо.
пока не знаю насчет linq2sql… но, насколько я знаю, его разработка сворачивается
EF пока сырой, есть баги, как в студии так и в нем самом, посмотрим на него в .net 4.0 ;)
EF пока сырой, есть баги, как в студии так и в нем самом, посмотрим на него в .net 4.0 ;)
В принципе, EF внутри — это набор интерфейсов с обертками. Баги — это понятно, они неизбежны при попытках скрестить ежа и ужа — объекты и реляционные базы. В O/R mapper'ах встречаются и проблемы похуже.
В нашем случае таких трудностей нет, так что надеемся на качественный результат. :-)
В нашем случае таких трудностей нет, так что надеемся на качественный результат. :-)
ну и меня удручает connection string у EF :(
А оно круче, чем db4o?
И я что-то не увидел транзакции — ни в коде, ни в обсуждении. Интересно, как там дело с ACID?
И я что-то не увидел транзакции — ни в коде, ни в обсуждении. Интересно, как там дело с ACID?
Вы писали запросы для db4o? Здорово! Вот мы тоже пробовали. Сказать, что они работают медленно, а написание их запросов — дело несколько муторное, это сделать некоторый комплимент, честно говоря. Да и нет у них JOIN'ов и операций по массивам (по секрету скажу, что db4o не поддерживает даже хранение многомерных массивов).
Как Вы думаете, SQL — с JOIN'ами и поддержкой любых массивов — не более удобный вариант, чем SODA? :-) А быстрее SODA у db4o ничего нет.
Над транзакциями идет работа — в данном билде они отключены, т.к. этот билд официально «украден» у разработчиков посреди разработки.
Да и транзакции в db4o — одна на всех, т.к. реально все операции выполняются последовательно.
Включая запросы. Поэтому говорить о параллельной работе и изоляции транзакций в db4o особенно не приходится.
Как Вы думаете, SQL — с JOIN'ами и поддержкой любых массивов — не более удобный вариант, чем SODA? :-) А быстрее SODA у db4o ничего нет.
Над транзакциями идет работа — в данном билде они отключены, т.к. этот билд официально «украден» у разработчиков посреди разработки.
Да и транзакции в db4o — одна на всех, т.к. реально все операции выполняются последовательно.
Включая запросы. Поэтому говорить о параллельной работе и изоляции транзакций в db4o особенно не приходится.
Советую вам подумать о карьере маркетолога, если вы еще не там :) вкусно все расписываете.
А вот про отсутствие транзакций — совсем плохо:(
Боюсь, что смысла в такой БД сейчас, кроме академического, нет; пусть даже она и «украдена».
Главное, чтобы все так и не осталось на уровне embedded storage. Будем ждать билдов с транзакциями.
А вот про отсутствие транзакций — совсем плохо:(
Боюсь, что смысла в такой БД сейчас, кроме академического, нет; пусть даже она и «украдена».
Главное, чтобы все так и не осталось на уровне embedded storage. Будем ждать билдов с транзакциями.
Спасибо за комплимент, но я — вполне такой обычный программист. Причем — в меру забывчивый. Я-то забыл сказать, что это клиент-серверная база, и ориентирована на веб. На ту часть, которая использует .NET с mySQL и прочими базами без long-running transactions — как оказалось, это вполне широкая аудитория (правда, в США и в Европе — по России и Украине картина очень отличается). И транзакции в данном сегменте «приобретают особый смысл» (ц).
Фактически нас просили об атомарности и изоляции для отдельных операций типа вставки, обновления и удаления (это есть). Так же соблюдается консистентность для этих операций. Консистентность при запросах еще не готова для коммерческого релиза — но, как ни странно, это не останавливает от использования подобных баз в веб.
Сейчас база работает на блокировках. Кстати, Вы — сторонник версионных или блокирующих баз? :-)
Фактически нас просили об атомарности и изоляции для отдельных операций типа вставки, обновления и удаления (это есть). Так же соблюдается консистентность для этих операций. Консистентность при запросах еще не готова для коммерческого релиза — но, как ни странно, это не останавливает от использования подобных баз в веб.
Сейчас база работает на блокировках. Кстати, Вы — сторонник версионных или блокирующих баз? :-)
От использования php в веб для сайтов, работающих с деньгами клиента, не останавливает даже отсутствие там нормальной детерминистической обработки ошибок.
Пор поводу «версионность или блокировки» — по ситуации. Это как ответ на вопрос — что лучше, бульдозер или самолет :)
При обычных нагрузках хватает обычных блокирующих механизмов, но если нужно обеспечить отсуствие «затыка» для многих параллельных транзакций, тем более — на уровне RepeatableRead и выше, ИМХО стоит посмотреть на версионные.
Пор поводу «версионность или блокировки» — по ситуации. Это как ответ на вопрос — что лучше, бульдозер или самолет :)
При обычных нагрузках хватает обычных блокирующих механизмов, но если нужно обеспечить отсуствие «затыка» для многих параллельных транзакций, тем более — на уровне RepeatableRead и выше, ИМХО стоит посмотреть на версионные.
Еще один голос за версионность! В принципе, разработка идет именно в этом направлении, но у «блокировщиков» в компании есть свои аргументы, которыми они вносят некоторую неуверенность в технически не очень подготовленные головы. :-) Да и SQL Server — по большей части блокирующая база, а это как бы эталон для .NET.
AFAIK все эти блокировки не нужны.
Если вы нигде не делаете in-place update'ы, вы нахаляву получаете
— транзакционную семантику
— undo любых операций
— snapshot'ы
— отсутствие проблем с concurrency
CouchDB работает по такому принципу.
Если вы нигде не делаете in-place update'ы, вы нахаляву получаете
— транзакционную семантику
— undo любых операций
— snapshot'ы
— отсутствие проблем с concurrency
CouchDB работает по такому принципу.
Да, просто очень много народа на .NET сидит под SQL Server — а это блокирующая база. Работа с версиями в MS SQL Server — сплошные слезы, с переписыванием данных в tempdb, и обратной записью в базу.
Но внутри Eloquera работает на версионном принципе, просто это еще не вынесено на логический уровень. Сейчас разработка крутится вокруг этого.
Но внутри Eloquera работает на версионном принципе, просто это еще не вынесено на логический уровень. Сейчас разработка крутится вокруг этого.
Сидят, потому что есть, на чем сидеть, а исторически это — реляционная БД, отсюда все. И, знаете, для своих границ она весьма неплоха.
Работа с версиями — snapshot isolation вас не устраивает, или вы о чем-то еще?
Тогда я помечтаю еще и об «историческом» хранилище «из коробки» :)
Работа с версиями — snapshot isolation вас не устраивает, или вы о чем-то еще?
Тогда я помечтаю еще и об «историческом» хранилище «из коробки» :)
Snapshot isolation иногда показывает чудеса медлительности для обновления одного поля в нескольких сотнях строк данных. Возможно, что это специфика софта и индустрии (данные с разведочных нефтяных скважин), но пришлось в MS SQL от нее отказаться, и решать вопрос редизайном некоторых частей в базе.
Я не ругаю MS SQL — она кормила меня ооочень долгое время. :-) И делала это вполне замечательно — у наших админов седых волос было немало, но все же не так, как у Ораклистов (или связь тут обратная? :-)) Но реляционно-объектное несоответствие никто не отменял, поэтому при хранении сложных объектов (включая сложные иерархии данных в XML) часто приходится искусствено вводить сущности, которых нет в объектах (например, для наследования).
«Исторические данные» с возможностью сложной аналитики или просто «чтобы было»? :-) Ну, IBM с Oracle тут не одну собаку съели, но ту самую еще, кажется, не нашли. :-)
Я не ругаю MS SQL — она кормила меня ооочень долгое время. :-) И делала это вполне замечательно — у наших админов седых волос было немало, но все же не так, как у Ораклистов (или связь тут обратная? :-)) Но реляционно-объектное несоответствие никто не отменял, поэтому при хранении сложных объектов (включая сложные иерархии данных в XML) часто приходится искусствено вводить сущности, которых нет в объектах (например, для наследования).
«Исторические данные» с возможностью сложной аналитики или просто «чтобы было»? :-) Ну, IBM с Oracle тут не одну собаку съели, но ту самую еще, кажется, не нашли. :-)
Не, я не про snaphsot в MsSQL, я интересовался, похожа ли она на то, что вы называете версионностью.
Исторические данные — различные: история изменений, заточенная под OLAP и отложенный OLAP, история транзакций под тем же соусом.
С Oracle и DB2 сильно плотно не работал, поэтому не могу ничего сказать, как это там :( В MsSQL точно никак :)
Исторические данные — различные: история изменений, заточенная под OLAP и отложенный OLAP, история транзакций под тем же соусом.
С Oracle и DB2 сильно плотно не работал, поэтому не могу ничего сказать, как это там :( В MsSQL точно никак :)
Версионность, по крайней мере, в ближайшей версии, базируется на snapshot модели изоляции.
Возможно, наш подход несколько упрощен, но он использует простую идею: транзакция, начавшаяся в момент N, видит только то, что было в момент N (все N — уникальны, пусть это будет глобальный возрастающий счетчик). Взаимодействие транзакций между собой пока не предусмотрено.
Правда, журналирование мы еще не собираемся добавлять — это полезно для корпоративных баз, но вряд ли — для веб. А на грандов нам замахиваться немного рано. :-) Да и OLAP с объектами не вяжется немного. Но у нас есть кое-что в рукаве для похожих случаев, так что — сюрпризы будут. :-)
Возможно, наш подход несколько упрощен, но он использует простую идею: транзакция, начавшаяся в момент N, видит только то, что было в момент N (все N — уникальны, пусть это будет глобальный возрастающий счетчик). Взаимодействие транзакций между собой пока не предусмотрено.
Правда, журналирование мы еще не собираемся добавлять — это полезно для корпоративных баз, но вряд ли — для веб. А на грандов нам замахиваться немного рано. :-) Да и OLAP с объектами не вяжется немного. Но у нас есть кое-что в рукаве для похожих случаев, так что — сюрпризы будут. :-)
Для электронного магазина a la быдлопхп (sic!) с минимумом апдейтов можно обойтись и блокировками. Имхо.
А вообще я думаю, что для объектной БД стоит вовсе пересмотреть концепцию транзакций.
Ну, если интересны мои «фантазии» по этому поводу, то я думаю, что в будущем будет не просто «уровень изоляции», а настройки стратегии для snapshot factory + change merger, позволяющие выбрать нужный уровень безопасности.
А вообще я думаю, что для объектной БД стоит вовсе пересмотреть концепцию транзакций.
Ну, если интересны мои «фантазии» по этому поводу, то я думаю, что в будущем будет не просто «уровень изоляции», а настройки стратегии для snapshot factory + change merger, позволяющие выбрать нужный уровень безопасности.
В принципе, если предоставить своего арбитра транзакций (а это классы с определенными вполне интерфейсами), то можно делать свою стратегию управлениями транзакций. Обычно такие классы уже встроен в базу, но ничего не мешает делать его «съемным» и заменять по желанию программиста.
Другое дело, что написание такого класса — дело, требующего глубокого понимания устройства транзакционных баз.
А можно побольше о Ваших «фантазиях» по поводу транзакций? Если бы Вам дали возможность сформировать систему транзакций, что бы Вы отметили как самое важное и необходимое? И какие уровни безопасности Вы бы хотели видеть?
Другое дело, что написание такого класса — дело, требующего глубокого понимания устройства транзакционных баз.
А можно побольше о Ваших «фантазиях» по поводу транзакций? Если бы Вам дали возможность сформировать систему транзакций, что бы Вы отметили как самое важное и необходимое? И какие уровни безопасности Вы бы хотели видеть?
Ох, блин, счас я нафантазирую :) Как тут принято писать, в комнате жарко, чашка на столе полна ацетона, его пары помогают увидеть нижеследующее.
Если я правильно понимаю, все эти уровни изоляции были введены как компромисс между производительностью и «здравым смыслом» :) Соответственно,
— шаг 1 — убираем промежуточные уровни изоляции: данные либо полностью непротиворечивы (в терминах объектов), либо данных нет; за этим следит инфраструктура, а не пользователь, который счас должен почти «угадывать» уровень изоляции и делать выкладки;
— шаг 2 — добавляем самонастраивающийся арбитр транзакций: пусть начинает с самого высокого уровня изоляции (версии), но постепенно «ослабляет болты» на основании статистики запросов; хинты ему приветствуются — это как раз то, что можно программисту потюнинговать, ибо самописный арбитр — это для тех, кто хочет — ррраз! — взять и обуглить себе мозг.
— шаг 3 — SQL в топку, даешь HQL и Linq, раз уж у вас .net; ну или Fluent QueryBuilder, НЕ основанный на склейке строк :)
— шаг 4 — Читабельный журнал транзакций; в прочем, это уже к истории относится, там и отвечу.
— шаг 5 — Раз уж у нас версии, то должен быть user-defined merger данных (может, мы такие извращенцы, что полная изоляция данных нас не устраивает), выбранный из предоставленных или «съемный»
Фуух, я бы и дальше молотил, но ацетон рассеялся… пока что все, не принимайте сказанное всерьез :)
Если я правильно понимаю, все эти уровни изоляции были введены как компромисс между производительностью и «здравым смыслом» :) Соответственно,
— шаг 1 — убираем промежуточные уровни изоляции: данные либо полностью непротиворечивы (в терминах объектов), либо данных нет; за этим следит инфраструктура, а не пользователь, который счас должен почти «угадывать» уровень изоляции и делать выкладки;
— шаг 2 — добавляем самонастраивающийся арбитр транзакций: пусть начинает с самого высокого уровня изоляции (версии), но постепенно «ослабляет болты» на основании статистики запросов; хинты ему приветствуются — это как раз то, что можно программисту потюнинговать, ибо самописный арбитр — это для тех, кто хочет — ррраз! — взять и обуглить себе мозг.
— шаг 3 — SQL в топку, даешь HQL и Linq, раз уж у вас .net; ну или Fluent QueryBuilder, НЕ основанный на склейке строк :)
— шаг 4 — Читабельный журнал транзакций; в прочем, это уже к истории относится, там и отвечу.
— шаг 5 — Раз уж у нас версии, то должен быть user-defined merger данных (может, мы такие извращенцы, что полная изоляция данных нас не устраивает), выбранный из предоставленных или «съемный»
Фуух, я бы и дальше молотил, но ацетон рассеялся… пока что все, не принимайте сказанное всерьез :)
Мне нравится ход Ваших мыслей. :-)
Шаг 1 реализуется версионностью. С классическим «но» — не все обновления могут быть осуществлены. Поэтому вопрос о полной непротиворечивости полностью решен быть не может.
В принципе, «ослаблять болты» может не получиться — требования первого шага мешают. Какие уровни промежуточной изоляции Вы бы рассмотрели для применения в своих приложениях?
У нас реализовано некоторое непустое :-) перечесение с HQL (хотя за особой строгостью мы не гнались). К примеру, у нас можно делать JOIN'ы по любым полям, а не только логически связанным. Ну, и поддержка массивов, на мой взгляд, у нас намного мощнее — можно искать по полям объектов в массиве, например.
Журнал транзакций (в виде внутреннего лога) у нас запланирован на версии «попозже» — народ не очень просит.
А вот насчет user-defined merger я бы хотел узнать побольше. Что именно Вы хотели бы видеть в этом случае?
P.S. Ацетон у Вас замечательный — я бы выписывал его многим программистам. :-)
Шаг 1 реализуется версионностью. С классическим «но» — не все обновления могут быть осуществлены. Поэтому вопрос о полной непротиворечивости полностью решен быть не может.
В принципе, «ослаблять болты» может не получиться — требования первого шага мешают. Какие уровни промежуточной изоляции Вы бы рассмотрели для применения в своих приложениях?
У нас реализовано некоторое непустое :-) перечесение с HQL (хотя за особой строгостью мы не гнались). К примеру, у нас можно делать JOIN'ы по любым полям, а не только логически связанным. Ну, и поддержка массивов, на мой взгляд, у нас намного мощнее — можно искать по полям объектов в массиве, например.
Журнал транзакций (в виде внутреннего лога) у нас запланирован на версии «попозже» — народ не очень просит.
А вот насчет user-defined merger я бы хотел узнать побольше. Что именно Вы хотели бы видеть в этом случае?
P.S. Ацетон у Вас замечательный — я бы выписывал его многим программистам. :-)
Отвечу сразу и про уровни, и merge; только сильно не ругайте, если чушь несу :)
Классические транзакции (в реляционных БД) имеют некоторую область действия — «захват» данных при выполнении. В ООП-транзакциях, где обновляются графы объектов, транзакции должны «захватывать» объект и/или его соседей в графе. Уровнем транзакции (условно) будет глубина связей, на которую распространяется действие транзакции.
Merger в таком случае будет, например, действовать как маска — кто из соседей или какие из полей объекта игнорируются при захвате.
Классические транзакции (в реляционных БД) имеют некоторую область действия — «захват» данных при выполнении. В ООП-транзакциях, где обновляются графы объектов, транзакции должны «захватывать» объект и/или его соседей в графе. Уровнем транзакции (условно) будет глубина связей, на которую распространяется действие транзакции.
Merger в таком случае будет, например, действовать как маска — кто из соседей или какие из полей объекта игнорируются при захвате.
НЛО прилетело и опубликовало эту надпись здесь
Насколько помню, в db4o нет контроля за изменениями структуры объектов. Т.е. было поле int, стало float — все будет работать, только в данных будет мусор. У нас при изменении структуры объектов выскакивает exception, мол, структура разная, класс не тот, что писали.
В данном случае, лучше всего подойдет наследование от старого класса — все запросы будут работать правильно, никаких особых изменений не нужно. Запросы к старому классу будут возвращать объекты и старого, и нового типа (если не использовать SELECT ONLY, конечно, который ограничивает выборку только определенным классом).
В данном случае, лучше всего подойдет наследование от старого класса — все запросы будут работать правильно, никаких особых изменений не нужно. Запросы к старому классу будут возвращать объекты и старого, и нового типа (если не использовать SELECT ONLY, конечно, который ограничивает выборку только определенным классом).
НЛО прилетело и опубликовало эту надпись здесь
Есть вариант использования Eloquera как локальную базу, но тогда теряется параллельность работы. Для этого достаточно указать в качестве сервера подключения имя (local). Как-то так:
В таком случае, security отключается (точнее, не включается :-)).
В нынешней конфигурации база настроена на скорость работы с несколькими клиентами, поэтому использование памяти довольно велико (128MB-384MB в зависимости от размера базы — эти данные для сотен тысяч или миллионов объектов). Но настройки можно «подкручивать» в конфигурации.
DB db = new DB("server=(local);options=none;")
В таком случае, security отключается (точнее, не включается :-)).
В нынешней конфигурации база настроена на скорость работы с несколькими клиентами, поэтому использование памяти довольно велико (128MB-384MB в зависимости от размера базы — эти данные для сотен тысяч или миллионов объектов). Но настройки можно «подкручивать» в конфигурации.
Не принимайте за наезд… Но зачем тут SQL? Раз уж вы пользуетесь .NET, так отобразите же запросы в .NET'овские языки. Как-то не греет душу отправка текста серверу. Пусть это сразу же будет well-formed запрос, со всеми полагающимися плюшками (type safety, compositionality, etc.)
Также не очень ясно, как SQL уживается с объектами. Все-таки совсем разные вещи.
Также не очень ясно, как SQL уживается с объектами. Все-таки совсем разные вещи.
SQL — язык, который знает любой программист баз данных. Если у Вас компания, в которой работают люди, знающие SQL, то не легче ли перейти на новый продукт, экономящий время разработки, который Ваши работники уже знают? Отзывы от партнеров — положительные. :-)
А насчет type safety и прочих прелестей — идет работа над EF-интерфейсом к базе.
Хотите посмотреть, как уживаются объекты с SQL — будем рады, если попробуете и выскажете своё мнение.
А насчет type safety и прочих прелестей — идет работа над EF-интерфейсом к базе.
Хотите посмотреть, как уживаются объекты с SQL — будем рады, если попробуете и выскажете своё мнение.
Нет, не легче. У меня в компании программисты нежно любят реляционную алгебру, и поэтому несколько пренебрежительно относятся к SQL, называя его калечным.
> А насчет type safety и прочих прелестей — идет работа над EF-интерфейсом к базе.
Отлично! :)
> Хотите посмотреть, как уживаются объекты с SQL — будем рады, если попробуете и выскажете своё мнение.
Работает ли оно под Mono?
> А насчет type safety и прочих прелестей — идет работа над EF-интерфейсом к базе.
Отлично! :)
> Хотите посмотреть, как уживаются объекты с SQL — будем рады, если попробуете и выскажете своё мнение.
Работает ли оно под Mono?
А как насчет HQL в этом плане — вам сильно не нравится? Близок к Sql, но объектный
Так HQL тоже основан на SQL, и наш «SQL» к нему ну очень близок.
Отличие Eloquera от Hibernate (кроме того, что первая — это база данных сама по себе, а вторая — маппер) в том, что Eloquera не генерирует классов на основе таблиц (и наоборот), а использует «натуральные» определения классов в C# (хотя язык неважен), без всяких искусственных добавоки красителей.
С приходом EF-интерфейса проблема строгой типизации будет решена, мне кажется. В принципе, ничего не мешает генерировать специфические классы доступа и сейчас — для строгой типизации. Но данный подход заставляет применять сгенерированный код, и перегенерировать его каждый раз при определенных изменениях.
Сейчас код генерируется, но это происходит на уровне MSIL и этого не видно. Но проблему строгой типизации при компилировании это не решает. Поэтому работаем над EF.
Отличие Eloquera от Hibernate (кроме того, что первая — это база данных сама по себе, а вторая — маппер) в том, что Eloquera не генерирует классов на основе таблиц (и наоборот), а использует «натуральные» определения классов в C# (хотя язык неважен), без всяких искусственных добавок
С приходом EF-интерфейса проблема строгой типизации будет решена, мне кажется. В принципе, ничего не мешает генерировать специфические классы доступа и сейчас — для строгой типизации. Но данный подход заставляет применять сгенерированный код, и перегенерировать его каждый раз при определенных изменениях.
Сейчас код генерируется, но это происходит на уровне MSIL и этого не видно. Но проблему строгой типизации при компилировании это не решает. Поэтому работаем над EF.
Очень любопытная вещь, как раз в данный момент что-то подобное понадобилось, уже смотрели в сторону db4o, но может быть и изменим свое решение :) Спасибо!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Объектная база данных Eloquera 2.0