1. В первую очередь, если имеется n-е количество справочников, для которых специфицировано общее поведение, то естественно сделать компонент "справочник", куда это поведение по возможности запихать. И где его, если захочется, можно легко переделать. Если нужны лукап-поля - никто не мешает унаследовать этот компонент от соответствующего датасета. Заодно в него можно будет класть дополнительно потребную информацию.

2. Кэширование справочников - вещь в принципе правильная. Открывать сразу все - вещь в принципе неправильная. Разгонять один и тот же справочник в кучу компонент на куче форм - вещь еще более неправильная. По идее, нужно открывать при первом обращении, как и сказал Дмитрий. Кроме того, в какой-то момент потребуется усложнить себе жизнь ради работы с большими справочниками.

3. И вообще, привыкните, как только натыкаетесь на то, что делаете задачу, которую уже решали - пора писать стандартное решение, которое сведет эту задачу к одному вызову.

LelikBolek softwarer..Разгонять один и тот же справочник в кучу компонент на куче форм - вещь еще более неправильная. ...
Информация о категории вывводится на половине форм, то что, в каждой из них ложить датасет со справочником категорийи там открывать его ?
Наверное, я недостаточно четко сформулировал. Как раз описанное Вами и названо "еще более неправильным". Если есть "устойчиво одинаковый объект", он должен присутствовать в одном месте и использоваться - во всех остальных, это азы программирования вообще.

LelikBolekДжойинть в запросе для представления - можно,
И нужно.

LelikBolekно не проще и не быстрее ли будет один уже окрытый к тому моменту датасет использовать для lookup поля?
Не уверен насчет "проще и быстрее" - поскольку последние лет восемь рекомендую побыстрее отвыкать от использования lookup полей. Быстрее пожалуй таки join-ить, проще - наверное lookup поля.

Загружать миллион записей клиенту - не факт, что правильно. Тут уже надо смотреть по логике работы пользователя, что ему в итоге дешевле обойдется. В идеале должна быть некая внутренняя логика кэширования, наподобие идеи SoftReference в Java.

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

Как дорабатывать базу - вопрос к конкретной СУБД. Например:


и регионы можно будет найти весьма быстро.

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

Но есть еще один интересный вопрос. Допустим, Вы засосали этот миллион записей (или полмиллиона из миллиона). Отработали и пошли дальше. Вопрос: оправдано ли тратить память на этот справочник? Когда он в следующий раз понадобится?

ОдинПо сути согласен, но у меня эмпирическое правило 4-х раз.
Разумеется, вопрос о точном расположении границы каждый решает для себя.

ОдинПросто я очень не люблю писать универсально-стандартные решения.
С моей точки зрения, правилен следующий критерий: не нужно ставить задачу писать универсальное решение. Оно должно вырастать из практики, из нежелания повторять некоторую работу (и видимого пути автоматизировать это решение раз и надолго). В то же время, разрабатывая прикладной код, нужно иметь нацеленность на поиск кандидатов, на отсутствие тупого повторения.