Строки из resource-файла или что-то другое?

← →
Ega23 © (2008-05-19 11:13) [0]

Задача: надо "научить" программу работать с разными СУБД. Предварительно идея была использовать ANSISQL, но, к сожалению, не получается - кое-какие моменты не учитываются.
Теперь идея - к exe прилагается некий ресурсный файл, где тексты запросов хранятся, разнесённые по разным SQL-диалектам. Насколько это оправдано, какие ещё могут быть варианты решения?
И вообще, как строку из ресурсного файла грузить? :)

← →
KSergey © (2008-05-19 11:25) [1]

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

Ну и, наверное, есть смысл различными держать только те запросы, которые на самом деле не удается сделать кросплатформенными. Большенство запросов все ж обычно не такие.

← →
Ega23 © (2008-05-19 11:33) [2]

> Варианты решения - прослойка, понимающая некие метакоманды
> или методы на своем интерфейсе и генерящая SQL. Но это тоже
> тот еще путь. Практически как пытаться на ANSISQL все делать.
> Хотя если база не сильно хитрая, то может ANSISQL все ж
> будет достаточно? Вернее не ANSISQL как таковой, а просто
> свод правил для разработчиков, что можно использовать, а
> что нет для поддерживаемых СУБД и как такую-то фигню решить
> "кросс-эс-ку-эльно" для поддерживаемых языков, если это
> возможно.

Не, к сожалению не пойдёт. Задача стоит такая, чтобы один голый exe мог работать и с Postgres, и c MSSQL и может ещё с чем-нибудь. Правила для разработчиков - тоже нереально. ANSI не получается из-за "прибабахнутого" диалекта plpgsql. Да и имена системных таблиц у всех разные (а они для проверок целостности БД нужны).
При этом динамических запросов не будет, всё достаточно статично. Так что, как ни крути, вырисовывается "что-то", сильно напоминающее ресурс, в котором поимённо хранятся эти самые тексты.

← →
Renegat (2008-05-19 11:37) [3]

> какие ещё могут быть варианты решения?

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

← →
KSergey © (2008-05-19 11:45) [4]

1) "Правила для разработчиков - тоже нереально." Это очень плохо. Очень! Чем меньше "художников" - тем лучше качество продукта.

2) Если проблема только в именах системных таблиц - то никто не мешает завести в постгресе вьюхи для "недостающих" системных таблиц с именем как в MS SQL. Равно ка ки наоборот. Или взаимно: и тама, и тама ввести какую-либо унификацию. Хуже, когда для оптимизации приходится вводить всякие хинты, имеющие принципиально различный синтаксис да еще и местоположение в пределах запроса - вот тут действительо засада и спасает либо прослойка, либо по 2 варианта запросов.

К стати, а как этому самому exe распознать с какой он базой должен работать?

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

← →
DiamondShark © (2008-05-19 11:45) [5]

Прослойку-транслятор с ANSISQL на прибабахнутый.

← →
Игорь Шевченко © (2008-05-19 11:46) [6]

> И вообще, как строку из ресурсного файла грузить? :)

LoadString

> Теперь идея - к exe прилагается некий ресурсный файл, где
> тексты запросов хранятся, разнесённые по разным SQL-диалектам.
> Насколько это оправдано, какие ещё могут быть варианты
> решения?

Плохая идея.

← →
Хитрий Лис (2008-05-19 11:47) [7]

> чтобы один голый exe мог работать и с Postgres, и c MSSQL и может ещё с чем-нибудь

Голому ЕХЕ можно создавать файлы настроек или запись в реестре ?
Т.е. место где может храниться строка коннекта к конкретному серверу и т.п. настройки.

По базе:
Кроме желательно ANSISQL рекомендую ограничить взаимодействие з базой до select from view, select from proc а уже на каждой базе делать свою реализацию.

← →
Хитрий Лис (2008-05-19 11:49) [8]

На добавку:
Тексты запросов можно хранить в той же базе, а выбирать по ID из таблички с унифицированім именем.

← →
Дмитрий С (2008-05-19 11:50) [9]

resourcestring вместо const?

← →
Ega23 © (2008-05-19 11:54) [10]

> К стати, а как этому самому exe распознать с какой он базой
> должен работать?
>

Ну маленький ini-файл c параметрами коннекта всё-таки есть. Оттуда и тип DBMS узнаю.

← →
DiamondShark © (2008-05-19 12:02) [11]

Очередная "гибкость", грозящая превратиться в криволапость.

Масенький пример.
В MSSQL rollback откатывает все вложенные транзакции, до самого верха. А, к примеру, в Sybase ASA rollback откатывает только на один уровень.

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

← →
Ega23 © (2008-05-19 12:04) [12]

> DiamondShark © (19.05.08 12:02) [11]
>
> Очередная "гибкость", грозящая превратиться в криволапость.

Сами базы и предварительно-предполагаемые запросы - достаточно простые, всякие хитрые многоуровневые транзакции не понадобятся.

← →
b z (2008-05-19 12:51) [13]

> Хитрий Лис (19.05.08 11:47) [7]
> По базе:
+1

> b z (19.05.08 12:51) [13]
>
>
> > Хитрий Лис (19.05.08 11:47) [7]
> > По базе:
> +1
>

select from proc - в том-то и дело, что тот же MSSQL такого не умеет. :)

← →
b z (2008-05-19 12:58) [15]

> Ega23 © (19.05.08 12:52) [14]
> select from proc

Это утрировано, вы же будете работать по средствам соотв. компонентов (или нет?), а они и сами это умеют. Вот уровень работы с базой - в отд. длл (к примеру), тогда при создании конкр. сборки (под конкр. субд) берете соответствующую длл.

> select from proc - в том-то и дело, что тот же MSSQL такого
> не умеет. :)

Зато он умеет exec proc.

А вообще, намёк был на то, чтобы унифицировать интерфейс со стороны базы, завернуть всё во вью и процедуры.

Тогда и со стороны клиента унификация будет проще.

← →
b z (2008-05-19 13:01) [17]

> b z (19.05.08 12:58) [15]

+ ко второй части, если добавят еще одну разновидность субд, вам надо будет написать только новую длл.

Строки из resource-файла или что-то другое? Найти похожие ветки