Я работаю над приложением, которое принимает любые выгруженные данные CSV, сохраняет их вместе с другими наборами данных, которые были выгружены ранее, а затем выдает выходные данные (CSV или HTML) на основе выбора пользователем того, какие столбцы / значения они хотят вернуть. База данных будет автоматически расширена для обработки новых / разных столбцов и типов данных по мере необходимости. Это предпочтение модели значения атрибута сущности.
Пример - загрузка этих 2 наборов в пустую базу данных:
набор данных A:
name | dept | age
------+-------+------
Bob | Sales | 24
Tim | IT | 32
набор данных B:
name | dept | age | salary
------+-------+------+--------
Bob | Sales | 24 | £20,000
Tim | IT | 32 | £20,000
Произойдет программное изменение таблицы «данных», так что при импорте набора данных A появятся 3 вновь созданных столбца (name, dept, age). Импортирование набора данных B приводит к появлению 1 вновь созданного столбца (зарплата). На данный момент забудьте о том, должны ли наборы записей объединяться или нет, и что нормализация отсутствует.
Проблема, с которой я столкнулся, заключается в том, что некоторые столбцы также будут иметь значения поиска - скажем, что столбец Dept в какой-то момент в будущем будет иметь связанные значения, которые дают адрес и номера телефонов этого отдела. То же самое может быть верно для столбца Заработная плата, поиска налоговых групп и т. Д.
Количество столбцов в этой большой таблице не должно становиться слишком большим (несколько сотен), но будет достаточно большим, чтобы пользователь мог управлять структурой и значениями таблицы поиска через панель администратора, а не каждый раз привлекать разработчиков. .
Вопрос заключается в том, использовать ли отдельные таблицы поиска для каждого столбца (значение, описание) или комбинированную таблицу поиска, которая ссылается на столбец (столбец, значение, описание). Обычно я бы выбрал отдельные таблицы поиска, но здесь приложению нужно будет создать их автоматически (например, lookup_dept, lookup_salary), а затем добавить новое соединение в основной оператор SQL. Это будет сделано по запросу пользователя, а не при добавлении столбца (чтобы избежать сотен пустых таблиц).
С другой стороны, комбинированную таблицу поиска необходимо будет несколько раз объединить с таблицей данных, каждый раз выбирая имя столбца.
Мне кажется, что отдельные поиски имеют смысл, но я, возможно, лаю совсем не на том дереве.