Насколько важна нормализация базы данных в очень простой базе данных?

Нормализуйте базу данных сейчас.

Гораздо проще оптимизировать запросы к нормализованным данным, чем нормализовать кучу данных.

Вы говорите, что сейчас все просто — эти вещи имеют тенденцию расти. Спроектируйте его правильно, и вы получите опыт правильного проектирования и проверки на будущее.

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

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

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

Похоже, вы рассматриваете местоположение как один атрибут, включая город и штат. Предположим, вы хотите сортировать или анализировать события только по штатам, а не по городам и штатам? Это может быть сложно сделать, если у вас нет атрибута для состояния. Логически я ожидал бы, что штат будет принадлежать таблице городов, хотя это может зависеть от того, как именно вы хотите идентифицировать города.

Прямой ответ: Тот факт, что проблема относительно проста, не является причиной того, чтобы не делать что-то, чтобы сделать ее простой. Мне намного легче ходить на ногах, чем на руках. Я не помню, чтобы когда-нибудь говорил: «О, мне нужно пройти всего полмили, это небольшое расстояние, так что я мог бы идти на руках».

Более длинный ответ: если вы не храните никакой информации о городе, кроме его названия, и у вас нет предварительно заданного списка городов (например, для построения раскрывающегося списка), то ваша схема уже нормализована. Что будет в таблице City, кроме названия города? (Я предполагаю, что штат не может зависеть от города, потому что у вас могут быть два города с одинаковым названием в разных штатах, например, Дейтон, штат Огайо, и Дейтон, штат Теннесси.) Соответствующее правило нормализации - «никаких неключевых зависимостей», то есть вы не можете иметь данные, которые зависят от данных, не являющихся ключом. Если бы у вас были, скажем, широта и долгота каждого города, то эти данные повторялись бы в каждой записи, относящейся к одному и тому же городу. В этом случае вы, безусловно, захотите создать отдельную таблицу городов для хранения широты и долготы. Конечно, вы можете создать «код города», представляющий собой целое число или аббревиатуру, которая ссылается на таблицу городов. Но если нет других данных о городе, я не вижу, как это что-то дает.

Технически я бы предположил, что город зависит от места проведения. Если место проведения — «Рокфеллеровский центр», это означает, что городом должен быть Нью-Йорк. Но если место проведения не является обязательным, это создает проблемы. Одна из возможностей состоит в том, чтобы иметь таблицу «Место проведения», в которой перечислены название места, город и штат, а для случаев, когда вы не указываете место, иметь «не указано» для каждого города. Это было бы более хрестоматийно правильно, но на практике, если в большинстве случаев не указывать вену, это мало что выиграет. Если большую часть времени вы ДЕЙСТВИТЕЛЬНО указываете место проведения, это, вероятно, будет хорошей идеей.

О, и действительно ли существует связь 1:1 между мероприятием и спонсором? Я могу поверить, что у мероприятия не может быть более одного спонсора. (В реальной жизни существует множество мероприятий с несколькими спонсорами, но, возможно, для ваших целей вас интересует только «основной спонсор» или что-то в этом роде.) Но разве спонсор никогда не проводит более одного мероприятия? Это кажется маловероятным.

Почему бы не продолжить и нормализовать? Вы пишете так, как будто нормализация сопряжена со значительными затратами, которые перевешивают выгоды. Легче настроить его в нормальной форме, прежде чем вы его заполните, чем пытаться нормализовать его позже.

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

ETA: я не знаю, почему я не замечал этого раньше, но если вы действительно не хотите нормализовать свою базу данных, и вы знаете, что у вас всегда будет Отношение 1 к 1 между событиями и спонсорами, тогда зачем вам спонсоры в отдельной таблице?

Похоже, вы можете быть немного сбиты с толку тем, что такое нормализация и зачем вам это делать.

Ответ, ИМО, зависит от того, хотите ли вы предотвратить ошибки при вводе данных. Если вы это сделаете, вам понадобится таблица МЕСТОПОЛОЖЕНИЯ:

VENUES
City
State
VenueName

а также таблицы CITIES и STATES. (Примечание: я видел ситуации, когда один и тот же город встречается несколько раз в одном и том же штате, обычно это небольшие города, поэтому ГОРОД/ШТАТ не составляют уникальную диаду. Обычно для устранения неоднозначности используется почтовый индекс.)

Чтобы предотвратить ситуации, когда оператор ввода данных вводит место проведения NY NY, которое на самом деле находится в SF CA, вам необходимо проверить ввод места проведения, чтобы увидеть, существует ли такое место в городе/штате, указанном в записи.

Тогда вам нужно будет сделать CITY/STATE обязательным и написать код для отката транзакции и обработки ошибки.

Если вы не заботитесь о соблюдении такой точности, вам также не нужны таблицы CITY и STATES.

Если вам интересно узнать о нормализации, вы должны узнать, что происходит, когда вы не нормализуете. Для каждой нормальной формы (за пределами 1NF) существует аномалия обновления, которая возникает вследствие вредоносной избыточности.

Часто можно запрограммировать аномалии обновления, и иногда это более практично, чем всегда нормализовать до максимальной степени.

Иногда база данных может попасть в несогласованное состояние из-за сбоя нормализации и невозможности запрограммировать приложение для компенсации.

В вашем примере лучшее, что я могу придумать, это своего рода хромая гипотетика. Что, если название города написано с ошибкой в ​​одной строке, но правильно написано во всех остальных? Что если суммировать по городам и спонсорам? Ваш вывод будет отражать ошибку и разделять одну группу на две группы. Может быть, было бы лучше, если бы город был прописан в базе только один раз, в лучшую или в худшую сторону. По крайней мере, группировка для сводки будет правильной, даже если имя написано с ошибкой.

Стоит ли это нормализовать? Эй, это твой проект, а не мой. Вам решать