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

← →
Vlad © (2004-06-29 20:54) [40]

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

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

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

← →
Mim1 © (2004-06-29 20:54) [41]

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

← →
Игорь Шевченко © (2004-06-29 22:33) [42]

Ihor Osov"yak © (29.06.04 20:04)

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

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

С уважением,

← →
Ломброзо © (2004-06-30 01:16) [43]

Vlad © (29.06.04 20:54) [40]

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

← →
Ihor Osov'yak © (2004-06-30 01:56) [44]

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

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

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

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

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

← →
vuk © (2004-06-30 11:50) [45]

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

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

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

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

← →
iZEN © (2004-06-30 18:27) [46]

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

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

← →
vuk © (2004-06-30 18:57) [47]

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

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

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

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

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

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

← →
iZEN © (2004-06-30 19:10) [48]

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

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

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

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

← →
wisekaa © (2004-06-30 19:15) [49]

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

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

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

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

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

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

← →
Igorek © (2004-07-01 10:56) [51]

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

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

> Ломброзо © (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 - мосты и окна Найти похожие ветки