Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
%INLIST() vs. IN() = <MAXSTRING>!? (и немного zen)
|
|||
|---|---|---|---|
|
#18+
Пример возьмем из соседнего топика про суперфильм (я про соцсеть ;): Допустим, есть объект "Человек", пусть в примере айди человека 55 у него туча свойств типа "Человек" (супруг 78, дети 102,126,184, родители 5,7, друзья 77,64) и некое расчетное свойство "ближний_круг" - куда в виде листа сваливаются его айдишник вкупе с айдишниками всех его друзей/родственников $lb(55,78,102,126,...) Есть объект "Клуб", содержащий объекты "Член" (простите мой французский), ссылающиеся на "Человека" ЗАДАЧА: Для ограниченного набора "Членов", например, для "любителей подводного лова" получить информацию о "Человеках" их близкого окружения. Например, список фамилий и цвет волос (почему бы и нет...). JOIN по-простому прикрутить не могу не подходит. Но памятуя, что JOIN лежит на одной полочке с IN, решение представлял таким: 1. Поскольку список всей родни всех рыбаков, по-сути есть список списков, а нас интересует просто список, понадобится преобразование вида Код: plaintext 1. 2. 3. В переменной список_родни_рыбаков окажется то, что там и должно оказаться ;) Уверен, что есть более красивые варианты, но я их не знаю ;( 2. С учетом того, что речь идет о зене, далее нужно сформировать условие для прорисовки таблицы. И для условия есть два варианта: Код: plaintext 1. Во втором для больших групп выходит сообщение ...<MAXSTRING>removeRedundant+14^%qaqpre2 ... Откуда ноги растут, примерно понятно. А вот как обойти - не очень. Может, кто в курсе, что неправильно в запросе вида: Код: plaintext 1. 2. 3. "ОШИБКА #5540: SQLCODE: -12 Сообщение: Ожидается конструкция, начинающаяся с: идентификатора, константы, агрегата, $$, (, :, +, -, %ALPHAUP, %EXACT, %MVR %SQLSTRING, %SQLUPPER, %STRING или %UPPER ^ SELECT <купюра> %INLIST ( $ listbuild ( SELECT<именно в этом месте текст ошибки обрывается>" ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2010, 08:32 |
|
||
|
%INLIST() vs. IN() = <MAXSTRING>!? (и немного zen)
|
|||
|---|---|---|---|
|
#18+
kolesovА вот как обойти - не очень. Как вариант, вместо IN - хранимая процедура. Которая просто вернёт истину или ложь для некой записи таблицы... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2010, 08:47 |
|
||
|
%INLIST() vs. IN() = <MAXSTRING>!? (и немного zen)
|
|||
|---|---|---|---|
|
#18+
kolesov , т.е. идея такая - все "длинное" заменить на нечто "короткое". До тех пор, пока (как минимум) данная ошибка не уйдёт... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2010, 08:49 |
|
||
|
%INLIST() vs. IN() = <MAXSTRING>!? (и немного zen)
|
|||
|---|---|---|---|
|
#18+
Размер списка ограничен (~32Kb), так же как и размер текста запроса. Проще и гибче будет, если "ближний_круг" окажется не списком людей, а курсором. Тогда можно будет написать, что-то типа: Код: plaintext 1. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2010, 09:18 |
|
||
|
%INLIST() vs. IN() = <MAXSTRING>!? (и немного zen)
|
|||
|---|---|---|---|
|
#18+
servitРазмер списка ограничен (~32Kb), так же как и размер текста запроса. Проще и гибче будет, если "ближний_круг" окажется не списком людей, а курсором. Тогда можно будет написать, что-то типа: Код: plaintext 1. Это первое, что и пришло в голову... Да есть проблемка небольшая - в результат попадают лишь те данные, где "ближний_круг" состоит ТОЛЬКО из айди рыбака (проще говоря, когда рыбачок один-одинешенек на свете). То-то я удивился, когда вернулось очень мало записей... Это и понятно, получается WHERE ID IN ("55", "56,67,123", "78,144" etc.). Вот и попадет только 55 в выборку. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.12.2010, 09:06 |
|
||
|
%INLIST() vs. IN() = <MAXSTRING>!? (и немного zen)
|
|||
|---|---|---|---|
|
#18+
krvsakolesovА вот как обойти - не очень. Как вариант, вместо IN - хранимая процедура. Которая просто вернёт истину или ложь для некой записи таблицы...Один из аспектов проблемы- замена "IN" на "%INLIST", ибо второй работает ощутимо быстрее... Но, похоже лишь с довольно ограниченными листами. Противоречие: вроде листы по размеру не ограничены, а %INLIST в качестве аргумента принимает только коротенькие... этакие $listik ($listochechek). В общем и целом резюмирую: Не пытайтесь сделать что-то сложнее табуретки используя Intersystems Cache' . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.12.2010, 09:14 |
|
||
|
%INLIST() vs. IN() = <MAXSTRING>!? (и немного zen)
|
|||
|---|---|---|---|
|
#18+
kolesovservitРазмер списка ограничен (~32Kb), так же как и размер текста запроса. Код: plaintext 1. 2. 3. 4. 5. 6. 7. Вот же подстава... А уж как разрекламировали этот %INLIST... а он - так себе ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.12.2010, 09:25 |
|
||
|
%INLIST() vs. IN() = <MAXSTRING>!? (и немного zen)
|
|||
|---|---|---|---|
|
#18+
Не пытайтесь сделать что-то сложнее табуретки используя извращенные методы, не понимая принципов устройства или имея кривые руки. Если бы вы знали, что список это строка, у вас даже мысли бы не возникло использовать его для таких целей. Для доступа к элементу списка при условии, что список состоит из N элементов нужно в среднем N/2 итераций. У вас ошибка в проектировании. Не могут дети быть свойствами человека. Я сейчас скажу слово "связи" - и придет злой бабай, объяснит вам, как вы неправы. Правда он скажет, что их вообще нет в ни в каше ни вообще в SQL, но это уже вопрос интерпретации. У вас задача довольно простая и решается средствами SQL Такие таблицы Человек - (Человек) - люди Родня - (Человек, Человек2, Тип родства) - родственники Клуб -(Клуб) Члены клуба -(Клуб, Человек) - члены клуба ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.12.2010, 10:45 |
|
||
|
%INLIST() vs. IN() = <MAXSTRING>!? (и немного zen)
|
|||
|---|---|---|---|
|
#18+
kolesovВот же подстава... А уж как разрекламировали этот %INLIST... а он - так себе ;)%INLIST делает ровно то, на что был рассчитан. Я им часто пользуюсь, когда уверен в небольшом размере списка или обрабатываю поля-списки (вместо FOR SOME %ELEMENT ): Код: plaintext 1. 2. 3. 4. PS: всё зависит от проектирования структуры классов. Имея её, можно было бы дать более конкретный ответ, а пока так: Код: plaintext 1. 2. 3. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.12.2010, 13:50 |
|
||
|
%INLIST() vs. IN() = <MAXSTRING>!? (и немного zen)
|
|||
|---|---|---|---|
|
#18+
Блок А.Н.У вас ошибка в проектировании. Ха. Я взял данную структуру в качестве примера (см. начало топика). Вдаваться в реальные подробности моих структур данных в данном случае не считаю нужным. Задачи, подобные приведенной, существуют независимо от того, есть ли у меня ошибки в проектировании ;) Собственно, уперся в ограничение размера списка. Значит, остается использовать IN или JOIN. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.12.2010, 02:30 |
|
||
|
%INLIST() vs. IN() = <MAXSTRING>!? (и немного zen)
|
|||
|---|---|---|---|
|
#18+
kolesov, SQL развращает ... Код: 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. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. Код: 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.12.2010, 20:51 |
|
||
|
|

start [/forum/topic.php?fid=39&fpage=45&tid=1557875]: |
0ms |
get settings: |
5ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
37ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
67ms |
get tp. blocked users: |
1ms |
| others: | 216ms |
| total: | 358ms |

| 0 / 0 |
