Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
||
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[3.131.110.169] |
|
Сообщ.
#1
,
|
|
|
Есть необходимость в хранимой процедуре, которая будет принимать в качестве входных параметров сложные типы данных, такие как структуры (С/С++) и массивы структур. Кроме того возможно ли организовать что-то наподобие цикла для обработки массивов?
СУБД: Postgre SQL. Спасибо. P.S. Для чего это нужно. Есть система, которая при определенных условиях записывает в БД информацию о некоторых сложных объектах. Различная информация об объекте размещается в разных, хитро между собой связанных, таблицах. Таким образом, для того, чтобы записать "объект" бывает необходимо выполнить порядка 20-30 SQL-запросов/хранимых процедур. Может случиться так, что в очереди на запись может оказаться 300к объектов, соответственно, время записи оказывается неприемлемо большим. Посему и возникла идея организовать это все в виде одной процедуры, чтобы хотя бы не гонять лишнее "му-му" по сети. |
Сообщ.
#2
,
|
|
|
проще в коде сформировать динамический sql
insert into table1(field1, ..., fieldN) values (val1, ... valN), ... (val1, ... valN); |
Сообщ.
#3
,
|
|
|
Нет, сейчас С++ код выглядит примерно так:
int id = AddBaseData(....); int id1 = AddAnotherData1(.....); int id2 = AddAnotherData2(.....); int id3 = AddAnotherData3(.....); CombineData(id, id1, id2, id3); for (....) { AddAdditionalData(id, .....); } Впрочем, 6 запросов лучше, чем 36. |
Сообщ.
#4
,
|
|
|
ну, как вариант, можно данные оформить в виде xml или csv и передавать длинной строкой
|
Сообщ.
#5
,
|
|
|
Цитата GAGARIN @ Это не "хитро связанные таблицы", это КРИВО спроектированная БД.Различная информация об объекте размещается в разных, хитро между собой связанных, таблицах ЗЫ - второй год нечто подобное разгребаю. |
Сообщ.
#6
,
|
|
|
Цитата #SI# @ Это не "хитро связанные таблицы", это КРИВО спроектированная БД. ну, классический случай - что-то типа ООП на уровне БД таблица 1 - entity - базовый объект, хранит id и что-то еще общее для всех таблицы 2 - N - наследники - ссылаются на табл 1, хранят специфическую для классов-наследников инфу Но "20-30 SQL-запросов/хранимых процедур" - это все-таки перебор ) |
Сообщ.
#7
,
|
|
|
Речь, насколько я понял, не о классике.
Речь о кривой БД и невозможности создать для неё бизнес-правила (насчёт Граблей не силён, с Ораклом таки разобрался (с тем, что пришлось околачивать)). |