Engine-independent DB Application - мосты и окна

← →
Igorek © (2004-06-29 12:35) [0]

Меняем БД движок в нашей программе. Возникла идея реализовать БД приложение, независящее от БД движка. Базы пока только реляционные. Приложение не меняет данные в базе.

В итоге рожаю счас такое дизайнерское решение:
Вводятся концепции "моста" и "окна".
Мост - класс, наследник некоего абстрактного моста. Приложение имеет доступ к базе только через этот мост. Конкретный мост реализует интерфейс к конкретному движку. Если напр. движок реализует SQL запросы, то данный мост перекрывает св-во SupportsSQL из базового и возвр. True. То же с фильтрами.
Окно - это класс. Каждая форма, работающая с БД обращается к мосту и открывает для себя окно. Через это окно форма затребует наборы данных, которые ей нужны (слепок таблицы (полный или отфильтрованный), запросы из нескольких таблиц и т.д.). Наборы данных подключаются к контролам их отображения - ДБ гридам и т.п.

Надо поменять движок - юзаем другой класс моста.

За счет того, что у каждой формы будут независимые наборы данных, изменение позиции БД курсора в одной форме никак не повлияет на остальные.
Имхо такое решение лучше чем городить все в одну кучу в DataModule или делать DataModule отдельно для каждой формы.
Есть неудобство в том, что пока что все надо подключать в RunTime. Соотв. в DesignTime нельзя вживую подключиться и посмотреть корректность отображения (соответствие столбцов, результат запроса и т.д.). Но если решение себя хорошо зарекоммендует - сделаем набор компонент.

Пока еще все туманно, так что жду комментариев.

Что скажете? Какие плюсы и минусы?

← →
Соловьев © (2004-06-29 12:36) [1]

про МИДАС читал?

← →
DiamondShark © (2004-06-29 12:38) [2]

> про МИДАС читал?

Чача.

← →
Igorek © (2004-06-29 12:40) [3]

> Соловьев © (29.06.04 12:36) [1]
> про МИДАС читал?

Ты за минуту прочитал и вник в мой пост? :-)))

Юзал и читал когда-то немного. А что МИДАС все это реализует?

← →
Igorek © (2004-06-29 12:41) [4]

> DiamondShark © (29.06.04 12:38) [2]
>
> > про МИДАС читал?
>
> Чача.

Что это такое???

← →
iZEN © (2004-06-29 12:50) [5]

to Igorek © (29.06.04 12:35)
Осталось реализовать независимый DataSet. Желательно отсоединяемый и в формате XML.

← →
Igorek © (2004-06-29 13:12) [6]

> iZEN © (29.06.04 12:50) [5]
> to Igorek © (29.06.04 12:35)
> Осталось реализовать независимый DataSet. Желательно отсоединяемый
> и в формате XML.

Что значит независимый? Я напр. думаю взять стандартный TDataSet. Ведь это все делается под Дельфи и в Дельфи будет юзаться (пока Борланд не перекроит VCL).

И что значит "отсоединяемый и в формате XML"? Поподробнее можно? И заодно ответ на вопрос "Зачем"?

← →
iZEN © (2004-06-29 13:18) [7]

/**Igorek © (29.06.04 13:12) [6]
Что значит независимый? Я напр. думаю взять стандартный TDataSet. Ведь это все делается под Дельфи и в Дельфи будет юзаться (пока Борланд не перекроит VCL).

И что значит "отсоединяемый и в формате XML"? Поподробнее можно? И заодно ответ на вопрос "Зачем"?
*/
Вроде последний MIDAS и ADO всё это нормально реализуют, так что извращаться не нужно.

А "отсоединяемый" - это значит его можно записать на диск, отсоединиться от базы, поработать с ним offline, подсоединиться к базе и произвести синхронизацию изменённых данных - классическая BriefCase-модель. Также возможны решения в виде переноса БД в другую СУБД или архивирование данных вне СУБД.

← →
Соловьев © (2004-06-29 13:24) [8]

http://distribucon.com/midas.html

← →
Соловьев © (2004-06-29 13:25) [9]

http://www.osp.ru/pcworld/2000/01/144_print.htm

← →
Соловьев © (2004-06-29 13:26) [10]

http://olegmotov.h1.ru/articles/inprisemidas/toc.htm

← →
Igorek © (2004-06-29 16:12) [11]

> Вроде последний MIDAS и ADO всё это нормально реализуют,
> так что извращаться не нужно.

MIDAS, ADO ... и другие страшные слова - это конечно круто.
Но надо учесть, что не во все версии Дельфи они входят. Вроде только в Enterprise (или Architect) - короче в самые полные (а значит самые дорогие).
А тут идея как раз в том, что-бы написать прослойку, какая позволить юзать любые движки (в том числе и фриварные). Естественно только те, что дают наборы данных в виде наследников от TDataSet. Конечно DB.pas (в нем размещен TDataSet) тоже не входит в минимальный набор Дельфи, но это лучше чем ничего. В идеале действительно хорошо бы и свой DataSet сделать.

Я вот пока пишу мост под ADO (хотя это на самом деле не движок, а прослойка, но сути не меняет). Придется - напишу под что-то другое. Но не придется лазить по юнитам и формам и менять все потроха приложения.

Повторю: это все в контексте того, что БД-приложение есть read-only.

> Соловьев © (29.06.04 13:24) [8-10]

Спасибо конечно, но достаточно было и [1]. В сети про МИДАС инфы навалом.

Так будет еще что-то по сабжу? Сама идея как?

← →
Igorek © (2004-06-29 16:13) [12]

Может это в "Базы" надо было запостить?

← →
Игорь Шевченко © (2004-06-29 16:15) [13]

Сложно как-то

← →
Vlad © (2004-06-29 16:21) [14]

Можно было просто интерфейс какойнить написать, и несколько COM(DCOM)-объектов реализующих по своему этот интерфейс.
Т.е. для каждого типа СУБД - свой.

← →
Igorek © (2004-06-29 16:24) [15]

> Игорь Шевченко © (29.06.04 16:15) [13]
> Сложно как-то

Нету ничего сложного. Может я просто невнятно пояснил.
На данный момент уже большая часть реализована - модуль с мостами, окном, вспомогательным классом для конструирования SQL запросов - до 200 строк. Обещает быть максимум до полтыщи строк.

← →
Igorek © (2004-06-29 16:26) [16]

> Vlad © (29.06.04 16:21) [14]
> Можно было просто интерфейс какойнить написать, и несколько
> COM(DCOM)-объектов реализующих по своему этот интерфейс.
> Т.е. для каждого типа СУБД - свой.

Да это аналог. В принципе даже лучше - COM обьект юзай потом где хочешь. Может так потом и сделаем.

← →
Игорь Шевченко © (2004-06-29 16:26) [17]

Igorek © (29.06.04 16:24)

> Обещает быть максимум до полтыщи строк.

А насколько возрастет объем кода предметной области ?

← →
DiamondShark © (2004-06-29 16:47) [18]

> iZEN © (29.06.04 12:50) [5]
> to Igorek © (29.06.04 12:35)
> Осталось реализовать независимый DataSet. Желательно отсоединяемый
> и в формате XML.

ADO?

← →
Polevi © (2004-06-29 16:48) [19]

>Возникла идея реализовать БД приложение, независящее от БД движка
а нафига ?

← →
Igorek © (2004-06-29 18:39) [20]

> Игорь Шевченко © (29.06.04 16:26) [17]
> А насколько возрастет объем кода предметной области ?

По правде сказать немного возрастет. Ведь надо динамически наборы данных создавать, линковать к контролам через DataSource, фильтры вручную выставлять. Но ненамного больше работы. А выгода в том, что раз написал и забыл.

> Polevi © (29.06.04 16:48) [19]
> >Возникла идея реализовать БД приложение, независящее от
> БД движка
> а нафига ?

В наших суровых реалиях бывает так, что надо то бесплатный движок помедленнее, то шустрый, но платный. Т.е. приложение уже написано и поступило распоряжение поменять движок. И кто знает, может такое повторится в будущем.

← →
Ihor Osov'yak © (2004-06-29 19:13) [21]

>Возникла идея реализовать БД приложение, независящее от
> БД движка

Видел уже многих, которые с такой идеей маялись. Оканчивалось в лучшем случае никак, в худшем - плачевно. Конечно, не рассматриваем проект из трех табличех и с логикой на стороне клиента.

Зы. Говорят люди, что на одних движках есть вложенные транзакции, на других нету, на одних и before триггера и after, на других только after, а на третьих даже такого нету. И так далее, и тому подобное.

Зы2. Посмотри вокруг Interbase и клонов - есть начиная от персональной и однопользовательской, кончая полновесными промышленными. Причем и в фришных вариантах, и не в фришных. Причем процесс перехода с одной версии на другую уж прост до неприличия. Конечно, масштаб какого-то ГАЗ может и не по зубам, но для большинства задач хватает с головой.

← →
Ihor Osov'yak © (2004-06-29 19:17) [22]

> Приложение не меняет данные в базе.

Да, кажется той же firebird можно настроить на работу с базой на RO носителе. Это так, между прочим.

← →
vuk © (2004-06-29 19:19) [23]

Если приучить себя делать логику на хранимых процедурах, то никаких проблем с построением переносибельной архитектуры не видно. Так что вот... :o)

← →
Vlad © (2004-06-29 19:22) [24]

> vuk © (29.06.04 19:19) [23]

Это что, шутка ? Язык ХП везде разный, а в файл-серверных БД их вобще нету
ИМХО, тогда уж надо трехзвенку делать, и логику выносить на сервер приложений.

← →
Ihor Osov'yak © (2004-06-29 19:32) [25]

если чесно - я никак не понимаю необходимости обеспечения переносимости на уровне движка базы даных.
Приходилось несколько раз видеть "переносимые" решения, где на клиент-серверной платформе работают по идеологии файл-серверной платформы. Гоняя таблички на клиентов так, что сеть не выдерживает.

← →
vuk © (2004-06-29 19:33) [26]

to Vlad © (29.06.04 19:22) [24]:
>Это что, шутка ?
Нет, это не шутка. Просто имеется практически полная аналогия. Нужно построить систему так, что внутри нее не будет никакого SQL. Вместо этого будут вызовы процедур. Вызовы серверных процедур легко заменить на вызовы процедур движка, а конкретную реализацию переложить на версию движка, заточенную под определенную БД. А что и как там у себя внутри движок будет вызывать - это его внутреннее дело.

>ИМХО, тогда уж надо трехзвенку делать, и логику выносить на
>сервер приложений.
По сути получается та же трехзвенка, но со вторым звеном, находящимся в движке. Другое дело, что городить настоящую трехзвенку не всегда имеет смысл. В большинстве случаев можно обойтись обычной двухзвенкой.

← →
Ihor Osov'yak © (2004-06-29 19:34) [27]

имхо, в приложениях баз данных - выбор движка еще более фундаментально и первично, чем выбор операционной системы.

← →
vuk © (2004-06-29 19:42) [28]

to Ihor Osov"yak © (29.06.04 19:34) [27]:
В принципе да, но если делать адаптацию приложения под конкретного заказчика, у которого уже имеется какой-то определенный сервер, то вся эта канитель с промежуточным слоем может быть необходима.

> Ihor Osov"yak © (29.06.04 19:34) [27]

Ну не всегда можно однозначно выбрать движок.
Вот к примеру, написал ты какую-то супер-пупер настраиваемую систему складского или бухгалтерского учета. Теперь стоит задача - впарить её клиентам. Клиентов много, и не каждый может себе позволить содержать к примеру Оракл, некоторые просто из своих каких-то соображений предпочитают Access и т.д.
Тут хочешь не хочешь, а придется подстраиваться под ту БД, которую тебе закажут, тогда и система твоя будет продаваться хорошо.
Многие фирмы гонятся за подобными универсальными решениями. Правда не знаю примеров успешной их реализации :-)

я работаю с базой MS SQL Server исключительно посредством вызова SP
причем каждая SP имеет лишь один параметр типа @Xml NTEXT - xml запрос
и возвращает SP всегда xml ответ (исползуя for xml explicit или просто select "<?xml version="1.0" ?><root>...</root>"
никаких триггеров
таким образом при необходимости перехода на другую БД эти процедуры просто переносятся на среднее звено

2 [26] vuk © (29.06.04 19:33)

ну, я бы не совсем согласился. Даже в вызовах процедур есть определенные ньюансы. Во вторых, при подходе - "работаем через процедуры" - есть тот минус, что остается возможность прямой работы с таблицами (я понимаю, что есть варианты на уровне нарезания прав - но это значительно усложняет систему, да и снова вопрос переносимости). С внесением некторой путаницы в непротиворичивость базы. Ибо не всегда можно спроектировать базу так, что непротиворечивость будет достигаться только одними связями. И тогда уж очень выручают триггера. Да и бизнес логику триггерами порою удобнее делать, чем процедурами. А вот с переносом тригерров в на сервер приложений уже могуть возникнуть проблемы. А сами тригерра уж больно платформозависимые.

Зы. Для мало-мальски серьезного проекта при рассмотрении возможности обеспечить переносимость на 2-3 движка возникает уж больно много вопросов. Количество которых либо вынуждает отказаться от идеи переносимости, либо отказаться он самых вкусностей конкретных движков. Во втором случае может возникнуть вопрос - а на кокой ляд такая переносимость?

2 [29] Vlad © (29.06.04 19:48)

> Правда не знаю примеров успешной их реализации :-)

Я о том же. Имел возможность наблюдать развитие однного шибко масштабируемого решения, которое должно було работать и на access, и на MSSQL и на Oracle :-).

> Клиентов много, и не каждый может себе позволить содержать к примеру Оракл,

ну немного для иныго масштаба задач оракл, чем для складского учета средней фирмы. Да и денег Оракл стоит. Кстати, и асссеss тоже. То бишь сотв. версия офиса. И это при том, что можно успешно использовать полноценный сервер промышленного класса, и в том числе легально фри, если в деньгах вопрос. И очень нетреботельный к администрированию. Так что решайте сами, использовать платный десктопный движок класса аксесса либо работать с полноценным сервером. Я имею ввиду клоны Interbase.
А задач, где Оракл с его мощью действительно нужен - не так уж много.

← →
Sergey Masloff (2004-06-29 20:17) [33]

Я хотел свои 5 копеек вставить но
---------------
Ihor Osov"yak © (29.06.04 19:32) [25]
и чуть раньше вполне изложил мою точку зрения.

> Ihor Osov"yak © (29.06.04 20:04) [32]

> А задач, где Оракл с его мощью действительно нужен - не
> так уж много.

Согласен. Я даже слышал о том что существуют серьезные биллинговые системы написанные под IB, размер базы что-то около 300 гб, при этом разработчики вроде говорили о достаточно неплохой производительности системы.
Но Оракл всё таки есть Оракл. Многие конторы, которым бы Акцесса хватило за глаза, считают своим долгом ставить именно Оракл (круто типа), и о других СУБД и думать не хотят. В итоге в инете часто видим такие объявления: требуется администратор Оракла, з/п 500 у.е. :-)))

to Ihor Osov"yak © (29.06.04 19:51) [31]:
>Во вторых, при подходе - "работаем через процедуры" - есть тот
>минус, что остается возможность прямой работы с таблицами (я
>понимаю, что есть варианты на уровне нарезания прав - но это
>значительно усложняет систему,
У нас система построена как раз по такому принципу - доступа к таблицам пользователи не имеют. Совсем. Возможности от этого не уменьшаются, а возрастают. В частности, реализована своя подсистема безопасности с построчными разрешениями для высокоуровневых операций.

>да и снова вопрос переносимости). С внесением некторой путаницы
>в непротиворичивость базы.
Вот этого не понял.

>Ибо не всегда можно спроектировать базу так, что
>непротиворечивость будет достигаться только одними связями.
>И тогда уж очень выручают триггера. Да и бизнес логику
>триггерами порою удобнее делать, чем процедурами. А вот с
>переносом тригерров в на сервер приложений уже могуть
>возникнуть проблемы. А сами тригерра уж больно
>платформозависимые.
Я не вижу проблемы. То есть совсем. Если клиент оперирует только вызовами процедур, которые выполняют высокоуровневые операции, то ему нет никакой разницы, как это реализовано внутри - ссылочной целостностью, триггерами или еще как. У нас по ходу разработки иногда менялась внутренняя реализация некоторых вещей. Так клиенту на это глубоко начхать - процедурный интерфейс к данным от этого никак не изменился.

2 [33] Sergey Masloff (29.06.04 20:17)

я польщен :-). И немного в развитие этой мысли (не о лести, а
о [30] Polevi © (29.06.04 19:50)) - то таки точно не могу понять, зачем с MS спрыгивать, если уже там оказались.. Ну, разве если Ваш постинг только в плане теоритической возможности - то тогда понятно :-).

> Ihor Osov"yak © (29.06.04 20:31) [36]

> зачем с MS спрыгивать, если уже там оказались

Я конечно стопроцентно не могу утверждать, но что-то я не слышал о компонентах прямого доступа к майкрософтовским базам. Это большой минус.
В IB или Oracle они есть, и это значительно упрощает задачу распространения продукта, да и разработки.
Так что вот навскидку одна причина чтобы уйти от MS

← →
Sergey Masloff (2004-06-29 20:46) [38]

Vlad © (29.06.04 20:42) [37]
Да там компоненты и не нужны. Таким компонентом является ADO и, в еще большей степени, ADO.NET которое работает непосредственно с энджайном MSSQL

2 [35] vuk © (29.06.04 20:25)

> Вот этого не понял.

Неудачно у меня построено предложение. Я имел ввиду случай, что непротиречивость может быть нарушена при работе в обход процедур и в случае отказа от триггеров (не все можно обеспечить ключами, да и не всегда целесообразно). Но раз у Вас все же решение на основании нарезания прав - тогде понятно, вопросов нет. Мы, вероятнее всего работаем с разного класса системами - я с более мелковестными, Вы с более крупными .

> Sergey Masloff (29.06.04 20:46) [38]

> Да там компоненты и не нужны. Таким компонентом является
> ADO

Ну как это не нужны ? Разве не лучше когда прямой доступ (ну или хотябы через библиотеки клиента), а ADO пока там эти данные через свои OLE объекты перекачает, это ж какая потеря скорости.

Engine-independent DB Application - мосты и окна Найти похожие ветки