Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Совместимость приложения с разными СУБД
|
|||
|---|---|---|---|
|
#18+
Сразу оговорюсь, что не хотелось бы обсуждать преимущества и недостатки различных СУБД. Вопрос в другом: Разрабатывается, допустим, некая трехзвенная клент-серверная система. И планируется организавать совместимость с разными СУБД (конечно, ограниченное количество, допустим MS SQL Server, Oracle и DB2). Так вот каким образом можно это организовать? Видятся два подхода: 1. Использование всех особенностей архитектуры, диалекта SQL и т.д. присущих данной СУБД. В таком случае , большую часть логики можно вынести в хранимые процедуры, обращения к базе данных оптимизировать в зависимости от особенностей СУБД, увеличивается безопасность, уменьшается сетевой трафик - в общем плюсы очевидны. Но при таком подходе, придется переписывать тексты хранимых процедур, триггеров и т.п. для каждой СУБД, а также обращения среднего звена к серверу БД - потребуется специалист достаточно хорошо владеющий всеми используемыми СУБД. 2. Использовать только стандартные SQL - запросы при обращении к СУБД и внутри хранимых процедур. В таком случае, вся логика выносится на среднее звено, а это ведет к понижению производительности, повышению сетевого трафика, затраты на передачу промежуточных результатов и т.д. Т. е. плюсы первого подхода превращаются в минусы второго. Но! При втором подходе сам переход на другую СУБД легче и проще! Так все же какой подход лучше? Или есть еще варианты? Или где про это почитать? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.07.2002, 12:38 |
|
||
|
Совместимость приложения с разными СУБД
|
|||
|---|---|---|---|
|
#18+
Давайте подойдем к этому с такой стороны. Что нужно для успешной реализации первого подхода? Хорошие мозги программиста. Для второго? Хорошая техника. Что имеет стремление постоянно улучшаться? Техника. Проблемы с производительностью могут быть сняты установкой новой, все более и более совершенной техники, а вот если первоначально базу сваяют парочка гениев, то для дальнейшей ее поддержки народу может и не найтись. Я за второй вариант. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.07.2002, 23:29 |
|
||
|
Совместимость приложения с разными СУБД
|
|||
|---|---|---|---|
|
#18+
А я однозначно за первый. Почему? Потому что неразумно НЕ ИСПОЛЬЗОВАТЬ весь потенциал какой-либо СУБД в погоне за мифической переносимостью. Тут, ИМХО, вопрос один: Что нужно получить: прогу, которая одинаково плохо работает с целым рядом СУБД используя "стандартный" SQL, или заточенную под ряд самых популярных. Конечно, второй вариант - сложнее в реализации, но ЗНАЧИТЕЛЬНО выигрышнее в эксплуатации. При этом, сам клиент может и не заметить перехода, т.к. специфичная логика реализуется, как библиотека классов для среднего звена (plug-in). Единственное требование к ней (библиотеке), чтобы классы использовали некий стандартный интерфейс, т.е. middle-trier (server) "не замечал" подмены при обращении к объектам - экземплярам этих классов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.07.2002, 18:02 |
|
||
|
Совместимость приложения с разными СУБД
|
|||
|---|---|---|---|
|
#18+
Может я чего-то, конечно, не понимаю, но смысла использовать разные СУБД не вижу. ИМХО можно сразу определить, на кай работать лучше/быстрее/надежнее... (нужное подчеркнуть). По-моему можно заранее примерно оценить и размер базы, кол-во юзверей и др. параметры и сразу писать под выбраную базу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.07.2002, 13:19 |
|
||
|
Совместимость приложения с разными СУБД
|
|||
|---|---|---|---|
|
#18+
2 IgorK Полностью согласен, если разработка уникальная. Если же коммерческая, то там нужно "быть в широком русле", чтобы бороться за сбыт продукта. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.07.2002, 13:41 |
|
||
|
Совместимость приложения с разными СУБД
|
|||
|---|---|---|---|
|
#18+
А я в реальной жизни сталкивался с обоими вариантами: SAP - вся логика в среднем звене, для общения с базой используется стандартный SQL, который работает практически со всеми базами. Некая относительно маленькая бухг. система (называется Dream) - может работать с Oracle или c SQL Server - так там просто два параллельных кода есть - отдельно для каждой СУБД. Относительно того, что можно заранее выбрать СУБД - это не всегда работает, т.к. у клиента может быть установлена вполне определенная СУБД и устанавливать еще одну он не хочет, т.к. за софт и лицензии платить надо, админа надо или доучивать или еще одного нанимать - тем самым компании теряют рынок. Софт-то он только в России бесплатный, да админы не везде за 100$ работают. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.07.2002, 16:50 |
|
||
|
Совместимость приложения с разными СУБД
|
|||
|---|---|---|---|
|
#18+
To IgorK А и не было никакого смысла. Был закон природы. "В приложении должны работать самые разные СУБД. " Возможно, это было принято по религиозным соображениям (старая шутка археологов - если назначение предмета не удается объяснить, он считается "культовым") ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.07.2002, 19:31 |
|
||
|
Совместимость приложения с разными СУБД
|
|||
|---|---|---|---|
|
#18+
меня мучают похожие проблемы я вот подумал о каком пути - разработке собственного SQL :)))))) - промежуточного слоя, который шире, чем стандартный SQL, потому что включает в себя кроме стандартных еще и те функции, которые ПО-РАЗНОМУ реализованы в разных серверах - соответственно, при выполнении он ретранслируется в SQL того сервера, на котором выполняется. геморно конечно... что скажете, уважаемые? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.07.2002, 18:32 |
|
||
|
|

start [/forum/topic.php?fid=35&msg=32035388&tid=1554478]: |
0ms |
get settings: |
8ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
43ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
55ms |
get tp. blocked users: |
1ms |
| others: | 208ms |
| total: | 346ms |

| 0 / 0 |
