| forw |
| Отправлено: 08.10.2004, 11:10 |
|
Не зарегистрирован
|
Вопрос простой для знающих... Динамический SQL. Есть ли такая возможность в других СУБД кроме Oracle??
Нужно выполнить перевод приложения с одной СУБД на другую... |
|
| AVC |
| Отправлено: 08.10.2004, 11:45 |
|
Ветеран
Группа: Модератор
Сообщений: 1583
|
Если имеется в виду execute immediate или его разновидности, то такая возможность есть у Sybase. Для меня обычной практикой является динамическая генерация запроса на стороне клиента.
Вам нужно выполнить перевод или сделать многоСУБДшное приложение?
При переводе динамические запросы это далеко не единственныый и даже не главный камень преткновения. |
|
| Guest |
| Отправлено: 08.10.2004, 15:32 |
|
Не зарегистрирован
|
Генерация запроса на стороне клиента, конечно поможет, только много кодить придется на стороне клиента .. На сервере такой код более компактный и эффективный.
не многоСУБДшное, перенести нужно один раз, на более легкую СУБД.
Подскажите какие могут быть проблемы при переносе?...
|
|
| AVC |
| Отправлено: 08.10.2004, 16:09 |
|
Ветеран
Группа: Модератор
Сообщений: 1583
|
Пост задвоился 
Отредактировано AVC — 08/10/2004, 16:13 |
|
| AVC |
| Отправлено: 08.10.2004, 16:10 |
|
Ветеран
Группа: Модератор
Сообщений: 1583
|
| QUOTE | | только много кодить придется на стороне клиента .. На сервере такой код более компактный и эффективный |
Отнюдь. Благодаря языку клиенту доступны очень эффективные алгоритмы генерации запроса, при которых сервер получает уже простой (относительно) запрос, который он может оптимально выполнить используя свои кеши и т.д.
Для "кодинья" на стороне клиента используются шаблоны запросов, хранящиеся на сервере, текстовые анализаторы и средства макроподстановки, которые выполнить на C++ несравненно легче, чем на SQL (даже если это PL/SQL). Кроме того, по определению, запрос в явном виде выполняется быстрее чем выполняемый через execute immediate (это дорогая команда, которую нужно по возможности избегать).
| QUOTE | | Подскажите какие могут быть проблемы при переносе?... |
Какие угодно.
Способы и системы блокировок.
Синтаксические правила встроенного языка написания процедур, триггеров и ...
Способы и необходимость разнообразных индексов
Да даже зачастую настройки языка для работы с национальным текстом.
...
Короче. Как правило при смене СУБД для серьезной базы все приходится делать заново. Удается перетянуть только данные. Мало того, приходится перелопачивать и клиентские приложения, конечно если вы не используете "тонкого клиента" типа веб-броузера.
|
|
| Guest |
| Отправлено: 10.10.2004, 12:57 |
|
Не зарегистрирован
|
| QUOTE |
Для "кодинья" на стороне клиента используются шаблоны запросов, хранящиеся на сервере, текстовые анализаторы и средства макроподстановки, которые выполнить на C++ несравненно легче, чем на SQL (даже если это PL/SQL). Кроме того, по определению, запрос в явном виде выполняется быстрее чем выполняемый через execute immediate (это дорогая команда, которую нужно по возможности избегать). |
Насколько возможно разделяю логику приложения на серверную часть и клиентскую, вплоть до того что клиенту напрямую недоступны никакие объекты кроме программных модулей. Взаимодействие происходит через набор процедур.
Плюсы такого подхода — уменьшение сеансов обмена по сети между сервером и клиентом, упрощаются сопровождение и модификация кода, эффективная защита данных по крайней мере на уровне базы данных и приложения.
| QUOTE |
Короче. Как правило при смене СУБД для серьезной базы все приходится делать заново.
|
Спасибо за предупреждение, надеюсь нерешаемых проблем не появится.
|
|
