Эта тема подробно обсуждалась в течение последних пятнадцати лет в рамках темы «Одна таблица истинного поиска» (сокращенно OTLT). Преимущества такого подхода выпрыгивают из базы данных новичка. Недостатки появляются со временем. Смотрите эти ссылки для недостатков OTLT:
Или поиск для OTLT, чтобы найти больше обсуждений.
Если вы создаете много справочных таблиц и множество экранов обслуживания для них, вы можете создать представление, которое имитирует OTLT, создав гигантский UNION, который включает в себя каждый код, каждое описание и имя таблицы, в которой находится описание кода пара сохраняется.
Можно создать такой союз, используя полуавтоматические методы, если вы знаете, что делаете. Я полагаю, что полуавтоматические методы позволят вам создать единый экран обслуживания для сотен справочных таблиц, а затем поместить некоторую логику между этим экраном и таблицами, которые вставят новый код в правильную таблицу.
Что касается того, чтобы позволить пользователям вводить новый код ТИПОВ, а не просто новый код ЗНАЧЕНИЯ, который открывает целую большую банку червей. Смотрите выше статью, обсуждающую EAV. Это очень соблазнительно, потому что позволяет пользователям создавать свою собственную структуру данных. Если вы игнорируете производительность, это работает довольно хорошо некоторое время. Вы получаете совершенно общую базу данных без необходимости изучать структуру данных у пользователей или специалистов в данной области.
Когда он сталкивается с настоящим горем, это когда вы пытаетесь использовать данные, как если бы они были интегрированной базой данных, а не просто мешаниной разрозненных мнений о данных. На этом этапе вы столкнулись с серьезной археологией данных, когда ваши клиенты ожидают регулярного создания отчетов. Удачи.
(отредактировано, чтобы заменить «интеллектуальный анализ данных» на «археология данных»)