mrakkСтруктура базы предполагает наличие большого количества справочников с возможностью использования множества значений справочника для одного поля. Связь поле таблицы <-> множество значений справочника организовывается через таблицу соотвествий. Но учитывая, что справочников много, я решил не делать таблицу соответствий значений для каждого справочника и таблицы, а сделать одну таблицу для всех справочников, имеющую вот такую структуруСмысл ? В используемой Вами СУБД есть ограничение на количество создаваемых таблиц и/или отсутствует поддержка ограничений типа FOREIGN KEY ?

mrakkChAВ используемой Вами СУБД есть ограничение на количество создаваемых таблиц и/или отсутствует поддержка ограничений типа FOREIGN KEY ?организовать как можно более простую систему взаимодействия клиента с БДНаписать универсальную форму под запрос к конкретной таблице ничуть не сложнее, чем к одной таблице с фильтрацией по идентификатору справочника. При этом ссылочная целостность при этом будет контролироваться сервером, а не потенциальными ошибками в клиенте.

SERG1257Ну положим внешний ключ на это навернуть можно.
только структура будет немного другойЕсли в поле одной таблицы допустимы значения только одного справочника, то "правильный" FOREIGN KEY невозможен, так как в это поле можно будет подставить любое значение из любого "справочника". Т.е., Ваш вариант формально позволяет в поле dict_id из my_table поставить любой dict_id из main_dict относящегося к любому dict_type_id и сервер это пропустит. Поэтому корректность придется проверять дополнительным кодом, неважно триггером или процедурой. Мало того, Ваш вариант предполагает множество view, которые с точки зрения клиента, ничем не отличаются от таблиц. Т.е., в БД вместо N справочных объектов(tables) появится N(views)+3(tables), да ещё и с необходимостью дополнительных проверок. Какая-то неправильная экономия получается.

Как вариант, можно добавить в таблицу my_table еще и поле dict_type_id с ограничением типа CHECK (dict_type_id = 1) , т.е., допустимы только значения из справочника с идентификатором равным 1. После чего сделать FOREIGN KEY от неё составным типа (dict_type_id, dict_id) . Такой вариант уже лучше, так как использует штатные механизмы СУБД, но, как минимум, несколько усложняет модификацию пользовательской таблицы my_table , да и некоторая избыточность будет наблюдаться.

В случае же отдельных таблиц, ссылочная целостность гарантирована сервером без всяких дополнительных усилий, самым естественным для РСУБД способом. Таким образом, вариант с одной большой таблицей не несёт никакой практической пользы, разве только за редкими исключениями. В частности, когда есть крайняя необходимость дать пользователю возможность создавать некие новые сущности, типа новых классификаторов, и связыванию их с какими-то конкретными полями каких-то других сущностей. Более того, это подразумевает возможность и удалять "их" сущности. Т.е., фактически пользователи будут заниматься самостоятельным "перепроектированием" БД без участия специалистов. Если они такие умные, то с таким же успехом им можно выдать профессиональные инстументы и пустить в БД, пущай "проектируют", но, избави Бог, заниматься поддержкой такой БД. Есть ещё несколько вариантов, когда такой подход может быть полезен, но они лежат далеко за пределами исходной постановки вопроса.

P.S. Лично у меня, целесообразность "справочник справочников" в большинстве случаев вызывает сильные сомнения, так как практика показывает, что "вменяемых" пользователей исчезающе мало. Не в смысле умаления их умственных способностей, в своём деле это могут быть асы, а ровно на незнакомом им поле, где их "здравый смысл" может завести в тупик. Насколько мне известно, большинство инструментов, которые создавались для "обычных" пользователей, в конечном счёте всё равно используются программистами, как те же SQL и Basic. 1С тоже продвигался как конструктор, где любой пользователь бла-бла-бла, но свелось всё к тому, что появилась целая ниша для 1С-программистов, а конечные пользователи типа бухгалтеров по-прежнему путаются даже в интерфейсе. В общем, кесарю - кесарево...