Совместимость приложения с различными СУБД

← →
Alex-A © (2002-07-06 07:05) [0]

Сразу оговорюсь, что не хотелось бы обсуждать преимущества и недостатки различных СУБД. Вопрос в другом:
Разрабатывается, допустим, некая трехзвенная клент-серверная система. И планируется организавать совместимость с разными СУБД (конечно, ограниченное количество, допустим MS SQL Server, Oracle и DB2).
Так вот каким образом можно это организовать?
Видятся два подхода:
1. Использование всех особенностей архитектуры, диалекта SQL и т.д. присущих данной СУБД. В таком случае , большую часть логики можно вынести в хранимые процедуры, обращения к базе данных оптимизировать в зависимости от особенностей СУБД, увеличивается безопасность, уменьшается сетевой трафик - в общем плюсы очевидны.
Но при таком подходе, придется переписывать тексты хранимых процедур, триггеров и т.п. для каждой СУБД,
а также обращения среднего звена к серверу БД - потребуется специалист достаточно хорошо владеющий всеми используемыми СУБД.
2. Использовать только стандартные SQL - запросы при обращении к СУБД и внутри хранимых процедур. В таком случае, вся логика выносится на среднее звено, а это ведет к понижению производительности, повышению сетевого трафика, затраты на передачу промежуточных результатов и т.д. Т. е. плюсы первого подхода превращаются в минусы второго.
Но! При втором подходе сам переход на другую СУБД легче и проще!

Так все же какой подход лучше?
Или есть еще варианты?
Или где про это почитать?

← →
blackman (2002-07-06 12:36) [1]

А что можно назвать стандартом ?
Если Вы это уже определили, то п.2
Но скорее всего всегда будет п.1
Иначе зачем выбираем СУБД ?

← →
Delirium © (2002-07-06 12:40) [2]

Полагаю, наиболее эффективен первый вариант, тогда совместимость с различными СУБД в конечном счёте сведётся к экспорту/импорту информации между серверами, а для этого существуют отлаженные и общепринятые механизмы (как правило на уровне самих серверов БД). А целесообразность написания сервера приложений, универсального по отношению к нескольким СУБД достаточно сомнительна, так как всё универсальное таит в себе множество недостатков - меньшая производительность, меньшая гибкость, громоздкость кода, ресурсоёмкость и т.п. Короче, лучше сразу ориентироваться на большую СУБД (Oracle, MSSQL), тем самым исключая саму необходимость в будущем переходе на другую систему.

← →
kaif © (2002-07-06 15:43) [3]

Присоединяюсь к Delirium © (06.07.02 12:40).
Лучше иметь и легче поддерживать даже 3 версии системы для разных СУБД, чем пытаться сделать нечто универсальное. Боюсь, что второй вариант просто неосуществим без того, чтобы не потерять 90% возможностей самих СУБД, которые и стоят-то немало именно в силу этих самых возможностей. Вариант 1 экономически более выгоден во всех отношениях.

← →
Polevi © (2002-07-07 11:50) [4]

-Использовать только стандартные SQL - запросы при обращении к СУБД
Ничего не выйдет из этого
Например для получения ID только что добавленой записи пр работе с MS SQL я использую SELECT @@IDENTITY - другого способа не вижу а в этом нет ничего "стандартного"

> All
Присоединяюсь к мнению в пользу первого пункта...

> Polevi © (07.07.02 11:50)
Значения ключей, генерируемые на сервере, не всегда удобны, особенно в случае трехзвенок.
В MSSQL можно реализовать ручками свою систему генераторов (аналог IB)...

>blackman
Я имел ввиду стандарт определенный ANSI

>All
Всем спасибо! Я в общем-то тоже более склоняюсь к первому варианту, но в этом случае резко возрастают затраты на разработку и сопровождение.

Совместимость приложения с различными СУБД Найти похожие ветки