Разработка таблиц базы данных для моделей, которые совместно используют много данных друг с другом

Question

В настоящее время я работаю над приложением, которое представляет собой группу отдельных форм, состоящих из модулей. После заполнения форм они загружаются в базу данных. Каждый отдельный модуль в форме загружается в таблицу для этого модуля. Вот пример.

• Кто-то открывает форму CombustionGas (в нее вводятся тестовые данные).
• CombustionGas имеет 7 различных модулей с полями (технические данные, данные предварительного тестирования, данные теста)
• Пользователь заполняет их и нажимает кнопку для их загрузки, каждый из различных модулей загружается в таблицу со своим соответствующим именем (dbo_pre_test_data, et c), идентификатором для индивидуума Сам тест формы (в данном случае CombustionGases) используется в качестве ключа для таблицы.

Теперь это работает хорошо для большинства случаев. Тем не менее, некоторые тесты имеют одинаковые модули, но немного разные поля внутри модуля. Таким образом, если в «Pre-test data» было 9 полей, в другом тесте могут быть дополнительные 3 поля. В настоящее время мы только что добавили дополнительные столбцы в таблицу и установили их в null, если они не используются в этом тесте, но, поскольку мы создали все больше и больше тестов, эти таблицы получают большое количество неиспользуемых столбцов в них. .

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

Answer 1

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

Похоже, что "модули", такие как данные перед тестированием, на самом деле не являются вашей "базовой" единицей организации для ваших данных. Это связано с тем, что в нем есть отдельные тесты, некоторые из которых являются общими для всего модуля, другие - нет. Похоже, что каждому тесту нужна отдельная таблица с ключом, чтобы связать его с таблицей родительского модуля. В частности, тестовая таблица будет содержать записи, связанные только с конкретными c тестами. В этом случае таблица модулей будет содержать данные, уникальные для каждого модуля (только для модулей, но не для тестов, которые они содержат). Затем вы можете связать их с объединяющей таблицей ModuleTests со списком внешних ключей каждого из модулей и тестов.

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

Дополнительная информация: https://www.amazon.com/Database-Design-Mere-Mortals-Hands/dp/0321884493

Кроме того, рискуя казаться очевидным: создайте среду тестового сервера для проверки ваших изменений. Не просто изменяйте таблицы, используемые в производстве.