Вопрос дизайна базы данных - поле или новая таблица + один ко многим

Question

Я проектирую базу данных для сайта управления событиями - там есть таблица мест и таблица событий. Каждое событие находится в месте (хранит идентификатор места), и каждое место находится в городе. Должна быть предусмотрена возможность поиска события по городам, если город является полем в таблице мест проведения мероприятий (что может привести к дублированию городов из-за ошибок в написании) или должна существовать таблица городов (каждый с идентификатором и именем) и таблица один-ко-многим, связывающая города с местами проведения (cityid, venueid)?

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

Заранее спасибо

[РЕДАКТИРОВАТЬ] @tvanfosson: Изменено со многих ко многим на один ко многим, поскольку каждое место связано с одним городом.

Answer 1

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

Возможно, вам следует указать не только город, но и штат (чтобы вы знали, в каком Спрингфилде находится место проведения мероприятия).

Answer 2

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

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

Примечание: вероятно, нет "правильного" ответа, поскольку он сильно зависит от ваших обстоятельств.

Answer 3

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

Answer 4

Если я правильно понимаю вашу ситуацию, стол с городом является обязательным, включая штат. Вы можете добавлять новые города / штаты по мере необходимости (перед добавлением проверьте наличие в таблице). Это будет намного эффективнее и позволит избежать дублирования, но с ошибками названий городов.

Answer 5

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

Answer 6

Переведите отношения «многие ко многим», связывающие города и места, с отношением «один ко многим» с помощью дополнительной таблицы (что-то вроде venue_city), где вы можете сохранить все объекты для каждого города, а затем связать событие таблицы и таблицу venue_city. сохранение идентификатора venue_city в табличном событии.

Answer 7

Возможно, стоит рассмотреть вопрос об использовании таблицы адресов с колонкой города.

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

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