Примечание: я видел несколько похожих вопросов о похожих проблемах;однако никто из них не ответил бы полностью на мой вопрос.
У меня есть данные экзаменов для школ.В моем наборе данных около 500 школ и около 12 предметных экзаменов (в каждой школе есть данные для каждого экзамена).Каждый экзамен имеет 6 атрибутов (столбцов).После загрузки исходных данных в базу данных никаких изменений не ожидается.Что касается SELECT запросов, я полагаю, что отдельные данные об экзамене используются так же часто, как и запросы по ряду экзаменов.Однако база данных будет использоваться веб-сайтом, визуализирующим данные, поэтому такие запросы SELECT могут выполняться довольно часто.Имея это в виду, я могу придумать три способа организации этих данных, каждый из которых создает (очевидно) таблицы BCNF.
Первый сценарий:
school
exam1_attr1
exam1_attr2
...
exam12_attr6
Эта схема кажется неправильной, хотяУ меня нет веских аргументов против этого.Как я уже сказал, мои данные не изменятся, поэтому разделение экзаменов на имена атрибутов не является большой проблемой.Однако такая настройка создаст некоторые трудности агрегирования по всему набору данных (т. Е. Результирующие запросы могут быть излишне сложными).
Вторая схема:
school
examID
attr1
attr2
...
attr6
Хотя эта схема выглядит привлекательно,Мне трудно убедить себя в том, что лучше представлять экзамены в виде значений, а не столбцов или отдельных таблиц.То есть набор экзаменов известен, конечен и окончателен, и каждый экзамен обладает точно такими же свойствами - звучит как основной кандидат на отдельную таблицу.С другой стороны, при таком расположении запросы агрегации и единичного экзамена очень чистые и понятные.
Третья схема будет идентична для 12 отдельных таблиц экзаменов:
school
attr1
attr2
...
attr6
Концептуально, я чувствую, что эта схема лучше всего отражает мои данные: каждый экзамен логически разделен на свою собственную таблицу.Однако любые запросы, требующие агрегированных данных по всем экзаменам, будут включать 12 таблиц, и это заставляет меня чувствовать себя немного неловко.
Таким образом, мой вопрос: какой дизайн базы данных будет лучшим в моем случае?Пока я ищу ответ, меня также очень интересуют причины выбора одной схемы над другой.В частности, мне интересно:
- как эффективность выполнения запросов меняется с каждым дизайном базы данных,
- насколько важна в реальной жизни простота написания запросов (учитывая, что данные будут в первую очередьиспользуется веб-сайтом - я редко пишу запросы к данным после завершения веб-сайта),
- , какой дизайн лучше, если будут учтены возможные будущие изменения в данных веб-сайта,
- будет ли ваш ответ другим, если число школ будет не 500, а 50 000.
Короче, меня интересуют любые мнения, которые помогут мне понять, почему один дизайн лучше, чемДругой.Любые теории проектирования баз данных также приветствуются.Спасибо!