| Версия для печати
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум на Исходниках.RU > C/C++: Базы данных > Сложный тип данных как параметр хранимой процедуры |
| Автор: GAGARIN 22.01.15, 17:29 |
| Есть необходимость в хранимой процедуре, которая будет принимать в качестве входных параметров сложные типы данных, такие как структуры (С/С++) и массивы структур. Кроме того возможно ли организовать что-то наподобие цикла для обработки массивов? СУБД: Postgre SQL. Спасибо. P.S. Для чего это нужно. Есть система, которая при определенных условиях записывает в БД информацию о некоторых сложных объектах. Различная информация об объекте размещается в разных, хитро между собой связанных, таблицах. Таким образом, для того, чтобы записать "объект" бывает необходимо выполнить порядка 20-30 SQL-запросов/хранимых процедур. Может случиться так, что в очереди на запись может оказаться 300к объектов, соответственно, время записи оказывается неприемлемо большим. Посему и возникла идея организовать это все в виде одной процедуры, чтобы хотя бы не гонять лишнее "му-му" по сети. |
| Автор: Relaxander 22.01.15, 19:29 |
| проще в коде сформировать динамический sql insert into table1(field1, ..., fieldN) values (val1, ... valN), ... (val1, ... valN); |
| Автор: GAGARIN 22.01.15, 19:41 |
| Нет, сейчас С++ код выглядит примерно так: <{CODE_COLLAPSE_OFF}><{CODE_WRAP_OFF}> int id = AddBaseData(....); int id1 = AddAnotherData1(.....); int id2 = AddAnotherData2(.....); int id3 = AddAnotherData3(.....); CombineData(id, id1, id2, id3); for (....) { AddAdditionalData(id, .....); } Впрочем, 6 запросов лучше, чем 36. |
| Автор: Relaxander 22.01.15, 19:49 |
| ну, как вариант, можно данные оформить в виде xml или csv и передавать длинной строкой |
| Автор: #SI# 22.01.15, 20:41 |
| Цитата GAGARIN @ Это не "хитро связанные таблицы", это КРИВО спроектированная БД.Различная информация об объекте размещается в разных, хитро между собой связанных, таблицах ЗЫ - второй год нечто подобное разгребаю. |
| Автор: Relaxander 22.01.15, 21:01 |
| ну, классический случай - что-то типа ООП на уровне БД таблица 1 - entity - базовый объект, хранит id и что-то еще общее для всех таблицы 2 - N - наследники - ссылаются на табл 1, хранят специфическую для классов-наследников инфу Но "20-30 SQL-запросов/хранимых процедур" - это все-таки перебор ) |
| Автор: #SI# 22.01.15, 21:15 |
| Речь, насколько я понял, не о классике. Речь о кривой БД и невозможности создать для неё бизнес-правила (насчёт Граблей не силён, с Ораклом таки разобрался (с тем, что пришлось околачивать)). |