В базе данных с главной таблицей связано много таблиц-справочников, которые имеют одинаковую структуру (рис. 1 в аттаче). Не будет ошибкой, если я все справочники помещу в одну таблицу и сделаю такую связь, как на рис. 2? Соответственно в этом случае справочники буду разделять по полю Flag в таблице all_table.
Второй способ кажется привлекательнее, т.к. в этом случае сокращается число таблиц.

Использую СУБД Firebird 2.

ChAА смысл ? Как я понимаю, у вас отдельные сущности, ссылочная целостность будет легко контролироваться стандартным функционалом СУБД.

В каждом из справочнике, который я хочу создать, будет не более 20 записей. И я так подумал, что «плодить» кучу справочников в базе данных это не есть хорошо (ведь же лучше иметь 1 таблицу чем 20 однотипных). Но вот с другой стороны, снизится ли производительность клиентского приложение при работе с базой данной при 2-ом способе реализации?

Bogdanov Andrey
А чем в СУБД Firebird привлекательно сокращение числа таблиц? Какие выгоды от этого?
Первое, и самое главное, это удобство работы с базой данной.
А вот насчёт остального, честно, не в курсе.

ChAДа хоть по 2. Никаких преимуществ в "стаскивании" разнородных, скорее всего, по смыслу данных лично я не вижу. Только недостатки. И главный из них в том, что вещи, которые уже реализованы в СУБД на уровне ядра, вы будете вынуждены реализовывать сами. Например, ту же самую ссылочную целостность. Зачем усложнять себе и другим жизнь ?

ОК! Спасибо большое. Последую вашему совету и сделаю всё "классическим способом"

Теперь-то после такой дискуссии понятно как нужно делать правильно – все справочники однозначно буду размещать в отдельных таблицах.
Спасибо всем за ответы!

В продолжение темы.

Сделал я справочники, связал их с главной таблицей (рис. в аттаче). Когда начал делать клиента, столкнулся с тем, что несколько неудобно работать с lookup полями, да и запросов к базе данных при работе клиента с базой получается многовато. Поэтому пришла мысль убрать все внешние ключи, и заменить их на поля типа varchar(100). Вопрос: стоит ли это делать?

В продолжение темы.

Сделал я справочники, связал их с главной таблицей (рис. в аттаче). Когда начал делать клиента, столкнулся с тем, что несколько неудобно работать с lookup полями, да и запросов к базе данных при работе клиента с базой получается многовато. Поэтому пришла мысль убрать все внешние ключи, и заменить их на поля типа varchar(100). Вопрос: стоит ли это делать?

В проектируемой мною базе данных получается, что атрибуты объекта «книга» связаны с помощью внешних ключей со справочниками. Соответственной на текущем уровне разработки у меня в главной таблице хранятся id (тип integer) атрибутов книги (издательство, жанр, назначение, рубрика и т.д.), а сами атрибуты хранятся в отдельных справочниках (см. предыдущий рисунок в конце 1-ой страницы этой темы).
Может лучше все атрибуты хранить в одной (главной) таблицы (т.е. все поля типа integer заменить на поля типа varchar)? Рисунок ниже.

ChA beresaМожет лучше все атрибуты хранить в одной (главной) таблицы (т.е. все поля типа integer заменить на поля типа varchar)?Зачем ? Такой вариант имеет право на жизнь, но не часто. Во-первых, резко увеличится объем физического пространства, отводимого под информацию на каждую книгу. Может сильно упасть эффективность операций поиска, так как операции сравнения строк будут дольше, чем идентификаторов, обычно представляющих разновидность целых чисел. Кроме того, при выполнении поиска может понадобится больше обращений к диску, что является самой "дорогой" операцией. Кстати, из-за этого же упадет эффективность индексов по таким полям, если таковые будут сделаны.
А если вы еще и от справочников откажитесь, то начнете просто терять информацию. Например, при удалении последней книги определенной рубрики, сама рубрика тоже исчезнет, и в следующий раз, при появлении книги, относящейся к такой рубрике вы должны будете указать заново (и, что важнее, правильно) эту рубрику.
В общем, опять вырисовывается куча недостатков и ни одного явного достоинства. А, самое главное, большинство современных СУБД прекрасно работают со схемой "снежинка" (главной таблицей, окруженной справочниками) которую вам уже рекомендовали.

ChA, спасибо большое за столь подробный ответ. Если буду в Москве, с меня пиво :-)

И у меня снова вопросы по поводу справочников:
1) хотелось узнать, какими лучше сделать правила обновления и удаления записей главной таблицы, связанных внешним ключом со справочниками? (я поставил при обновлении – CASCADE, а при удалении - SET NULL).
2) в клиенте для получения значения атрибутов, которые хранятся в справочниках, думаю использовать не lookup-поля набора данных, а поля непосредственно справочников, полученные в результате запроса:
Такой подход верен?

И ещё, чтобы получить значения всех атрибутов главной таблицы, придётся делать приведенный выше запрос. Смущает, конечно, большое число внутренних левосторонних объединений. Не сильно ли это будет нагружать сервер баз данных и тормозить работу клиента?

ChA , большое спасибо вам за подробные ответы!
Теперь-то мне становится понятным как правильно нужно всё делать! :-))