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]:
В принципе да, но если делать адаптацию приложения под конкретного заказчика, у которого уже имеется какой-то определенный сервер, то вся эта канитель с промежуточным слоем может быть необходима.

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

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

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

← →
Polevi © (2004-06-29 19:50) [30]

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

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

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

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

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

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

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]
и чуть раньше вполне изложил мою точку зрения.

← →
Vlad © (2004-06-29 20:24) [34]

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

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

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

← →
vuk © (2004-06-29 20:25) [35]

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

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

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

← →
Ihor Osov'yak © (2004-06-29 20:31) [36]

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

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

← →
Vlad © (2004-06-29 20:42) [37]

> 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

← →
Ihor Osov'yak © (2004-06-29 20:51) [39]

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

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

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

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

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

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

К стати при реализации среднего зверна можно на него возложить задачу синхронизации баз данных между удаленными серверами.

Ihor Osov"yak © (29.06.04 20:04)

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

Вот мы, например, используем Oracle по нескольким причинам. Во-первых, мы с ним начали работать 10 лет назад, когда серьезной альтернативы ему, все-таки, не было по всем его возможностям. У нас был выбор - либо Sybase либо Oracle, выбор решился в пользу Oracle из-за его масштабируемости. Во-вторых, у Oracle очень сильно, по сравнению с Interbase, развит язык процедур и триггеров (про MSSQL ничего не скажу, я его совсем не знаю), В-третьих, сервер Oracle все-таки попроизводительней будет на зубодробительных запросах, а их есть у нас. В четвертых, объем обрабатываемых данных, все-таки, не маленький, и масштабируемость Oracle очень удачно вписывается в эту обработку. И в пятых, на данный момент у нас довольно большая часть бизнес-логики написана именно на PL/SQL и я не представляю, чтобы ее можно было безболезненно и в относительно разумные сроки перенести на какую-либо платформу сервера баз данных.

С уважением,

Vlad © (29.06.04 20:54) [40]

Я надеюсь, Вы понимаете, что выбор, скажем, 100000 строк вовсе не означает создания движком ADO 100000 COM-объектов? И откуда такое отношение к COM/OLE? Работа через COM подразумевает всего-навсего более частый вызов виртуальных методов, каковые используются в ООП сплошь и рядом, и даже, представьте, в VCL.

2 [42] Игорь Шевченко © (29.06.04 22:33)

У Вас, все же, как я представляю, задачи под стать Ораклу. Я же имел в виду случаи, когда ставят ворованный Оракл, совершенно не думая, сколько потом обойдется легализация, в сколько обойдется администрирование.. А задачу в конечном итоге решают такову и такими методами, что толку от этого Оракла..

> Oracle очень сильно, по сравнению с Interbase
Это все же вещи с разных весовых категорий. Это как бы шустренького ЗИЛа с БЕЛАЗом сравнить.

относительно масштабируемости. Да, в IБ это одно из относительно слабых мест, кажется, в седьмой версии есть некоторые улучшения в этом направлении, но конкреино сказать не могу, я сейчас активно базами не занимаюсь, так, поддерживаю на ходу 2 проекта примерно 4-летней давности..

> развит язык процедур
Смотрел немного, действительно мощь.. И они будут после этого еще говорить о многоплатформенности с точки зрения движка :-). На MSSQL делал один маленький проект, после ИБ немного непрывычно было, но я бы не сказал, что там намного мощнее с точки зрения процедур, тригерров (вопросы той-же масштабируемости не запрагиваем). Есть также вещи, которые на ИБ заметно удобнее делаются, но может это костность мышления, все же мозги в сторону ИБ закручены. Вообще-то ожидал более сильного впечатления.. Может не разобрался, все таки с ИБ работал года четыре, с MSSQL от силы месяца два.

to Ihor Osov"yak © (30.06.04 01:56) [44]:
>И они будут после этого еще говорить о многоплатформенности с
>точки зрения движка
Игорь, речь не о переносимости серверного процедурного кода. Никто этого и не говорил. Речь о том, что если есть привычка к работе с только процедурами, легко придумать схему переносимого промежуточного слоя (ПС). Со стороны клиента это будут вызовы процедур ПС (не в смысле БД, а в смысле языка, на котором написан клиент), а уже сам этот ПС будет работать с БД. Как он это будет делать - уже не важно.

>На MSSQL делал один маленький проект, после ИБ немного
>непрывычно было, но я бы не сказал, что там намного мощнее с
>точки зрения процедур
Единственное отличие, в MSSQL нельзя делать select из результата процедуры. А так, разницы не очень много.

>тригерров
Вот здесь согласен, с триггерами в IB несколько проще.

>Есть также вещи, которые на ИБ заметно удобнее делаются
Многие вещи, связанные с манипуляцией данными в MSSQL делаются проще, чем в IB т.к. сам язык запросов помощнее будет.

to vuk © (30.06.04 11:50) [45].
Вы, вот, всё упираете на хранимые процедуры, каждый раз переписывая их на сервере под конкретную СУБД.
Что ж, это один из выходов в переноси большей части логики на сервер БД, да и из других языков достучаться более реально, нежели через сервер приложений (написанный, скажем, на Delphi/ADO).
Но в то же время теряется всякий смысл использования продвинутой логики в клиентском приложении (зачем? всё же определено на сервере, И на ДРУГОМ языке - SQL).
Таким образом, слой СУБД превращается в СЕРВЕР ПРИЛОЖЕНИЙ, который программируется хранимыми процедурами. Плохо это или хорошо - вопрос не в этом (в зависимости от целей).
Но почему-то в других парадигмах полностью отказываются от сервера приложений в СУБД, заменяя универсальным промежуточным слоем, который работает лиш с тупыми плоскими таблицами без триггеров и хранимых процедур (очень простая схема БД) - всё это (целостность данных, внесение данных, предварительный обсчёт, выдачу данных) он обеспечивает сам. При этом клиент ВООБЩЕ не знает, что он работает с СУБД - сервер приложений закрывает всю видимость таблиц от клиента. Получается такая вот информационная система с чётко определённым набором видимых для клиента методов: клиент физически не может послать произвольный SQL-запрос, а в Вашем случае - может, если забыли "запретить".

Лучше РАЗРЕШАТЬ чем ЗАПРЕЩАТЬ. Иначе Вы моделируете ненадёжную систему безопасности Windows.

to iZEN © (30.06.04 18:27) [46]:
>Вы, вот, всё упираете на хранимые процедуры
Я говорю не столько про хранимые процедуры, сколько про процедурный интерфейс к данным. Разница есть.

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

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

Вот при очень простой схеме БД это еще может и прокатит. Но на деле сложность БД зависит не от желания разработчиков, а от представления предметной области. А вынесение проверок целостности с сервера - вообще неразумный шаг. Зачем, если сервер это сделает проще и эффективнее?

>а в Вашем случае - может, если забыли "запретить".
Кто сказал? Наоборот. Не может, пока не разрешили.

>Иначе Вы моделируете ненадёжную систему безопасности Windows.
Что-то у Вас странное какое-то представление о системе безопасности Windows...

/**vuk © (30.06.04 18:57) [47]:
Вот при очень простой схеме БД это еще может и прокатит. Но на деле сложность БД зависит не от желания разработчиков, а от представления предметной области. А вынесение проверок целостности с сервера - вообще неразумный шаг. Зачем, если сервер это сделает проще и эффективнее?
*/
Вот именно. Предметная область часто плохо "ложится" в реляционную схему, иногда даже невозможно её смоделировать на языке SQL, поэтому появляются примочки к СУБД в виде стороннего кода в DLL.

А почему бы тогда вообще не отказаться какого-либо кода в сервере СУБД, а перенести ВСЮ логику на сервер приложений, где можно использовать полную мощь ООП-языка программирования, а не "костыли" в виде "примочек" и заплаток проблемной области.
В этом случае в СУБД хранятся только плоские таблицы и больше ничего. СУБД обеспечивает только быстрый поиск записей, соединения и т.д. и выдачу запрошенного набора данных серверу приложений, а тот сам пусть разбирается, моделирует, устанавливает связи. Это же эффективнее (программирование на языке высокого уровня более приближено к предметной области, чем SQL), не так ли?

/**
>а в Вашем случае - может, если забыли "запретить".
Кто сказал? Наоборот. Не может, пока не разрешили.
*/
Тогда прошу прощения.

/**
>Иначе Вы моделируете ненадёжную систему безопасности Windows.
Что-то у Вас странное какое-то представление о системе безопасности Windows...
*/
Простите, но в Windows многое разрешено с момента установки, приходится закрывать очевидные вещи, вместо того, чтобы открывать когда это понадобится РЕАЛЬНО. В последних версиях одумались немножко.

Можно юзать dbExpress + Отказаться от наворотов на серверной части.

Драйвера для dbExpress есть почти, для любой БД, а каких нет можно самим написать, это и есть та прослойка которая не зависит от СУБД

to iZEN © (30.06.04 19:10) [48]:
>Предметная область часто плохо "ложится" в реляционную схему,
>иногда даже невозможно её смоделировать на языке SQL, поэтому
>появляются примочки к СУБД в виде стороннего кода в DLL.
Проблемы стоит решать по мере поступления. Когда будет эта невозможность - бум думать. А пока все что-то замечательно раскладывается в реляционные данные.

>СУБД обеспечивает только быстрый поиск записей, соединения и
>т.д. и выдачу запрошенного набора данных серверу приложений, а
>тот сам пусть разбирается, моделирует, устанавливает связи.
Красиво конечно, но эффективность именно работы с данными падает. Я уже неоднократно говорил, что вообще не вижу смысла из любви к искусству городить сервера приложений там, где можно обойтись двузвенкой.

>Это же эффективнее (программирование на языке высокого уровня
>более приближено к предметной области, чем SQL), не так ли?
Эффективнее не это, а использование для каждой задачи адекватных средств. SQL код в процедурах боле близок к данным, которыми он манипулирует и поэтому более эффективен.

Всем большое спасибо за участие в обсуждении.

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

> Ломброзо © (30.06.04 01:16) [43]

> выбор, скажем, 100000 строк вовсе не означает создания движком
> ADO 100000 COM-объектов?

Ну совсем за дурака-то меня не надо считать. Есть конечно чуть чуть, но не на столько же :-)

> Работа через COM подразумевает всего-навсего более частый
> вызов виртуальных методов, каковые используются в ООП сплошь
> и рядом, и даже, представьте, в VCL.

А вот представьте, мне весьма часто приходится сравнивать скорость работы ADO и компонент прямого доступа. И знаете, ADO намного(!) проигрывает. С чем это связано ? Предполагаю, именно с COM. Хотя, возможно ошибаюсь. Но факт остается фактом.

> Простите, но в Windows многое разрешено с момента установки,
> приходится закрывать очевидные вещи, вместо того, чтобы
> открывать когда это понадобится РЕАЛЬНО. В последних версиях
> одумались немножко.

А руководство администратора Windows почитать, конечно, не судьба

Vlad © (01.07.04 11:06) [52]

А причём тут ADO? ADO всего-навсего делегирует вызовы соответствующему OLE DB драйверу, тот - или Native-драйверу, или сам дёргает СУБД... И если бойцы из Oracle не хотят или не могут написать нормальный OLE DB драйвер - это их проблемы. Мне лично удобнее абстракция. Зачем мне забивать голову тонкостями очередной библиотеки?

> И если бойцы из Oracle не хотят или не могут написать нормальный
> OLE DB драйвер

MSDAORA ?

> Ломброзо © (01.07.04 11:38) [54]

> И если бойцы из Oracle не хотят или не могут написать нормальный
> OLE DB драйвер

если бы да кабы...
Потому и говорю, если требуется высокое быстродействие, то глупо использовать ADO, когда есть компоненты прямого доступа.
И это касается не только Оракла, кстати.

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