Анатолий — неглупый дядька, очень начитанный. Но он никогда не создаст ничего нового, т.к. он чистый эрудит без творческого начала. Некоторого рода пустоцвет.
В свое время с ним общался достаточно, поэтому это не пустые слова.
> Поэтому решение с использованием объектно-ориентированных СУБД
> в качестве основы для хранения данных следует считать скорее
> очередным «велосипедом», нежели промышленным стандартом.
К примеру, одна из крупнейших систем хранения, обработки и анализа данных построена на объектной базе компании Versant. Название системы — Echelon.
Да и нашу базу тоже используют довольно широко — правда, имена клиентов публиковать не имеем права.
Доля объектных баз на общем рынке пока мала, но это сравнимо с ситуацией с электромобилями. Гибридный Prius вполне популярен, а Tesla — чистый электромобиль — пока довольно дорогА, но показывает, что электрический автомобиль — не такой уж «велосипед».
Шаг 1 реализуется версионностью. С классическим «но» — не все обновления могут быть осуществлены. Поэтому вопрос о полной непротиворечивости полностью решен быть не может.
В принципе, «ослаблять болты» может не получиться — требования первого шага мешают. Какие уровни промежуточной изоляции Вы бы рассмотрели для применения в своих приложениях?
У нас реализовано некоторое непустое :-) перечесение с HQL (хотя за особой строгостью мы не гнались). К примеру, у нас можно делать JOIN'ы по любым полям, а не только логически связанным. Ну, и поддержка массивов, на мой взгляд, у нас намного мощнее — можно искать по полям объектов в массиве, например.
Журнал транзакций (в виде внутреннего лога) у нас запланирован на версии «попозже» — народ не очень просит.
А вот насчет user-defined merger я бы хотел узнать побольше. Что именно Вы хотели бы видеть в этом случае?
P.S. Ацетон у Вас замечательный — я бы выписывал его многим программистам. :-)
Версионность, по крайней мере, в ближайшей версии, базируется на snapshot модели изоляции.
Возможно, наш подход несколько упрощен, но он использует простую идею: транзакция, начавшаяся в момент N, видит только то, что было в момент N (все N — уникальны, пусть это будет глобальный возрастающий счетчик). Взаимодействие транзакций между собой пока не предусмотрено.
Правда, журналирование мы еще не собираемся добавлять — это полезно для корпоративных баз, но вряд ли — для веб. А на грандов нам замахиваться немного рано. :-) Да и OLAP с объектами не вяжется немного. Но у нас есть кое-что в рукаве для похожих случаев, так что — сюрпризы будут. :-)
Так HQL тоже основан на SQL, и наш «SQL» к нему ну очень близок.
Отличие Eloquera от Hibernate (кроме того, что первая — это база данных сама по себе, а вторая — маппер) в том, что Eloquera не генерирует классов на основе таблиц (и наоборот), а использует «натуральные» определения классов в C# (хотя язык неважен), без всяких искусственных добавок и красителей.
С приходом EF-интерфейса проблема строгой типизации будет решена, мне кажется. В принципе, ничего не мешает генерировать специфические классы доступа и сейчас — для строгой типизации. Но данный подход заставляет применять сгенерированный код, и перегенерировать его каждый раз при определенных изменениях.
Сейчас код генерируется, но это происходит на уровне MSIL и этого не видно. Но проблему строгой типизации при компилировании это не решает. Поэтому работаем над EF.
Snapshot isolation иногда показывает чудеса медлительности для обновления одного поля в нескольких сотнях строк данных. Возможно, что это специфика софта и индустрии (данные с разведочных нефтяных скважин), но пришлось в MS SQL от нее отказаться, и решать вопрос редизайном некоторых частей в базе.
Я не ругаю MS SQL — она кормила меня ооочень долгое время. :-) И делала это вполне замечательно — у наших админов седых волос было немало, но все же не так, как у Ораклистов (или связь тут обратная? :-)) Но реляционно-объектное несоответствие никто не отменял, поэтому при хранении сложных объектов (включая сложные иерархии данных в XML) часто приходится искусствено вводить сущности, которых нет в объектах (например, для наследования).
«Исторические данные» с возможностью сложной аналитики или просто «чтобы было»? :-) Ну, IBM с Oracle тут не одну собаку съели, но ту самую еще, кажется, не нашли. :-)
В принципе, если предоставить своего арбитра транзакций (а это классы с определенными вполне интерфейсами), то можно делать свою стратегию управлениями транзакций. Обычно такие классы уже встроен в базу, но ничего не мешает делать его «съемным» и заменять по желанию программиста.
Другое дело, что написание такого класса — дело, требующего глубокого понимания устройства транзакционных баз.
А можно побольше о Ваших «фантазиях» по поводу транзакций? Если бы Вам дали возможность сформировать систему транзакций, что бы Вы отметили как самое важное и необходимое? И какие уровни безопасности Вы бы хотели видеть?
В принципе, EF внутри — это набор интерфейсов с обертками. Баги — это понятно, они неизбежны при попытках скрестить ежа и ужа — объекты и реляционные базы. В O/R mapper'ах встречаются и проблемы похуже.
В нашем случае таких трудностей нет, так что надеемся на качественный результат. :-)
Есть вариант использования Eloquera как локальную базу, но тогда теряется параллельность работы. Для этого достаточно указать в качестве сервера подключения имя (local). Как-то так:
DB db = new DB("server=(local);options=none;")
В таком случае, security отключается (точнее, не включается :-)).
В нынешней конфигурации база настроена на скорость работы с несколькими клиентами, поэтому использование памяти довольно велико (128MB-384MB в зависимости от размера базы — эти данные для сотен тысяч или миллионов объектов). Но настройки можно «подкручивать» в конфигурации.
Да, просто очень много народа на .NET сидит под SQL Server — а это блокирующая база. Работа с версиями в MS SQL Server — сплошные слезы, с переписыванием данных в tempdb, и обратной записью в базу.
Но внутри Eloquera работает на версионном принципе, просто это еще не вынесено на логический уровень. Сейчас разработка крутится вокруг этого.
Еще один голос за версионность! В принципе, разработка идет именно в этом направлении, но у «блокировщиков» в компании есть свои аргументы, которыми они вносят некоторую неуверенность в технически не очень подготовленные головы. :-) Да и SQL Server — по большей части блокирующая база, а это как бы эталон для .NET.
Насколько помню, в db4o нет контроля за изменениями структуры объектов. Т.е. было поле int, стало float — все будет работать, только в данных будет мусор. У нас при изменении структуры объектов выскакивает exception, мол, структура разная, класс не тот, что писали.
В данном случае, лучше всего подойдет наследование от старого класса — все запросы будут работать правильно, никаких особых изменений не нужно. Запросы к старому классу будут возвращать объекты и старого, и нового типа (если не использовать SELECT ONLY, конечно, который ограничивает выборку только определенным классом).
SQL — язык, который знает любой программист баз данных. Если у Вас компания, в которой работают люди, знающие SQL, то не легче ли перейти на новый продукт, экономящий время разработки, который Ваши работники уже знают? Отзывы от партнеров — положительные. :-)
А насчет type safety и прочих прелестей — идет работа над EF-интерфейсом к базе.
Хотите посмотреть, как уживаются объекты с SQL — будем рады, если попробуете и выскажете своё мнение.
Спасибо за комплимент, но я — вполне такой обычный программист. Причем — в меру забывчивый. Я-то забыл сказать, что это клиент-серверная база, и ориентирована на веб. На ту часть, которая использует .NET с mySQL и прочими базами без long-running transactions — как оказалось, это вполне широкая аудитория (правда, в США и в Европе — по России и Украине картина очень отличается). И транзакции в данном сегменте «приобретают особый смысл» (ц).
Фактически нас просили об атомарности и изоляции для отдельных операций типа вставки, обновления и удаления (это есть). Так же соблюдается консистентность для этих операций. Консистентность при запросах еще не готова для коммерческого релиза — но, как ни странно, это не останавливает от использования подобных баз в веб.
Сейчас база работает на блокировках. Кстати, Вы — сторонник версионных или блокирующих баз? :-)
В свое время с ним общался достаточно, поэтому это не пустые слова.
> Поэтому решение с использованием объектно-ориентированных СУБД
> в качестве основы для хранения данных следует считать скорее
> очередным «велосипедом», нежели промышленным стандартом.
К примеру, одна из крупнейших систем хранения, обработки и анализа данных построена на объектной базе компании Versant. Название системы — Echelon.
Да и нашу базу тоже используют довольно широко — правда, имена клиентов публиковать не имеем права.
Доля объектных баз на общем рынке пока мала, но это сравнимо с ситуацией с электромобилями. Гибридный Prius вполне популярен, а Tesla — чистый электромобиль — пока довольно дорогА, но показывает, что электрический автомобиль — не такой уж «велосипед».
Шаг 1 реализуется версионностью. С классическим «но» — не все обновления могут быть осуществлены. Поэтому вопрос о полной непротиворечивости полностью решен быть не может.
В принципе, «ослаблять болты» может не получиться — требования первого шага мешают. Какие уровни промежуточной изоляции Вы бы рассмотрели для применения в своих приложениях?
У нас реализовано некоторое непустое :-) перечесение с HQL (хотя за особой строгостью мы не гнались). К примеру, у нас можно делать JOIN'ы по любым полям, а не только логически связанным. Ну, и поддержка массивов, на мой взгляд, у нас намного мощнее — можно искать по полям объектов в массиве, например.
Журнал транзакций (в виде внутреннего лога) у нас запланирован на версии «попозже» — народ не очень просит.
А вот насчет user-defined merger я бы хотел узнать побольше. Что именно Вы хотели бы видеть в этом случае?
P.S. Ацетон у Вас замечательный — я бы выписывал его многим программистам. :-)
Возможно, наш подход несколько упрощен, но он использует простую идею: транзакция, начавшаяся в момент N, видит только то, что было в момент N (все N — уникальны, пусть это будет глобальный возрастающий счетчик). Взаимодействие транзакций между собой пока не предусмотрено.
Правда, журналирование мы еще не собираемся добавлять — это полезно для корпоративных баз, но вряд ли — для веб. А на грандов нам замахиваться немного рано. :-) Да и OLAP с объектами не вяжется немного. Но у нас есть кое-что в рукаве для похожих случаев, так что — сюрпризы будут. :-)
Отличие Eloquera от Hibernate (кроме того, что первая — это база данных сама по себе, а вторая — маппер) в том, что Eloquera не генерирует классов на основе таблиц (и наоборот), а использует «натуральные» определения классов в C# (хотя язык неважен), без всяких искусственных добавок
и красителей.С приходом EF-интерфейса проблема строгой типизации будет решена, мне кажется. В принципе, ничего не мешает генерировать специфические классы доступа и сейчас — для строгой типизации. Но данный подход заставляет применять сгенерированный код, и перегенерировать его каждый раз при определенных изменениях.
Сейчас код генерируется, но это происходит на уровне MSIL и этого не видно. Но проблему строгой типизации при компилировании это не решает. Поэтому работаем над EF.
Я не ругаю MS SQL — она кормила меня ооочень долгое время. :-) И делала это вполне замечательно — у наших админов седых волос было немало, но все же не так, как у Ораклистов (или связь тут обратная? :-)) Но реляционно-объектное несоответствие никто не отменял, поэтому при хранении сложных объектов (включая сложные иерархии данных в XML) часто приходится искусствено вводить сущности, которых нет в объектах (например, для наследования).
«Исторические данные» с возможностью сложной аналитики или просто «чтобы было»? :-) Ну, IBM с Oracle тут не одну собаку съели, но ту самую еще, кажется, не нашли. :-)
Другое дело, что написание такого класса — дело, требующего глубокого понимания устройства транзакционных баз.
А можно побольше о Ваших «фантазиях» по поводу транзакций? Если бы Вам дали возможность сформировать систему транзакций, что бы Вы отметили как самое важное и необходимое? И какие уровни безопасности Вы бы хотели видеть?
В нашем случае таких трудностей нет, так что надеемся на качественный результат. :-)
DB db = new DB("server=(local);options=none;")
В таком случае, security отключается (точнее, не включается :-)).
В нынешней конфигурации база настроена на скорость работы с несколькими клиентами, поэтому использование памяти довольно велико (128MB-384MB в зависимости от размера базы — эти данные для сотен тысяч или миллионов объектов). Но настройки можно «подкручивать» в конфигурации.
Под Mono наша база не работает, т.к. Mono еще не реализовала весь стандарт C#/MSIL полностью.
Но внутри Eloquera работает на версионном принципе, просто это еще не вынесено на логический уровень. Сейчас разработка крутится вокруг этого.
В данном случае, лучше всего подойдет наследование от старого класса — все запросы будут работать правильно, никаких особых изменений не нужно. Запросы к старому классу будут возвращать объекты и старого, и нового типа (если не использовать SELECT ONLY, конечно, который ограничивает выборку только определенным классом).
А насчет type safety и прочих прелестей — идет работа над EF-интерфейсом к базе.
Хотите посмотреть, как уживаются объекты с SQL — будем рады, если попробуете и выскажете своё мнение.
Фактически нас просили об атомарности и изоляции для отдельных операций типа вставки, обновления и удаления (это есть). Так же соблюдается консистентность для этих операций. Консистентность при запросах еще не готова для коммерческого релиза — но, как ни странно, это не останавливает от использования подобных баз в веб.
Сейчас база работает на блокировках. Кстати, Вы — сторонник версионных или блокирующих баз? :-)