Расшифровка ссылок в справочник - как лучше сделать?

[KKomov]

До сих пор ссылки в справочник я обрабатывал одним и тем же способом. Если в таблице есть колонка ссылок, то в запросе делается присоединение справочника и добавляется колонка расшифровок.

Код: Выделить всё

SELECT T.TYPE, TYPES.TYPENAME
FROM TABLE T, TYPES
WHERE T.TYPE=TYPES.ID

Здесь поле TYPE - ссылка в справочник TYPES, добавляется поле TYPENAME - расшифровка.

Недавно я начал прокручивать такую мысль: а не создаёт ли такой "прямолинейный" способ расшифровки лишнего трафика? Если в справочнике мало записей, но расшифровки длинные, а запрос выбирает много записей - это ж получается раздувание данных.

Не лучше ли перенести расшифровку на клиент? То есть, перекачать справочники заранее, а затем выполнять расшифровку при отображении данных.

Приходит в голову, как это можно было бы сделать. Например, сделать вычислимое поле TYPENAME в датасете, а в обработчике вычисления заглядывать в справочник.

Делал ли это кто-нибудь? Как это лучше сделать? Можно ли задействовать ClientDataSet для хранения справочника? У кого есть практика, раскажите пожалуйста.

[kdv]

запрос, кстати, фиговый, с точки зрения FB 2.0 и вообще использования алиасов. У TYPE алиас используется, а для TYPES нет.
я понимаю, что это пример, но пример написанный впопыхах показывает используемую практику. Правильно так

Код: Выделить всё

SELECT T.TYPE, TN.TYPENAME
FROM TABLE T, TYPES TN
WHERE T.TYPE=TN.ID 

насчет вопроса - непонятно в каком смысле "лишний трафик".
и также непонятно, идет речь о справочниках вообще, или об "универсальном" справочнике куда скинуто несколько разных справочников?

Вообще, посмотри статью
www.ibase.ru/devinfo/joins.htm

и представь, как бы ты те же самые join-ы делал если бы справочники клиентов и товаров были "загружены" в клиентское приложение. Ужас.

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