Приветствую!
Знаю что тема звучит как избитая, но интенсивный гуглинг и просмотр флеймов на родственные темы результатов не дали, поэтому прошу совета.
Но к делу:
Есть приложение (кадры) со сложной структурой данных — у базовых объектов сотни (несколько сотен) реквизитов с историей изменений со многими уровнями вложенностями. В логике редактирования данных реквизитов реализуются различные проверки. Один из простых примеров:
Если Sum(Сотрудник.ИсполняемыеДолжности.ЗанимаемаяСтавка, по ШтатнойЕдинице) > ШтатнаяЕдиница.РазрешенныхСтавок то ругаемся "Число ставок по дложности такой=то превышает кол-во разрешенных". Как мы видим на таком описательном уровне выглядит все просто, но когда дело доходит до написания запросов к БД да еще и возможно с обработкой на стороне клиента, да еще с учетом истории изменения значений , все становится гораздо хуже — получаются сложные мнгостраничные конструкции (БД — MS SQL), трудемкость их написания достаточно высока (сужу по практике), да еще часто бывает изменяется логика проверок и выборок.
Что бы хотелось: некую надстройку над БД, в которой описывалась структура предметной области данных, связи между ними. И самое главное — какой-то язык и engine запросов, чтобы проще описывать подобные запросы к данным. Понятно что на хитрых выборка и гиганстских агрегациях данных это все в разы будет медленнее прямых запросов, но для этого такая надстройка и не будет испольоваться (будут использоваться прямые SQL запросы к БД). Специфика приложения — небольшие точечные выборки, но по сложной модели данных — и большое их кол-во и часто могут меняться. Всякие Cache , ObjectDB и т.п. объектные БД не подходят, тк в качестве хранилища используется РБД MSSQL и ее менять на "настоящие" объектные БД нет смысла.
Буду признателен за ссылки по теме и просто за дельные мысли, а также есть интерес в приобретении готовых решений или поучаствовать в подобных проектах (возможно и финансово)...
Здравствуйте, MadHuman, Вы писали:
MH> Если Sum(Сотрудник.ИсполняемыеДолжности.ЗанимаемаяСтавка, по ШтатнойЕдинице) > ШтатнаяЕдиница.РазрешенныхСтавок то ругаемся "Число ставок по дложности такой=то превышает кол-во разрешенных".
Бизнес-правило в чистом виде ...
MH>Что бы хотелось: некую надстройку над БД, в которой описывалась структура предметной области данных, связи между ними. И самое главное — какой-то язык и engine запросов, чтобы проще описывать подобные запросы к данным. Понятно что на хитрых выборка и гиганстских агрегациях данных это все в разы будет медленнее прямых запросов, но для этого такая надстройка и не будет испольоваться (будут использоваться прямые SQL запросы к БД). Специфика приложения — небольшие точечные выборки, но по сложной модели данных — и большое их кол-во и часто могут меняться. Всякие Cache , ObjectDB и т.п. объектные БД не подходят, тк в качестве хранилища используется РБД MSSQL и ее менять на "настоящие" объектные БД нет смысла.
Возможно, имеет смысл написать бизнес-логику на классах, а маппинг на БД сделать через подходящий для ваших средств разработки OPF (Object Persistent Framework) -- по этому словосочетанию можно и погуглить -- есть как коммерческие, так и бесплатные. Для Java например есть Hibernate -- it's for free.
MH>Буду признателен за ссылки по теме и просто за дельные мысли, а также есть интерес в приобретении готовых решений или поучаствовать в подобных проектах (возможно и финансово)...
Здравствуйте, byur, Вы писали:
B>Здравствуйте, MadHuman, Вы писали:
MH>> Если Sum(Сотрудник.ИсполняемыеДолжности.ЗанимаемаяСтавка, по ШтатнойЕдинице) > ШтатнаяЕдиница.РазрешенныхСтавок то ругаемся "Число ставок по дложности такой=то превышает кол-во разрешенных".
B>Бизнес-правило в чистом виде ...
Согласен, токо данные для него доставать трудоемко, особенно с учетом историчности хранения значений. не буду приводить пример как это у нас сделано, дабы не замораивать многостраничным малопонятным кодом...
MH>>Что бы хотелось: некую надстройку над БД, в которой описывалась структура предметной области данных, связи между ними. И самое главное — какой-то язык и engine запросов, чтобы проще описывать подобные запросы к данным. ........
B>Возможно, имеет смысл написать бизнес-логику на классах, а маппинг на БД сделать через подходящий для ваших средств разработки OPF (Object Persistent Framework) -- по этому словосочетанию можно и погуглить -- есть как коммерческие, так и бесплатные. Для Java например есть Hibernate -- it's for free.
Возможно в некоторых случаях, но уж очень хочется декларативно, т.е. запросами. На Hibernate к сожалению не подойдет, тк у на все в COM-технологии, хотя...
MH>>Буду признателен за ссылки по теме и просто за дельные мысли, а также есть интерес в приобретении готовых решений или поучаствовать в подобных проектах (возможно и финансово)...
B>Возможно вам подойдут и бесплатные
MH>Возможно в некоторых случаях, но уж очень хочется декларативно, т.е. запросами. На Hibernate к сожалению не подойдет, тк у на все в COM-технологии, хотя...
есть еще NHibernate, он C#-ный, и поэтому более дружественный к Windows-платформе.
DG>есть еще NHibernate, он C#-ный, и поэтому более дружественный к Windows-платформе.
Посмотрел подробнее на Hibernate (и на NHibernate), жаль что не в COM-технологии , а так очень интересно и близко к тому что бы хотелось, достаточно интересный OQL , позволяющий писать компактные запросы к сложным данным. Но все таки хотелось бы еще найти подобные системы для COM-технологии, так что поиск продолжаю...
Здравствуйте, MadHuman, Вы писали:
MH>Здравствуйте, DarkGray, Вы писали:
DG>>есть еще NHibernate, он C#-ный, и поэтому более дружественный к Windows-платформе.
MH>Посмотрел подробнее на Hibernate (и на NHibernate), жаль что не в COM-технологии , а так очень интересно и близко к тому что бы хотелось, достаточно интересный OQL , позволяющий писать компактные запросы к сложным данным. Но все таки хотелось бы еще найти подобные системы для COM-технологии, так что поиск продолжаю...
BZ>Можно еще посмотреть Eclipse JSR220-ORM (бесплатный, Java/JDO 2/EJB3) или VOA.NET Object Persistence (коммерческий продукт).
BZ>Кстати есть еще и список реализаций здесь.
BZ>Если есть вопросы — спрашивайте
Хм... нам очень важна встроенная поддержка работы с историей значений, т.к. практически каждый реквизит хранит историю изменений и работа с бизнес-объектом идет на дату, т.е. в зависимости от даты реквзиты могут менять значения. Что-то во всех просмотренных реализациях ничего об этом не увидел, может плохо смотрел? Кто сталкивался или слышал или знает, подскажите плиз в какой из систем O/R mapping реализована поддержка подобной фичи?
Здравствуйте, MadHuman, Вы писали:
MH>Хм... нам очень важна встроенная поддержка работы с историей значений, т.к. практически каждый реквизит хранит историю изменений и работа с бизнес-объектом идет на дату, т.е. в зависимости от даты реквзиты могут менять значения. Что-то во всех просмотренных реализациях ничего об этом не увидел, может плохо смотрел? Кто сталкивался или слышал или знает, подскажите плиз в какой из систем O/R mapping реализована поддержка подобной фичи?
Я не работал ни с одной реализацией ORM, в которой бы была встроенная версионность объектов (если я Вас правильно понял). Но это не значит что их нет.
Кроме этого, я считаю, что такие вопросы должны реализовываться на уровне бизнес-логики, а не ORM... В ООСУБД-ах есть версионность классов, а вот насчет версионности объектов — еще раз повторю, что это можно (и нужно) реализовывать самому.
Здравствуйте, MadHuman, Вы писали:
MH>Здравствуйте, BaZa, Вы писали:
BZ>>Можно еще посмотреть Eclipse JSR220-ORM (бесплатный, Java/JDO 2/EJB3) или VOA.NET Object Persistence (коммерческий продукт).
BZ>>Кстати есть еще и список реализаций здесь.
BZ>>Если есть вопросы — спрашивайте
MH>Хм... нам очень важна встроенная поддержка работы с историей значений, т.к. практически каждый реквизит хранит историю изменений и работа с бизнес-объектом идет на дату, т.е. в зависимости от даты реквзиты могут менять значения. Что-то во всех просмотренных реализациях ничего об этом не увидел, может плохо смотрел? Кто сталкивался или слышал или знает, подскажите плиз в какой из систем O/R mapping реализована поддержка подобной фичи?
MH>Спасибо...
Версионность конечно же надо делать на физ.уровне. Далее для объекта дабавить параметр даты типа:
Сотрудник.НайтиПоНомеру(Номер, Дата)
Следует отметить, что потребуется введение темпоральной логики для выбора атрибутов.
Еще хотел отметить, что возможно использовать коротко-живущие объекты.
Такие объекты живут только вовремя транзакции. Иногда это здорово упрощает реализацию.
А вообще можно было поучаствовать.
Здравствуйте, alex-chin, Вы писали:
AC>Версионность конечно же надо делать на физ.уровне. Далее для объекта дабавить параметр даты типа: AC>Сотрудник.НайтиПоНомеру(Номер, Дата)
Я тоже так считаю, так как основные проблемы (точнее — трудоемкость) вызвана именно хранением истории изменений свойств объектов и последующей работой с ней и именно это одно из "тяжелых" место которое хотелось бы облегчить и упростить работу (читай инкасулировать в объектной надстройке) .
AC>Еще хотел отметить, что возможно использовать коротко-живущие объекты. AC>Такие объекты живут только вовремя транзакции. Иногда это здорово упрощает реализацию. AC>А вообще можно было поучаствовать.
Если есть какие-то предложения то шлите на мыло (в профайле) .
Да кстати, так пока ничего и не нашел подходящего, так что изначальные предложения остаются в силе.
