hvladТаблоидчто такое "контекст" ?Во время выполнения запрос вычисляет и хранит состояние каждого потока данных (таблицы в простейшем случае).
Грубо говоря - текущую запись из каждого потока.
Операторы BLR принимают номера потоков (контекстов) как параметры.
Номер контекста кодируется 1 байтом, отсюда ограничение.
Т.е. если какой-нибудь генератор sql-кода сгенерит 256 джойнов одним селектом, то всё пропало?
Если это так, то можно ли отодвинуть это ограничение хотя бы до размера word?

У меня вот 175 джойнов генерится, при этом вытаскиваются 560 полей из примерно 30 таблиц. Это для печати отчёта. Лишних полей там нет, т.е. они либо печатаются, либо участвуют в вычислениях в отчёте. Это не табличный отчёт, а одностраничный документ с детальными характеристиками покупаемого изделия (много цифр, много букв).
И запрос уже на 45 килобайт... Простой селект одной записи с кучей джойнов.

И я вполне допускаю, что со временем система может перешагнуть и через 64K на этом запросе, и через 256 джойнов.
Я могу конечно запрос побить на два, причём прозрачно для отчётера (fastreport), на уровне кода сервера приложений. Но имхо универсальней будет убрать ограничение в дальние дали :)

hvladNickDeeможно ли отодвинуть это ограничение хотя бы до размера word?Нет.
Что-то поломается?

Гаджимурадов РустамNickDee> Т.е. если какой-нибудь генератор sql-кода сгенерит
NickDee> 256 джойнов одним селектом, то всё пропало?

Почему всё пропало? Ни с сервером, ни с БД
ничего не происходит, а запрос не выполнится, да.

Вот представь, что у тебя есть табличка, в которой среди прочих есть четыре поля: FirstDocId, SecondDocId, ThirdDocId, FourthDocId (ссылаются на одну табличку Docs). И у тебя есть вьюшка по таблице.
И вот тебе говорят, что во вьюшку нужно добавить четыре поля:
FirstDocId.ManagerId.ServerId.DealerId.CountryId.Name
SecondDocId.ManagerId.ServerId.DealerId.CountryId.Name
ThirdDocId.ManagerId.ServerId.DealerId.CountryId.Name
FourthDocId.ManagerId.ServerId.DealerId.CountryId.Name

Каждое такое поле развернётся в 5 joins, итого +20.

Понятно что имея инструмент, который позволяет строить такие вьюшки на раз-да, без написания sql вручную, то можно вполне наступить на ограничение в 256 joins на сложных базах.
У меня база совсем не сложная по структуре, а 175 joins на запрос уже есть.

Гаджимурадов РустамNickDee> Вот представь

Зачем? Способов создать себе проблемы я итак больше тебя знаю.

Проблем нет, пока ты не наступаешь на ограничение.
Вот начинаешь работать с движком БД, а там - то ограничение на количество элементов в IN, то на размер стейтмента, то на размер таблицы, то на длину имени поля, то на суммарный размер всех полей в таблице.

Лично я наступил на ограничение с IN, на размер стейтмента, на ограничение длины поля. Пришлось выкручиваться.

Спрашиваешь - почему бы не изменить такое поведение? В ответ получаешь телегу как правильно писать. В том-то и дело, что писать надо так, чтобы не создавать глупых ограничений :) А если они унаследованы из чужого кода, и пользователи просят изменить ограничение пока никто не наступил, то почему это просто не сделать?

kdvNickDeeСпрашиваешь - почему бы не изменить такое поведение? В ответ получаешь телегу как правильно писать
дай вам волю, вы процедуры по 10 мегабайт писать будете.

И что конкретно тебя в этом пугает? :) Ну будут у меня стейтменты по 10 мегабайт, или по сто. Мне так удобно, и мне с ними жить :)
Почему я должен быть ограничен константой в коде? Просто потому что кто-то решил что конкретного N должно хватить на все задачи, доступные к осознанию того кто ставит этот N? :) А если некоторые задачи не подвластны его осознанию? :)

kdvNickDeeто почему это просто не сделать?
потому что ряд подобных изменений требует изменений в движке, которые могут повлиять неизвестно на что. И потому что не бывает софта без ограничений. Всегда есть какой-то лимит, и всегда на этот лимит кто-то наступит, обязательно.
Есть лимиты старые, которые можно или легко или с определенными усилиями изменить. И они меняются. Например, 36 гиг на одну таблицу, разрядность генератора, Next transaction, ... Ну растут данные, что поделать. Но есть определенные лимиты, которые выходят за здравый смысл.
Например, размер оператора. В ЯП ведь уже много лет есть правило - размер процедуры не должен превышать размер экрана (допустим, 120 строк). Почему в SQL это можно "нарушать"?

Потому что стейтменты могут быть сгенерённые. Собственно при генерации кода для триггера я и наступил на ограничение.

kdvА с IN - насколько бы тебе его увеличить хотелось? 2500? 5000? 10000? Я гарантирую, что после увеличения до 10к обязательно тут же кто то на это наступит.
Я наступил на 1500. И естественно это была автогенерация кода :) Пользователь в гриде выделял записи, и я их для групповой обработки вставлял в "where ID in (...)".
Ограничение должно быть как можно выше, и я бы не стал ограничиваться размером WORD. Пусть работает медленней, пусть противоречит чьей-то девелоперской совести, но пусть работает... это уже будет выбор того, кто это использует.

Dimitry SibiryakovNickDeeПользователь в гриде выделял записи, и я их для групповой обработки вставлял
в "where ID in (...)".
Потому что использовать для этого временную таблицу у тебя не хватило... чего?

Ты сейчас спрашиваешь о том, почему я вместо того чтобы написать простой "where ID in (...)", не создал временную таблицу, потом не сделал в неё N инсертов, а потом не написал "where Id in select from ..."? :) Ты сейчас про это спрашиваешь? :)

Dimitry SibiryakovNickDeeТы сейчас про это спрашиваешь? :)

Именно так. Только не in, а join.

если делать с джойном, то тогда лучше без временной таблицы. Мы это тут обсуждали пять лет назад: 6343890 :)
Но это настоящий изврат, правда меньший чем с инсертами :) Быстро работает, да. Но изврат :)

ТаблоидNickDeeесли делать с джойном, то тогда лучше без временной таблицы. Мы это тут обсуждали пять лет назад: 6343890 :)
Но это настоящий изврат, правда меньший чем с инсертами :) Быстро работает, да. Но изврат :)0xFF.
2 NickDee: ты там разбиваешь список ИДшников на "слова" и выдаёшь из процедуры наружу отдельные ИДшники - я правильно понимаю ?
Да.
ТаблоидЧто делает с входным блобом (IntStr) твоя УДФ CreateIntList(IntStr, ListId, Cnt) ?
Она создаёт из блоба IntStr список чисел, возвращает ассоциированный с этим списком ListId, и возвращает в Cnt количество элементов в списке.
ТаблоидИ откудова вытаскивает ID'шник вот эта штука: ValueInList(ListId, I, V) ? (ListId - это же integer, а не блоб... я слабо как-то понимаю тамошний код...)
Она вытаскивает их из списка, который ассоциирован с ListId.
Кстати Blob это же реально Int64, привязанный к данным, и имеющий методы работы с этими данными :) Вот тут по аналогии: ListId привязан к списку, и есть методы работы с этим списком.

Гаджимурадов Рустамkdv> ой, опять про выделение пользователем в гриде полутора тысяч записей....
Да на самом деле там где-нибудь "выделить все" или
выделить диапазон, а обработать нормально это дело
автору лень, нехай сервер трудится, он же железный.

Ну ты знаешь, у меня код в скриптах прописан, и достаточно сильно абстрагирован от грида.
Там (в скрипте) торчит функция, типа GetMarkedIdList: TIntegerDynArray.
С моей точки зрения именно список Id из грида и является теми данными, которые ожидает скриптовая процедура обработки, желающая обработать отмеченные записи :) Я так и реализовал.
Я эту функцию вызываю, получаю список отмеченных Id, и в скрипте пишу например такой sql-запрос: "update T set IsProcessed = 1 where Id in (' + IntListToStr(GetMarkedIdList) + ')".
Почти одной строчкой. Все шаги очевидны и понятны. А вы что предлагаете? :)

Я sql-серверу на его собственном языке говорю: поставь IsProcessed = 1, для записей у которых Id принадлежит указанному множеству значений.
Чего не так? :)

Dimitry SibiryakovNickDeeЯ эту функцию вызываю, получаю список отмеченных Id, и в скрипте пишу
например такой sql-запрос: "update T set IsProcessed = 1 where Id in (' +
IntListToStr(GetMarkedIdList) + ')".
Почти одной строчкой. Все шаги очевидны и понятны. А вы что предлагаете? :)
Две строки:


Все шаги очевидны и понятны.

Это я понимаю.
Можно, чтобы не переписывать существующий sql-код, пойти ещё дальше - распарсить sql, вытащить из него элементы IN, вставить их во временную таблицу, исправить sql на join или merge, и отдать серверу :)
Будет почти универсальный воркэраунд для IN. Но это и есть изврат :)

Гаджимурадов РустамПри чём тут скрипты и код? Пользователи как 1500
записей в гриде выбирают?

Наример так: загружают данные за период (условие в where), затем средствами devex-грида фильтруют-сортируют как им вздумается (это уже локально), затем в отфильтрованом выбирают либо инсертом (если им нужно отметить несколько записей), либо нажатием * (инвертировать выделение) с последующим деселектом ненужных записей. Дальше жмётся кнопка, которая делает определённые действия для отмеченых записей.

Гаджимурадов РустамNickDee> либо нажатием * (инвертировать выделение)
NickDee> Дальше жмётся кнопка

Ч.Т.Д.
Человеку нужны все документы за период, кроме документов менеджера Иванова, менеджера Петрова, и менеджера Сидорова, и нужно исключить документы без номера.
Он выставляет период, снимает в devex-овском фильтре по столбцу "Менеджер" три соответствующих чекбокса, ставит значение "(Не пустые)" в фильтре по столбцу "Номер", и получает на экране то, что ему нужно обработать. Это может быть как 10 записей, так и 10000.
Дальше жмёт * и жмёт кнопку обработки. Дальше ты знаешь что происходит :)
Особо обращаю твоё внимание, что локальный фильтр в devex-гриде может быть очень навороченым, настолько, что не смапится на sql-условие. А если ещё учесть, что он может быть сделан по вычисляемым на клиенте полям, то задача конвертации фильтра в sql-условие становится в общем виде нерешаемой.
Так что остаётся только список ID :)

kdvNickDee,

понял. Тем не менее, лучи ненависти можешь аналогично посылать Ораклу и Микрософту (см. предыдущее сообщение). И Микрософт тоже говорит - переписывайте на объединение таблиц.
Мда... :)
Оптимизатору есть из чего догадаться, что вместо развёртывания IN на OR-ы эффективней сделать джойн?
А можно ли сделать так, что до 1500 элементов оно работает как сейчас, а после - не падает с ошибкой, а делает виртульный джойн (если он возможен)? :)

Гаджимурадов РустамПросто это неуместный плач Ярославны и проблемы
не сервера, а тупых горе-пользователей и ленивого
разработчика, который хочет переложить проблемы
со своих плеч на сервер или кого бы то ни было.

Разработчик действительно ленив. Горе-пользователи действительно тупы. Проблемы сервера тут действительно нет :)

Почему 256 джойнов? Потому что в байте 8 бит, а восемью битами можно закодировать только 256 значений. Это не ограничение сервера, это ограничение в архитектуре байта :)

Тут dmitry недавно д'артаньяна вспоминал :)

Гаджимурадов Рустам
Вернёмся к джойнам.
Ты представляешь себе что имеет право существовать система из двух таблиц, в которой есть 500 справочников? Все справочники находятся в одной таблице... Наверняка представляешь.
А можешь себе представить вторую таблицу, в которой 500 FK на таблицу справочников (или 10 таблиц по 50 полей, но связаных друг с другом по ID 1:1)?
А можешь себе представить, что нужно селектнуть запись из таблички с 500 FK, но не просто селектнуть, а с соответствующими значениями из таблицы справочника, причём не какие-то несколько полей, а все 500?
Не можешь себе представить как у одной сущности может быть 500FK? Не было таких задач? Не представляешь кому может пригодиться сразу 500 значений? А если представляешь, то знаешь как обойти ограничение в 255 джойнов? Двумя запросами? :)
А как это должна обходить какая-нибудь ORM-система с автогенерацией SQL? Никак? А кто сделал больше 255 FK, тот идиот, и задачи у него заведомо идиотские? :) А до скольки FK он ещё не идиот? :) До 255? :)

Dimitry SibiryakovNickDeeА можешь себе представить вторую таблицу, в которой 500 FK на таблицу
справочников (или 10 таблиц по 50 полей, но связаных друг с другом по ID 1:1)?
Я уверен, что Рустам на своём модераторском веку повидал достаточно идиотов, так что
представить себе такого, который не знает как делается связь N:M, он, определённо, сумеет.

Я про ограничения FB. А ты про что? :)

Dimitry SibiryakovNickDeeЯ про ограничения FB. А ты про что? :)
А я про анацефала - проектировщика БД.

И какие цели ты перед собой ставишь, когда пишешь об этом? :) Какие насущные задачи пытаешься решить? :)