PaulWistвот я и хотел посмотреть как он собирается связать две таблы без JOIN
Хотел бы я посмотреть на постановку реальной задачи где это твоё извращение понадобится!
Если мне надо напечатать ведомость из двух таблиц,то я делаю в 1000 раз проще
При формировании ведомости используется куча полей как из f1 так из f2
- Создаём курсор уникальных значений ключа
SELECT F1 as Key ;
FROM test1 ;
UNION ;
SELECT F2 as Key ;
FROM test1 ;
INTO CURSOR keys
*UNION без ALL создаёт курсор уникальных значений - то что нам и надо, здесь же можем отсортировать по дате документа

SET RELATION TO Key INTO F1, Key INTO F1
*По полям F1,F2 разумеется нужен индекс
*Далее формируем отчёт
REPORT ...

В результате работает в 1000 раз быстрее,так как поля не надо тащить и соединять по UNION из таблиц для ведомости.
Поля по SET RELATION вытаскиваются автоматически непосредственно в процессе печати REPORT
Работает практически мгновенно.
PS.
Учиться,Учиться и ещё раз Учиться как и завещал великий Ленин, а сам подох Неучем...

tanglirПитон33в 1000 раз быстрееБазист нервно курит в сторонке
Опечатка!
Не в 1000, а в 10000 раз! :)

ВладимирМНу, так он это и показал уже. Идея заключается в том, что сначала создается специфический курсор-диспетчер, который имеет всего одно поле - ключ. Это поле формируется просто объединением по UNION ключей обоих таблиц. При этом дубли исключаются.

Затем по SET RELATION этот курсор-диспетчер связывается с исходными таблицами. Собственно, все.

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

В принципе, если отчет не содержит сложных вычислений, вполне себе нормальный способ. Правда, утверждать, что это самый лучший из возможных способов я бы не стал. Имеет как достоинства, так и недостатки. В любом случае, настаивать на том, что Join использовать не надо - глупо.
Всё верно,именно это я и хотел показать,однако должен не согласиться с тем что способ медленный.
1. Данные для формирования отчёта подтягиваются из таблиц и сразу печатаются или заносятся в результирующую таблицу.
2. Сам код выглядит проще и читабельней, за счёт чего отладка проще и ошибки минимизируются,скорость разработки выше.
В то время как JOIN работает ещё медленней,да и дров наломать легко.
Помните - Хорошая программа не имеет права на ошибку!

Dima TПитон332. Сам код выглядит проще и читабельней, за счёт чего отладка проще и ошибки минимизируются,скорость разработки выше.
А как насчет сортировки в отчете? Например есть таблица с заголовками накладных (номер, дата, код клиента, сумма) и список клиентов (код, название).
Надо вывести отчет с группировкой по именам клиентов, т.е. сортировка должна быть по названию клиента.
И как тут просто и понятно написать подготовку исходных данных без селектов с джоинами?
Питон33В то время как JOIN работает ещё медленней,да и дров наломать легко.
Неадекватный замер, т.к. ты выбираешь не все а только часть результата. Остальная часть подставляется в процессе формирования отчета, т.е. время подготовки результата состоит из двух частей - предвыборка кодов до вывода отчета и довыборка из дочерних таблиц по мере показа отчета.
А если отчет не нужен? Например для экспорта куда-либо нужна последующая обработка результата SCAN`ом или COPY TO. Померь время селекта с джоинами и твоего подхода с последующей генерацией DBF или курсора. Удивишься.
Ещё раз для "особо одарённых" кто читать не умеет:
- Создаём курсор уникальных значений ключа
SELECT F1 as Key ;
FROM test1 ;
UNION ;
SELECT F2 as Key ;
FROM test1 ;
INTO CURSOR keys
*UNION без ALL создаёт курсор уникальных значений - то что нам и надо, здесь же можем отсортировать по дате документа
Когда формируется этот Курсор ключей - можно и отсортировать по любому полю,но сами поля выбирать не нужно.
Если использовать Джопы, а потом ещё и SET RELATION,наломать ошибок, потом их выкалупывать - это закончится очередным нытьём на форуме sql.ru
Про угробленное время я вообще молчу - Kein Kommentar!

tanglirПитон33Если использовать Джо йн ы, а потом ещё и SET RELATION,наломать ошибок, потом их выкалупывать - это закончится очередным нытьём на форуме sql.ru
Про угробленное время я вообще молчу - Kein Kommentar! Ну, если после джойнов кто-то ухитряется ещё и сетрелейшен использовать... это да, это сильно
Насчёт адекватности замера (вторая часть этого поста 10989816 ) наш анонимус промолчал. Забыл ответить или просто добавить нечего?
Уже ответил на этот вопрос - ORDER BY и SET ORDER TO никто не отменял.
А на счёт SET RELATION после Джопов - это вопрос не ко мне а к тому кто рисует Джопы.
Не спорю что Джопы это часть мат. аппарата SQL, в математических задачках наверняка пригодится.
Пусть делает через джопы, тока потом не ноет что криво работает.
В прикладных бухгалтерских и складских задачах проще и понятней делать через SET RELATION.
Время надо ценить.

ВладимирМ,

SET RELATION только в одном месте, а вычислений бывает - хренова темень.
А вот если сделать все вычисления в Джопах, тогда Джопа получится ну просто Огромная.
Например надо в зависимости от признаков и типов операций делать анализ - учитывать количество и цену товара или не учитывать.
Наворотов целая туча и даю 99.9 % что прога будет меняться.
Опять ковыряться в джопах?
Гораздо проще сделать один раз SET RELATION и думать только о прикладной задаче.

Sergey SizovПитон33ВладимирМ,

SET RELATION только в одном месте, а вычислений бывает - хренова темень.
А вот если сделать все вычисления в Джопах, тогда Джопа получится ну просто Огромная.
У Вас какие-то очень оригинальные представления о джойнах. Какие еще вычисления в джонах? Не из-за этого ли Вы их так не любите? Просто готовить не умеете?
Кака обычно мен нравятся такие зантоки от сохи, которые если чем-то не умеют пользоваться, то называют это ненужным,глупым и т.д. Их тесты самые правильные, их выводы самые правильные, а все несогласные - лохи. И их нисколько не смущает вопрос - но ведь зачем то это придумано и где-то это дожно быть очень полезно. Иначе бы этим просто никто бы не пользовался.
Питон33, я сильно не прав?
Я понимаю что тебе лень читать.
Я привёл конкретный пример и ВладимирМ понял о чём речь.
Например есть задача сделать сложный репорт - некую ведомость.
Вычисления в ней зависят от значений в связанных справочниках.
Создаём курсор ключей, делаем один раз SET RELATION и не нужны ни какие Джопы.
Концентрируемся исключительно на прикладной задаче, а не на джопах!
Более того с джопами можно наступить на грабли когда значение поля в результате соединения таблиц равно .Null.
Джопы удобны в математических задачах, например при работе с массивами.
Впрочем мне всё равно как начинающий юзер Banditos собирается использовать фокспро

проходящий.Потому джойн и не нравится. Только не надо собственную неспособность понять нечто прикрывать отговорками и поливанием грязью.
1. Грязью тебя пока ещё никто не поливает,хотя всем давно известно что ты му**к.
2. Join не может нравиться или не нравиться,так как это не девушка. Может ты извращенец? Это многое объясняет
3. Если две таблицы имеют мемо поля - тоже будешь их соединять через Join? Смотри тогда не обкакайся.

tanglirПросто напомню, как всё это было...
PS. Джойны, применяемые к массивам... нечто отдалённо похожее было только у Дедала, что как бы намекает нам
Иди в counter strike играйся ебанько.