Дизайн базы данных: столбцы с двойным значением - PullRequest
0 голосов
/ 04 октября 2010

возможно, название вопроса не очень хорошо описывает мою проблему, но вот оно:

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

+ title
+ author
.
.
.
+ status [choices : ('draft', ..., 'translate')]

Искажем, в моем бизнес-процессе я публикую на своей веб-странице статьи, в которых есть [status = 'translate']

. Это правильное дизайнерское решение добавить еще одно поле:

+ read [bool] 

к моемутаблица означает, что статья готова к публикации, или это плохой дизайн, потому что я могу проверить состояние == 'перевести' для этого, и новое поле будет просто дубликатом ??

я надеюсьчто мой вопрос ясен, и заранее спасибо.

Ответы [ 5 ]

2 голосов
/ 04 октября 2010

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

Вот хорошая цитата, чтобы помнить, что:

каждый неключевой атрибут

"должен содержать факт о ключе, весь ключ и ничего кромеключ, помогите мне, Кодд ".

(это также из вики)

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

1 голос
/ 04 октября 2010

Дублировать.Если вы можете обойтись без столбца, не используйте его.

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

(и, конечно, заменить строки состояния на числовые значения).

Удачи.

1 голос
/ 04 октября 2010

Плохой дизайн.

Во-первых, у вас есть поле, которое в основном является текущим состоянием механизма состояний.

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

0 голосов
/ 05 октября 2010

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

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

Потеря времени - это та, которая больше всего беспокоит программистов.Но здесь проблема становится более тонкой.Иногда «вредная избыточность» приводит к экономии времени, а не к его потере.Чаще всего это приводит к дополнительному времени при обновлении, но экономит время при поиске.Зачастую экономия времени или потери являются тривиальными, и поэтому так же, как и проектное решение, с точки зрения скорости.

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

0 голосов
/ 04 октября 2010

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

Однако для этогоВ конкретном проекте я бы поместил состояния в таблицу и имел бы столбец IsReady в таблице состояний.Затем вы можете добавить различные состояния, которые все IsReady.Я использовал подобные конструкции много раз, когда определенные состояния эквивалентны для некоторых операций, но не для других.У каждого есть флаг.В моем конкретном случае многие партии в разных штатах было разрешено считать «успешными» для целей среднего времени / производительности, но партии, которые были полностью успешными, но были позже аннулированы, не считались «успешными» и т. Д.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...