дано: 1с-диалект sql, ВТ разрешены.
есть одномерная ВТ tt1 с полем val разрядности N, представляющая собой множество X (пусть, например, это будут натуральные числа)

результатом нужно получить множество перестановок элементов множества X

в случае, когда N заранее известно, всё понятно, декартово с условиями. а как быть, если N заранее неизвестно? можно ли построить универсальный запрос для данного случая?

(0)Что?

можно
cross join

(1) где?

(2) в 1с разве есть такое?

(0) То, что факториал быстро растёт - тебя не смущает?

(5) нет. задачка не прикладная

(4) ты не поверишь!
:)

(7) тьху, извиняюсь, протупил. я ж про декратово и говорил


однако: N - неизвестно!

во избежание недоразумений уточню:
под "1с-диалект sql" я подразумеваю язык запросов 1с v8

(9) можно пример таблички со значениями? в сабже слова все знакомые, но чего надо так и не понял.

(10) ну, допустим, мы знаем, что N = 5

тогда мы можем составить такой запрос:


select
1 as val
into tt1
union select 2 union select 3 union select 4 union select 5

;

select
tt1.val as val1
,tt2.val as val2
,tt3.val as val3
,tt4.val as val4
,tt5.val as val5
from
tt1
,tt1 as tt2
,tt1 as tt3
,tt1 as tt4
,tt1 as tt5
where (tt1.val<>tt2.val) and (tt1.val<>tt3.val) and (tt1.val<>tt4.val) and (tt1.val<>tt5.val)
 and (tt2.val<>tt3.val) and (tt2.val<>tt4.val) and (tt2.val<>tt5.val)
 and (tt3.val<>tt4.val) and (tt3.val<>tt5.val)
 and (tt4.val<>tt5.val)


но для другой разрядности множества он уже не сгодится

(11) А не дал ли ты тем самым ответ на свой вопрос о существовании универсального запроса?

(12) т.е. твой вердикт отрицательный?

(13) У тебя по синтаксису SQL в select должны торчать все колонки. А их у тебя - переменное число N.

ну как минимум можно текст запроса составлять по значению N ))

(15) Тогда в (11) было бы решение. Но раз ТС говорит "не сгодится" - значит, нельзя.

(16) он не думал в это время о динамическом sql.

(17) не-не-не, никаких сферических коней. попробую ещё раз объяснить, по-другому.

представь, что перед тобой консоль запросов, и дан справочник X с заранее неизвестным числом элементов. тебе нужно вписать текст запроса, чтобы он, независимо от поступишего содержимого этого справочника, выдал мн-во перестановок эл-тов этого справочника

(18) Ну так ты и натыкаешься на то, что количество колонок в select - фиксировано.

Однако возникает вопрос - а как представлена перестановка в таблице? Тут ведь возможны варианты. Например, можно запихнуть их все в таблицу с тремя колонками
НомерПерестановки НомерЭлементаВПерестановке Элемент

+(19) (Но легче от изменения представления не станет. IMHO)

(19) мы начинаем выходить на правильную дорогу :)

(20) ну почему же. мы избавились от технический неразрешимости. осталась логика

(19) только структурно правильнее будет, наверное, так:
НомерПерестановки  Перестановка(влож. таблица с НомерЭлементаВПерестановке ЭлементМножества)

по моему язык запросов 1с слишком убог для таких задач

(23) "Предполагая декартово произведение ассоциативным, а таблицы - находящимися в 1НФ..." - по барабану :-)

(24) в этом вся соль ;-)

(25) "ассоциативным" <- "ассоциативным и коммутативным"

На самом деле (23) неприятно тем, что отбросит алгоритмы, в которых номер перестановки будет существенно использоваться для её порождения.

(0) cross join  не подходит?

(25) это будет больше соответствовать условиям: в результате будут именно перестановки, а не их части.
(27) но для "лиха беда начало" можно пока и не заморачиваться с (23)

(29) А вот после того, как построишь - группируй, как тебе угодно.

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

(30) "Сможешь на 1СQL построить начальный отрезок натурального ряда?"

ты про это?

select
0 as val
into tt1
union select 1 union select 2 union select 3 union select 4 union select 5 union select 6 union select 7 union select 8 union select 9

;

select
tab1.val+1+10*tab2.val+100*tab3.val as val
into num_tab
from
tt1 as tab1, tt1 as tab2, tt1 as tab3
where (tab1.val+1+10*tab2.val+100*tab3.val<=&Размерность)
index by val

(31) че нужно получить?

(31) Не годится. Произвольный отрезок так не соорудишь.

Теперь о перестановках.
Любой из реляционных операторов даёт таблицу размером не более чем произведение размеров исходных таблиц.
Факториал же растёт быстрее любого полинома.

(32) все условия - в (0)

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

(34) только динамическим текстом запроса.

(33) что значит "произвольный" в твоём понимании?

на крайняк, можно договориться, например, что N<MAX_N, задаваемого в параметрах

(36) Если "можно договориться" - то в (11) решение твоей задачи.

В противном случае в (33) - математически строгое доказательство того, что запроса, решающий задачу (0) - не существует.

(37) нет. условия "на входе мн-во размерности не более 1000", и "на входе мн-во размерности 100"  - это две большие разницы

(38) Нет разницы.
Строишь решение для 1000 (это и будет твой универсальный запрос) - а потом обрезаешь лишнее при помощи where.

Если же никакого MAX_N не предусмотрено, то задача из (0) - неразрешима.

+(38) *мощности

(40) Я так и понял. Всё равно (39).

(39) хорошо, что-то мы заговорились не туда. неправильно.
я имел в виду именно так, пусть N<MAX_N, задаваемого в параметрах.
т.е. при написании запроса мы не знаем, что там - в MAX_N, но знаем, что оно, вероятно, может быть достаточно велико, чтобы (39) не прокатило

эту договорённость можно считать сугубо в угоду незагромождения памяти сверхбольшими таблицами, т.к. всё равно понятно, что при прикладном решении  размерность всё равно ограничена физическими параметрами ЭВМ.

(42) Всё равно от (33) ты никуда не денешься. Факториал обгонит любой полином.