Можно ли не использовать операцию "соединение" для восстановления ссылок?

Добрый день, корифеи!
Я опять со своими дурацкими детскими вопросами. Извините и не сильно ругайтесь!
Можно ли (и в каком современном языке это можно, если в сиквеле нельзя) восстанавливать по ключевым ссылкам в каскадах таблиц нужную информацию, но не использовать при этом операции соединения таблиц?
Постараюсь пояснить смысл вопроса. Пусть имеется совокупность реляционных таблиц, в которых только цифры-коды и немного цифр "фактов". Точно, как в Кимбаловской "снежинке". Тысячи таблиц-скелетов с фактами и десяток таблиц-справочников (измерений).
Как выполнить выборки по индексу по значениям ключей так, чтобы на выходе получить результат с подменой значений ключей значениями из справочников, но так, чтобы ничего не перемножать этим нудным "джоином", а осуществлять простое сцепление таблиц?
"Старые" языки программирования имели простейшую операцию типа "сетрелейшн", которая осуществляла позиционирование в буфере на запись (или на группу записей) по значениям ключа одновременно в куче таблиц. И потому позволяла сразу же "сцеплять" таблицы, а не перемножать их. Это был как бы частный случай соединения, который выполнялся сразу же в реальном времени. И самое главное - моментально быстро!
А в современных языках такое можно делать?
Только умоляю - давайте обойдемся без нудных лекций на тему "какие плохие студенты нынче пошли - не хотят само годами в книжках копаться, а только норовят украсть чужие знания, потому и задают идиотские вопросы". Давайте не мусорить форум лекциями, а просто обсудим проблему.
Еще раз спасибо за деловые подсказки и помощь бедным студентам...

0

Для начала вопрос: что ты знаешь о физической реализации этих "нудных" джойнов и этих set relation?

PS
В конечном итоге важна не скорость "установки set relation" или "джойна" (кого она волнует), а скорость получения набора данных. Так вот, уверяю тебя, что скорость получения набора в тех старых языках (скажем, я работал с Clipper) отнюдь не была мгновенной (разумеется при нахождении БД на сети, локальное расположение мало кого интересует).

0

Сообщение от Grossmeister Для начала вопрос: что ты знаешь о физической реализации этих "нудных" джойнов и этих set relation?

Та вынужден признать, что тонкостей я не знаю, как оно внутри работает. Потому то и вынужден задавать дурацкие вопросы.

Сообщение от Grossmeister В конечном итоге важна ... скорость получения набора данных

Вот-вот. Так вот смысл вопроса именно в этом. Можно ли в принципе в онлайне получать такие выборки, если таблиц - тысячи, а записей - миллионы!

Сообщение от Grossmeister ... скорость получения набора в тех старых языках (скажем, я работал с Clipper) отнюдь не была мгновенной

Я сам лично игрался с приложениями, написанными на клиппере в 90х годах, которые в реальном времени обслуживали описанную конфигурацию таблиц. И все там просто "летало" даже на старых 486 машинках под Новелом. А что ж говорить о современных системах?
Но меня очень "продвинутые" программеры уверяют, что современные приложения будут тонуть на скелетных БД именно из-за невозможности управлять джоинами.
Опять же мой вопрос из разряда "да-нет", то есть "можно-нельзя". Меня вполне устроит, если вы мне скажете - точно можно, просто нужно будет покопаться в документации о сиквеле...
Это - так? Сиквел тоже позволяет такое вытворять, просто нужно его знать хорошо? Или это теперь в принципе не возможно?

0

ОК.
Чем отличается клиент-серверная технология от файл-серверной? При файл-серверной технологии, для того, чтобы прочитать таблицу, ее нужно было протащить целиком на клиента и уже там обрабатывать. При значительных объемах таблиц трафик получался ого-го.
В случае клиент-серверной технологии мы посылаем запрос на сервер, сервер в соответствии с запросом обрабатывает данные и возвращает на клиента только результирующий набор строк. Собственно клиент-серверная технология была придумана для того, чтобы уменьшить трафик сети. Плюс, как правило, сервер обладает бОльшими ресурсами, чем клиентский комп.
Т.е. если на небольших объемах и небольшой загрузке сети файл-серверная технология может в некоторых случаях быть быстрее клиент-серверной, то в "обычных" условиях клиент-серверная технология является превалирующей (иначе нафиг она была бы нужна).
А что касаемо того, как физически происходит соединение таблиц на сервере, то для этого в СУБД существует оптимизатор, который на основании некоторых факторов принимает решение о применении того или иного метода. Про методы можно поискать по ключевым словам nested loop, merge join, hash join. Разумеется, скорость выборки зависит от наличия "правильных" индексов, адекватной настройки сервера (скажем, выделения достаточного места под buffer cache) и других факторов (например, в Oracle для этого должна быть собрана статистика по таблицам и индексам).

PS
В реальных запросах часто бывает соединение 5, 10, а то и больше таблиц (если система достаточно большая, класса ERP). Если объем их достаточно большой, я даже не представляю, сколько времени это будет работать при файл-серверной технологии. Именно поэтому такие технологии (на том же FoxPro или Access) сохранились только для мини-БД.

0

Сообщение от Grossmeister ОК. Чем отличается клиент-серверная технология от файл-серверной?

Спасибо огромное за то, что отвечаете. Но если честно, я немного не об этом. Для меня (не смотря, что я всего лишь примитивный студент) совершенно очевидны преимущества клиент-серверной технологии.
Я видимо немного непонятно высказал вопрос. В старых языковых средствах существовало такое поняте как управляемый программером указатель. И кодер мог просто сказать "елочка, зажгись!" - т.е. указатель, стань на запись по значению ключа. И все - никаких перемножений, соединений, и прочей нудности. Причем, само собой, что под словом "запись" тут имеется ввиду очень витиеватая группа записей - каскад таблиц с пачкой записей в каждой таблице. Указатель становился одномоментно в 10 000 таблиц на 10 000 пачек записей, отфильтрованных совокупностью значений строк, каждая из которых строго соответствует индексу, открытому совместно с таблицами.
И что же получалось в итоге? Что кодер мог просто "читать" ОДНОВРЕМЕННО каждую пачечку - по 10, по 100, по 10000 записей в каждой таблице! И "сцепление" таблиц получалось АВТОМАТИЧЕСКИ - просто при выводе на экран. Это было не соединение, а сцепление таблиц. Никаких реляционных операций и соединений. А простое считывание из буфера указателя.
Вопрос - такой механизм есть в современных сиквелах? А если есть - почему же тогда все учебники рассказывают о том, что высоконормализованные БД хуже плохо-нормализованных? Ведь чем "снежинистее" схема БД (чем более она нормализована под "снежинку", скажем в 5НФ или даже ДКНФ) тем шустрее работала описанная совокупность. Потому, что соединения вообще были не нужны, а только выборки по части индексной строки. А при вводе информации обновление также происходило моментально.
Итак, можно ли моделировать описанный алгоритм в современном сиквеле?

Добавлено через 16 минут
И еще.
Я собственноручно проверял старые клипперные проги с терабайтными объемами фалов за 20 лет работы. На современных сетях они просто ЛЕТАЮТ! Потому, что каждый запрос имеет дело только с узкими фрагментами пачек записей из совокупности таблиц. И никаких соединений нет и в помине! О чем рассказывают все учебники? Зачем тут нужны соединения?

Добавлено через 2 часа 50 минут
Я вот еще о чем подумал. Вполне может быть, что просто фильрованные пачки записей в клиппере вытягиваются в буфер оперативной памяти и уже в памяти перемножаются. Поэтому и возникает впечатление молниеносности "сцепления" таблиц. Но тогда полностью аналогичное действие можно моделировать и в сиквеле.
Похоже, что в том старом приложении важно иное - пачки в высоконормализованных таблицах очень мелко фильтрованы индексом. Потому и запрос работает с очень узкими слоями таблиц. И хотя таких таблиц - тысячи, это никак не сказывается на быстродействии, потому что буфера памяти с головой достаточно для "сцепления" пачек путем соединения в одну таблицу, а затем отбрасывания из соединения не нужных по условию. Похоже, что там просто очень грамотные кодировщики работали с этими запросами.
Но если это - так, то возникает уже иной вопрос. Почему же тогда большинство классиков "коддизма-фейджинизма-кимбаллизма" рассказывают сказки о том, что мелко-посеченная совокупность таблиц типа "снежинки" плохо работает с оперативными запросами? Ведь именно оперативные запросы сводятся к очень мелким пачкам!
А соединения в буфере памяти коротких индексных пачек - это единственное, что нужно, чтобы при ответе на запросы о выборке из таблиц-фактов нужных строк заменять ссылочные значения ключей на всякие неключевые атрибуты.
В чем тогда тут прикол? Почему такое сильное противоречие, что народу приходится дополнять таблицы фактов всякими ненормаолизующими полями (наименованиями, иными атрибутами)?

0