|
|
|
Аррей больше трёхсот
|
|||
|---|---|---|---|
|
#18+
Насколько мне известно, то передать просто через параметр numeric-array в размере больше трехсот в dw нельзя. Как вы решаете для себя эту проблему ? 1) Через Динамический скл. Вставить строку IN (тут аррай ) 2) Разбить аррай на арреи по 300 мест и сделать ретрив 3) Вставить аррей в базу данных и уже делать джоин с этой таблицей ,,,, Есть какие нибудь нестандарные решения ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.06.2005, 00:50 |
|
||
|
Аррей больше трёхсот
|
|||
|---|---|---|---|
|
#18+
EndymionНасколько мне известно, то передать просто через параметр numeric-array в размере больше трехсот в dw нельзя. Как вы решаете для себя эту проблему ? 1) Через Динамический скл. Вставить строку IN (тут аррай ) 2) Разбить аррай на арреи по 300 мест и сделать ретрив 3) Вставить аррей в базу данных и уже делать джоин с этой таблицей ,,,, Есть какие нибудь нестандарные решения ? 1) А откуда это известно (насчёт 300) ? 2) Мы, когда надо, делаем динамический WHERE clause, а поскольку Oracle раньше не поддерживал больше 255 элементов в IN, то вокруг этого числа и крутили... 3) Можно разбивать массив на куски, dw говорить, чтобы оно append rows (то бишь в RetrieveStart eventе возвращать 2) и т.п. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.06.2005, 01:21 |
|
||
|
Аррей больше трёхсот
|
|||
|---|---|---|---|
|
#18+
Откуда известно на счёт 300 ? Я работаю с сайбес и он точно не поддерживает . Значит всё таки второй вариант ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.06.2005, 10:33 |
|
||
|
Аррей больше трёхсот
|
|||
|---|---|---|---|
|
#18+
А может быть все таки изменить логику? Более 300 аргументов для запроса это на мой взгляд не самое удачное решение. За 8 лет работы с PB мне ни разу не потребовалось передать массив в качестве аргумента запроса. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.06.2005, 11:12 |
|
||
|
Аррей больше трёхсот
|
|||
|---|---|---|---|
|
#18+
а мне недавно протребовалось: есть список изделий выбираемый из БД с помощью ХП список изделий связан с классификатором как многие ко многим пользователь может выбрать в виде условия отбора изделий неограниченное количество записей из классификатора. Мое решение: формируется строка в виде списка ID (через запятую) выбранных записей классификатора и передается как параметр в ХП. ХП превращает строку в рекордсет и присоединяет к списку изделий. Процедура превращения списка в рекордест есть на codexchange для ASA ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.06.2005, 11:41 |
|
||
|
Аррей больше трёхсот
|
|||
|---|---|---|---|
|
#18+
rcryoа мне недавно протребовалось: есть список изделий выбираемый из БД с помощью ХП список изделий связан с классификатором как многие ко многим пользователь может выбрать в виде условия отбора изделий неограниченное количество записей из классификатора. Мое решение: формируется строка в виде списка ID (через запятую) выбранных записей классификатора и передается как параметр в ХП. ХП превращает строку в рекордсет и присоединяет к списку изделий. Процедура превращения списка в рекордест есть на codexchange для ASA Я бы для ASA сделал глобальную временную таблицу (а начиная с 9.0.2.3131 может даже сессионную локальную времянку, которая создавалась бы при входе в режим и дропалась при выходе). В нее писал все то, что пометил пользователь (через тот же DW с CheckBox, в котором выводится весь список товаров и можно пометить нужные), а потом просто в запросах использовал обычный INNER JOIN к этой таблице. Дешево, красиво, удобно, никакого кода в клиенте и никаких IN :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.06.2005, 12:11 |
|
||
|
Аррей больше трёхсот
|
|||
|---|---|---|---|
|
#18+
автордаже сессионную локальную времянку, которая создавалась бы при входе в режим и дропалась при выходепо сути у меня и создается локальная времянка, только в момент запроса в скрипте ХП как я вас понял вы предлагаете в момент запроса создать временную таблицу (из клиента?) затем заполнить её данными из DW (код клиента?) а потом сделать запрос данных с объединением таблиц. Мне показалось что с этим больше возни и это не согласуется с этим автор никакого кода в клиентевариант с глобальной таблицей тоже показался не очень, так как клиент может открыть несколько одинаковых форм с запросом (у меня это можно) тогда надо передавать еще какой-нибудь ID запроса, и если есть другие подобные запросы для каждого вида запроса своя глобальная таблица, или в таблице учитывать тип запроса, вобщем морока. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.06.2005, 13:06 |
|
||
|
Аррей больше трёхсот
|
|||
|---|---|---|---|
|
#18+
Имея ввиду "никакого кода в клиенте" я имею ввиду "никакого кода бизнес-логики" в клиенте. Раз у Вас может открываться более одной формы данного режима одновременно, то делаем глобальную временную таблицу с доп. полем WindowHandle и везде работаем по фильтру в разрезе Handle окна. По моему надежней и как раз менее гемморней, чем пытаться PB генерить сотни параметров в IN, а потом использовать динамический SQL или вызывать UDF для разбора переданной строки и заполнению их в таблицу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.06.2005, 17:09 |
|
||
|
Аррей больше трёхсот
|
|||
|---|---|---|---|
|
#18+
rcryoвариант с глобальной таблицей тоже показался не очень, так как клиент может открыть несколько одинаковых форм с запросом (у меня это можно) тогда надо передавать еще какой-нибудь ID запроса, и если есть другие подобные запросы для каждого вида запроса своя глобальная таблица, или в таблице учитывать тип запроса, вобщем морока. Я обошелся всего одной глобальной времянкой. Таблица определена с несколькими полями разных типов (char (20), integer, datetime) и в зависимости от задачи заполняются соответствующие поля. А ХП уже сама знает какое поле читать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.06.2005, 18:08 |
|
||
|
Аррей больше трёхсот
|
|||
|---|---|---|---|
|
#18+
У нас ВСЕ поисковые экраны делают динамический WHERE clause с IN - НИКАКИХ временных таблиц, SPs и т.п. безобразия :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.06.2005, 18:26 |
|
||
|
Аррей больше трёхсот
|
|||
|---|---|---|---|
|
#18+
EndymionОткуда известно на счёт 300 ? Я работаю с сайбес и он точно не поддерживает То бишь семантически, фраза "передать просто через параметр numeric-array в размере больше трехсот в dw нельзя" - бессмысленна? :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.06.2005, 18:28 |
|
||
|
Аррей больше трёхсот
|
|||
|---|---|---|---|
|
#18+
хочу все-таки понять, оставим только это: автор По моему надежней и как раз менее гемморней, чем пытаться PB генерить сотни параметров... вызывать UDF для разбора переданной строки и заполнению их в таблицу так как другого я не предлагал. Просьба разъяснить где здесь снижение надежности или гемморой. Возможно в этом решении и есть какой-то недостаток и я его не вижу? Это скрипт в PB формирует строку и передает в ХП Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Код: plaintext 1. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. авторУ нас ВСЕ поисковые экраны делают динамический WHEREмне не подходит, запрос должен быть в ХП ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.06.2005, 18:37 |
|
||
|
Аррей больше трёхсот
|
|||
|---|---|---|---|
|
#18+
ФилиппУ нас ВСЕ поисковые экраны делают динамический WHERE clause с IN - НИКАКИХ временных таблиц, SPs и т.п. безобразия :-)Остается порадоваться за вас. База какая? И что ни разу не сталкивались с ограничениями на количество элементов в IN(...) ? И что ни разу не сталкивались с ограничением на размер SQL оператора? Нет? Ну значит повезло. А мы знаете вот как то не привыкли на удачу рассчитывать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.06.2005, 19:12 |
|
||
|
Аррей больше трёхсот
|
|||
|---|---|---|---|
|
#18+
White OwlЯ обошелся всего одной глобальной времянкой. Таблица определена с несколькими полями разных типов (char (20), integer, datetime) и в зависимости от задачи заполняются соответствующие поля. А ХП уже сама знает какое поле читать. УЖОСНАХ!!! Нет печальнее картины чем человечек на суппорте, который в чужом коде тупо пялится на обращения к загадочным column1 varchar(255) и column2 datetime в некой загадочной глобальной времянке. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.06.2005, 19:15 |
|
||
|
Аррей больше трёхсот
|
|||
|---|---|---|---|
|
#18+
ЗоринАндрей ФилиппУ нас ВСЕ поисковые экраны делают динамический WHERE clause с IN - НИКАКИХ временных таблиц, SPs и т.п. безобразия :-)Остается порадоваться за вас. База какая? И что ни разу не сталкивались с ограничениями на количество элементов в IN(...) ? И что ни разу не сталкивались с ограничением на размер SQL оператора? Нет? Ну значит повезло. А мы знаете вот как то не привыкли на удачу рассчитывать. Читать тщательнее надо, г-н Зорин. Oracle у нас, так что вокруг 255 крутились, и если надо, разбивали на куски, кратные 255, вот так примерно: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.06.2005, 19:38 |
|
||
|
Аррей больше трёхсот
|
|||
|---|---|---|---|
|
#18+
rcryo Вместо всего кода можно просто раз сделать глобальную временную таблицу в БД, заполнять ее через тот же DW и пользоваться в SELECT-ах, как предустановленным пользователем фильтром. В итоге помимо того, что у нас кода на клиенте нет, мы не тратим время на сбор строки в клиенте и ее разбор на сервере, мы имеем проиндексированную времянку, что учитывается при выполнении запросов оптимизатором. Ваша же ХП будет всегда идти через scan ее записей с другими в запросе. Филипп Какая у Вас интересная система на Оракле - запросы и изменения таблиц прямо с клиентского приложения, логика там же. Наверное весело права доступа расписывать и после какого то изменения/доработки структуры БД клиента всего перелопачивать ? :) Мне как то легче все на ХП держать - и с правами на таблички и представления заморачиваться не надо и клиенту все равно, что там в БД происходит, он знает что ХП ему возвращают и этого ему хватает. Правда беру свои слова обратно ... если Оракл не поддерживает "SELECT * FROM StoredProcedure()", как например MSSQL - тогда остается только посочувствовать. P.S. А вообще раз в качестве сервера используется ASA 9, давайте и рекомендовать с точки зрения ASA 9, а не писать, что ХП это бред, времянки плохо и т.д. Для кого то может и плохо. Для ASA я считаю просто прекрасно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.06.2005, 20:10 |
|
||
|
Аррей больше трёхсот
|
|||
|---|---|---|---|
|
#18+
ASCRUS Филипп Какая у Вас интересная система на Оракле - запросы и изменения таблиц прямо с клиентского приложения, логика там же. Наверное весело права доступа расписывать и после какого то изменения/доработки структуры БД клиента всего перелопачивать ? :) Не понял, причём здесь права доступа? О каких "изменениях таблиц" вы спрашиваете? Об изменениях ДАННЫХ в них - ну тогда естественно прямо с клиентского приложения, а откуда они ещё возьмутся? И не надо думать, что мы не используем ХП и т.п. - при том что у нас почти 160 пибблов клиентского приложения, я думаю объём PL/SQL кода всё равно превышает объём РВшного кода... Просто в привидённом мной примере (поисковые экраны), гибкость РВ значительно превышает возможности всяческие попытки предусмотреть юзерские извраты в stored procedure... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.06.2005, 20:38 |
|
||
|
Аррей больше трёхсот
|
|||
|---|---|---|---|
|
#18+
ЗоринАндрей White OwlЯ обошелся всего одной глобальной времянкой. Таблица определена с несколькими полями разных типов (char (20), integer, datetime) и в зависимости от задачи заполняются соответствующие поля. А ХП уже сама знает какое поле читать. УЖОСНАХ!!! Нет печальнее картины чем человечек на суппорте, который в чужом коде тупо пялится на обращения к загадочным column1 varchar(255) и column2 datetime в некой загадочной глобальной времянке. Что может быть ужасного в коде типа: select t1.* from RequestedCodes, t1 where t1.pk=RequestedCodes.CharKey; или select t2.* from RequestedCodes, t2 where t2.somedatefield=RequestedCodes.DateKey; Если в этом сложно разобраться - нафиг такой человечек в суппорте? :) Но если заполнение клиентом таблицы RequestedCodes вам кажется слишком сложным... можете заниматься формированием макроподстановок для IN(). Не смею настаивать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.06.2005, 21:48 |
|
||
|
Аррей больше трёхсот
|
|||
|---|---|---|---|
|
#18+
Угу. Был у нас когда то давно такой умелец. Для передачи параметров использовал структурку типа string1, string2, string3,... , datetime1, datetime2, datetime3,... и как-то опечатался - типа засунул в datetime5 а вытаскивал из datetime6. и коллеги все время бегали спрашивать - а что за херня такая str_1.string3 и кто ее туда положил? зато гордился - вот там у вас каких-то объектов до фига - а я обошелся одной структурой! к счастью вовремя спохватились и выгребли это дерьмо из приложения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.06.2005, 23:16 |
|
||
|
Аррей больше трёхсот
|
|||
|---|---|---|---|
|
#18+
У нас в фирме дела обстоят так: начальство не любит временные таблицы и storeprocedure. Я конечно попробую уломать начальство, но к сожалению надежды мало, потому как мне кажется что временные таблицы это красивое решение. Пока что я пользуюсь решением, наподобие решения Филлипа (его красивее). А каково точно максимальное ограничение масива я в ближайшем будущем (когда найду время) проверю. У нас тоже пользуются АСА9. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.06.2005, 23:29 |
|
||
|
Аррей больше трёхсот
|
|||
|---|---|---|---|
|
#18+
У нас десятки структур по любому поводу. Не понимаю зачем нужно создавать структуры если можно пользоваться объектами :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.06.2005, 23:31 |
|
||
|
Аррей больше трёхсот
|
|||
|---|---|---|---|
|
#18+
ЗоринАндрейУгу. Был у нас когда то давно такой умелец. Для передачи параметров использовал структурку типа string1, string2, string3,... , datetime1, datetime2, datetime3,... А вот это действительно ужасный код :) Теперь сравни его с моим. Увидишь разницу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.06.2005, 01:04 |
|
||
|
Аррей больше трёхсот
|
|||
|---|---|---|---|
|
#18+
продолжаем разговор авторВ итоге помимо того, что у нас кода на клиенте нет,какой опять код на клиенте, у вас вообще нет кода на клиенте или если вы его не привели, то его и нет. автор мы не тратим время на сбор строки в клиенте и ее разбор на сервере,согласен, но против этого мы имеем: заполнение DW (на клиенте), формирование PB SQL запроса, обращение к серверу БД, разбор запроса сервером и добавление записей в таблицу с индексом, и, чуть не забыл, перед этим удаление старых записей от предыдущего запроса (т.е два обращения к серверу) автор мы имеем проиндексированную времянку, что учитывается при выполнении запросов оптимизатором. как специалист по оптимизации запросов и использованию индексов, разъясните пожалуйста, какой будет выигрыш от использования индекса на таблице с 1-20 записями(в моем случае) (не считая затрат на поддержку индекса при вставке и удалении записей)? авторВаша же ХП будет всегда идти через scan ее записей с другими в запросе.не понял. будет scan результата разбора строки или scan всех таблиц при соединении с этим результатом? Привожу план запроса в файле. По поводу характера дискуссии. Часто наблюдаю, что вместо того чтобы привести свое решение, надо сначала обос*ать чужое, неважно какое это решение, не мое - поэтому фигня, аргументы приходится клещами вытаскивать. ничего не имею против ни хп, ни времянок с индексами, кода на сервере и ваше решение мне тоже нравится, но нелюблю безапеляционные выпады. или это на всех форумах так принято, или вы весь в пылу борьбы за размещение кода в СУБД, что вообще происходит? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.06.2005, 01:39 |
|
||
|
Аррей больше трёхсот
|
|||
|---|---|---|---|
|
#18+
ЗоринАндрейУгу. Был у нас когда то давно такой умелец. Для передачи параметров использовал структурку типа string1, string2, string3,... , datetime1, datetime2, datetime3,... и как-то опечатался - типа засунул в datetime5 а вытаскивал из datetime6. и коллеги все время бегали спрашивать - а что за херня такая str_1.string3 и кто ее туда положил? зато гордился - вот там у вас каких-то объектов до фига - а я обошелся одной структурой! к счастью вовремя спохватились и выгребли это дерьмо из приложения. А что такого плохого в одной структуре? Вот я использую одну структуру. Содержит переменные описывающие период, массивы с названиями, соответствующими аналитикам учета и несколько переменных, через которых передается режим работы. Хватает практически на все случаи жизни. А называя переменные типа RemoveOrganizationsOlderThanOneMonth через два года все равно, когда она встретится полезешь смотреть дальше в код - а что это такое по данному режиму делается? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.06.2005, 11:28 |
|
||
|
Аррей больше трёхсот
|
|||
|---|---|---|---|
|
#18+
EndymionНасколько мне известно, то передать просто через параметр numeric-array в размере больше трехсот в dw нельзя. Откуда известно? В доках не встречал, впрочем, может быть... EndymionКак вы решаете для себя эту проблему ? 2) Разбить аррай на арреи по 300 мест и сделать ретрив Есть какие нибудь нестандарные решения ? Здесь применение нестандартных решений не нужно. Выборку делаем пачками по 100 значений. Размер пачки был определен наблюдением за планом запроса на SAW5. На больших значениях оптимизатор клал на индексы и шел "секвенсом". Впрочем, в некоторых случаях это значение делается еще меньше, опять же исходя из поведения оптимизатора. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.06.2005, 21:44 |
|
||
|
|

start [/forum/topic.php?fid=15&msg=33122895&tid=1338293]: |
0ms |
get settings: |
5ms |
get forum list: |
9ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
48ms |
get topic data: |
8ms |
get forum data: |
1ms |
get page messages: |
36ms |
get tp. blocked users: |
1ms |
| others: | 204ms |
| total: | 316ms |

| 0 / 0 |
