|
|
|
Получить 3 набора записей из функции
|
|||
|---|---|---|---|
|
#18+
С клиента (на delphi) требуется вызвать функцию сервера, которая возвратит 3 множества записей, разумеется с разной структурой. *Важное уточнение: от обмена клиент-сервер требуется максимальное быстродействие, при условии что часть клиентов подключена через медленное соединение. В PL/pgSQL пока разбираюсь не настолько, чтобы сообразить, возможно ли вернуть их через out-параметры, да и непонятно, как с клиента-то их прочитать. Скорее всего, так нельзя... Значит, придётся возвратить только один набор, а остальные получить отдельными вызовами. Тогда сервер должен временно сохранить эти наборы до последующих вызовов с клиента. Видимо, следует задействовать временные таблицы? Или лучше, учитывая (*), упаковать эти наборы в bytea - наборы и передать сразу..? Какая бест-практик в моём случае? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.03.2015, 11:14 |
|
||
|
Получить 3 набора записей из функции
|
|||
|---|---|---|---|
|
#18+
_avzС клиента (на delphi) требуется вызвать функцию сервера, которая возвратит 3 множества записей, разумеется с разной структурой. *Важное уточнение: от обмена клиент-сервер требуется максимальное быстродействие, при условии что часть клиентов подключена через медленное соединение. В PL/pgSQL пока разбираюсь не настолько, чтобы сообразить, возможно ли вернуть их через out-параметры, да и непонятно, как с клиента-то их прочитать. Скорее всего, так нельзя... Значит, придётся возвратить только один набор, а остальные получить отдельными вызовами. Тогда сервер должен временно сохранить эти наборы до последующих вызовов с клиента. Видимо, следует задействовать временные таблицы? Или лучше, учитывая (*), упаковать эти наборы в bytea - наборы и передать сразу..? Какая бест-практик в моём случае? варианта три 1)вернуть 1 большой json ответ 2)вернуть 3 массива составных типов (тот же json просто сериализация другая) 3)вернуть 3 курсора и клиентом затем из них вычитать 3мя дополнительными ззапросами PS: через out параметры вы задачу не решите. через временные таблицы не советую - очень дорогое решение. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.03.2015, 12:35 |
|
||
|
Получить 3 набора записей из функции
|
|||
|---|---|---|---|
|
#18+
_avzС клиента (на delphi) требуется вызвать функцию сервера, которая возвратит 3 множества записей, разумеется с разной структурой. Этого не может быть, потому что этого не может быть никогда. :-) В plpg/sql типизация сильная. Можно конечно извратиться, чтобы одна функция возвращала 3 разных типа, но это будет полный изврат. Так лучше не делать _avzВ PL/pgSQL пока разбираюсь не настолько, чтобы сообразить, возможно ли вернуть их через out-параметры, да и непонятно, как с клиента-то их прочитать. Скорее всего, так нельзя... Считайте что нельзя! Так будет лучше, в т.ч. и вам. _avz Значит, придётся возвратить только один набор, а остальные получить отдельными вызовами. Тогда сервер должен временно сохранить эти наборы до последующих вызовов с клиента. Видимо, следует задействовать временные таблицы? Или лучше, учитывая (*), упаковать эти наборы в bytea - наборы и передать сразу..? Какая бест-практик в моём случае? Бест-практик в вашем случае выбросить глупости из головы. Делать нужно правильно! Т.е. если вам нужно три разных результата, то нужно делать три разных запроса. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.03.2015, 12:35 |
|
||
|
Получить 3 набора записей из функции
|
|||
|---|---|---|---|
|
#18+
_avz, много букв, мало деталей сути задачи, характеристик и связей результатов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.03.2015, 12:41 |
|
||
|
Получить 3 набора записей из функции
|
|||
|---|---|---|---|
|
#18+
_avzС клиента (на delphi) требуется вызвать функцию сервера, которая возвратит 3 множества записей, разумеется с разной структурой. *Важное уточнение: от обмена клиент-сервер требуется максимальное быстродействие, при условии что часть клиентов подключена через медленное соединение. В PL/pgSQL пока разбираюсь не настолько, чтобы сообразить, возможно ли вернуть их через out-параметры, да и непонятно, как с клиента-то их прочитать. Скорее всего, так нельзя... Значит, придётся возвратить только один набор, а остальные получить отдельными вызовами. Тогда сервер должен временно сохранить эти наборы до последующих вызовов с клиента. Видимо, следует задействовать временные таблицы? Или лучше, учитывая (*), упаковать эти наборы в bytea - наборы и передать сразу..? Какая бест-практик в моём случае?а NextRecordset (или что-то около) в ADO отключили ? есть стандратный бэд паттерн -- открыть три курсора и держать транзакцию открытой с клиента -- распространён у аров-калоедов. но это особенности ара-кала, как вструмента, им диктуют. жалко их ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.03.2015, 12:45 |
|
||
|
Получить 3 набора записей из функции
|
|||
|---|---|---|---|
|
#18+
Maxim Bogukварианта три 1)вернуть 1 большой json ответдля моего клиента не самое удобное (компоненты pgDAC не поддерживают) 2)вернуть 3 массива составных типов (тот же json просто сериализация другая)Спасибо за идею, посмотрю как с этим в pgDAC, но думаю что придётся вручную разбирать. 3)вернуть 3 курсора и клиентом затем из них вычитать 3мя дополнительными ззапросамиспасибо, поизучаю такую возможность через временные таблицы не советую - очень дорогое решение. В том смысле, что быстродействие будет не очень? Например, если создать эти темп. таблицы один раз за сессию, а в каждом вызове функции их перезаполнять? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.03.2015, 12:55 |
|
||
|
Получить 3 набора записей из функции
|
|||
|---|---|---|---|
|
#18+
mad_nazgulДелать нужно правильно! Т.е. если вам нужно три разных результата, то нужно делать три разных запроса. Вообще - да, только тогда получится что самый тяжёлый запрос будет выполнен трижды, в то время как в моём случае возможно подобрать все нужные данные, исполнив его единожды. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.03.2015, 13:00 |
|
||
|
Получить 3 набора записей из функции
|
|||
|---|---|---|---|
|
#18+
?Ыа NextRecordset (или что-то около) в ADO отключили ? на клиенте используется библиотека pgDAC. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.03.2015, 13:02 |
|
||
|
Получить 3 набора записей из функции
|
|||
|---|---|---|---|
|
#18+
запись массивов записей_avz, много букв, мало деталей сути задачи, характеристик и связей результатов.Деталями задачи грузить не хотелось бы, вопрос больше про возможности, имеющиеся у субд. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.03.2015, 13:10 |
|
||
|
Получить 3 набора записей из функции
|
|||
|---|---|---|---|
|
#18+
_avzmad_nazgulДелать нужно правильно! Т.е. если вам нужно три разных результата, то нужно делать три разных запроса. Вообще - да, только тогда получится что самый тяжёлый запрос будет выполнен трижды, в то время как в моём случае возможно подобрать все нужные данные, исполнив его единожды. Так сделайте один запрос в котором возвратиться все что надо. :-) Потом раскидайте по нужным вам спискам. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.03.2015, 13:56 |
|
||
|
Получить 3 набора записей из функции
|
|||
|---|---|---|---|
|
#18+
mad_nazgul_avzпропущено... Вообще - да, только тогда получится что самый тяжёлый запрос будет выполнен трижды, в то время как в моём случае возможно подобрать все нужные данные, исполнив его единожды. Так сделайте один запрос в котором возвратиться все что надо. :-) Потом раскидайте по нужным вам спискам.так не получится в рамках одного запроса. детали, если интересноГрубо говоря, наборы такие: 1) список ид объектов, выбираемых по сложному условию, на отбор которых сервер тратит много времени 2) набор с детальной информацией по объектам из списка 1, причём записей там на порядок меньше. 3)большой объём (много колонок) по небольшой части объектов из списка 1. Причём на клиентах с медленной (модемной!) связью проверено: один большой запрос на большой блок данных выполняется намного быстрее, чем сотни мелких, забирающих те же данные. Отсюда желание забрать все за один раз. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.03.2015, 14:32 |
|
||
|
Получить 3 набора записей из функции
|
|||
|---|---|---|---|
|
#18+
_avz, кста, подумал, если сказать с клиента одним предложением Код: plsql 1. 2. 3. 4. 5. 6. то библой с NextRecordset [или аналогом ] можно будет возвраты перебрать, при этом с клиента транзакцию не держать (что всегда чревато висящим "idle in transaction" соединением при отвалившемся клиенте). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.03.2015, 14:47 |
|
||
|
Получить 3 набора записей из функции
|
|||
|---|---|---|---|
|
#18+
пока решил второй и третий наборы запаковать на сервере в bytea-блоки, которые будут возвращены через out-параметры и разобраны на клиенте. Решение не извращения ради, а только для скорости обмена :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.03.2015, 14:48 |
|
||
|
Получить 3 набора записей из функции
|
|||
|---|---|---|---|
|
#18+
_avzнаборы такие: 1) список ид объектов, выбираемых по сложному условию, на отбор которых сервер тратит много времени 2) набор с детальной информацией по объектам из списка 1, причём записей там на порядок меньше. 3)большой объём (много колонок) по небольшой части объектов из списка 1. Это всё охватывающие множества. Что мешает вернуть один набор из "много колонок", у которого для ненужных объектов в ненужных колонках будет NULL? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.03.2015, 14:49 |
|
||
|
Получить 3 набора записей из функции
|
|||
|---|---|---|---|
|
#18+
?Ы_avz, кста, подумал, если сказать с клиента одним предложением Код: plsql 1. 2. 3. 4. 5. 6. то библой с NextRecordset [или аналогом ] можно будет возвраты перебрать, при этом с клиента транзакцию не держать (что всегда чревато висящим "idle in transaction" соединением при отвалившемся клиенте). Да, я уже подумал над этим вариантом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.03.2015, 14:50 |
|
||
|
Получить 3 набора записей из функции
|
|||
|---|---|---|---|
|
#18+
Dimitry Sibiryakov_avzнаборы такие: 1) список ид объектов, выбираемых по сложному условию, на отбор которых сервер тратит много времени 2) набор с детальной информацией по объектам из списка 1, причём записей там на порядок меньше. 3)большой объём (много колонок) по небольшой части объектов из списка 1. Что мешает вернуть один набор из "много колонок", у которого для ненужных объектов в ненужных колонках будет NULL? одному объекту может соответствовать несколько деталей, но для большинства (90%) объектов деталей вообще нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.03.2015, 14:53 |
|
||
|
|

start [/forum/topic.php?fid=53&msg=38906970&tid=1998117]: |
0ms |
get settings: |
9ms |
get forum list: |
16ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
48ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
57ms |
get tp. blocked users: |
2ms |
| others: | 207ms |
| total: | 358ms |

| 0 / 0 |
