Сериализация данных в едином текстовом поле - слишком далеко зашла денормализация? - PullRequest
0 голосов
/ 05 января 2011

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

Предположим, я создаю таблицу под названием "Home", в этой таблице есть текстовое поле с именем"номера".В этом поле находятся сериализованные данные для набора комнат, которые есть в этом доме.Моим первым побуждением было, конечно, нормализовать эти данные в отдельной таблице «Комнаты».Однако из-за некоторого разочаровывающего опыта работы с чрезмерно нормализованными базами данных в прошлом я перестал задавать себе несколько вопросов:

  1. Нужно ли мне когда-нибудь находить определенную комнату?
  2. Будет лиМне когда-нибудь нужно обновить отдельную комнату?
  3. Будут ли какие-либо записи Домашней записи когда-либо делиться записями комнаты?

Ответ на каждый из этих вопросов "нет".Все записи номеров уникальны для каждого дома.Запросы никогда не нужно выполнять, чтобы выяснить, например, сколько домов в базе данных имеют ванные комнаты.Данные всегда будут извлекаться с точки зрения дома.Количество спален и ванных комнат будет явно сохранено в записи Home для поиска.

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

Это имеет для меня большой смысл, но я надеюсь на проверку вменяемости.Спасибо за любой вклад!

Ответы [ 4 ]

3 голосов
/ 05 января 2011

Что ж, у вас может не быть необходимости СЕГОДНЯ запрашивать, чтобы узнать такие вещи, как:

  • Каково среднее количество ванных комнат в доме в Огайо?
  • Где дома имеют больше спален? Восточное побережье или западное побережье?
  • Как цена дома соотносится с размером главной спальни? Какова будет средняя доходность в долларовом эквиваленте при увеличении размера главной спальни на 30%?

и т. Д. И т. П.

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

Плюс, с отдельной таблицей ROOMS вы сможете добавить дополнительные поля комнаты, которые имеют смысл позже (такие как ширина / высота, цвет, уровень пола и т. Д.), Что было бы очень сложно, если бы данные были просто скопированы в одно поле.

Люди захотят сделать запрос неожиданным образом, например:

  • У меня плохие колени. Можете ли вы перечислить дома с главной спальней и главной ванной на первом этаже?

Как правило, наличие таблицы ROOMS сделает ваше приложение более мощным и простым в использовании.

Эй, я понял, что вы говорите о "чрезмерно нормализованных данных". Мы все были там, и это кусает. Однако наличие таблицы ROOMS в базе данных с информацией о жилье не является "чрезмерно нормализованным". Это просто правильное построение приложения.

3 голосов
/ 05 января 2011

Прагматичный ответ ...

  • а) вероятность того, что вы захотите разложить его в будущем
  • б) выгода от того, чтобы не делать этого сейчас
  • в) стоимость изменения схемы в дальнейшем.

Если a * c > b, то вам следует разложить сейчас.

1 голос
/ 05 января 2011

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

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

0 голосов
/ 05 января 2011

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

«Постоянное объединение» не так сложно сделать, но если это так, вы можетевсегда делайте вид для этого, и все готово.

...