#mysql #database-design
#mysql #база данных-дизайн
Вопрос:
У меня есть значение поиска «Непрочитанное». Здесь используется: Почта может быть прочитана или непрочитана. (Итак, у меня есть идентификатор 10 = прочитанный и идентификатор 11 = непрочитанный). Теперь в пользовательском интерфейсе у меня есть фильтры отображения, где я могу сортировать сообщения по предопределенным фильтрам, один из них «Непрочитанный», поэтому вопрос в следующем: идентификаторы в обоих случаях будут равны 11 или мне создать два отдельных значения для непрочитанного — одно для состояния сообщения и одно для сортировки отображения?
Использование этих данных в 2 раза:
1) Ссылка на его основное действие на основе идентификатора поиска FK
2) Отчет: если я хочу увидеть, сколько пользователей отсортировано с использованием фильтра непрочитанной почты для непрочитанной почты, в этом случае я могу легко получить это число — используя два идентификатора (по одному для каждого вопроса (состояние сообщения и сортировка отображения) или только один идентификатор?
Ответ №1:
Значение статуса прочитано / непрочитано является свойством элемента сообщения, а не графического интерфейса пользователя. Выбранное пользователем состояние фильтра является свойством пользователя, а не сообщения.
Если для вас имеет смысл использовать одинаковые значения в этих двух похожих, но независимых столбцах кода, то это нормально.
Вам необходимо сохранить состояние сообщения в виде столбца в сообщении (если вы не хотите отслеживать историю состояния сообщения, и в этом случае оно должно перейти в дочернюю таблицу сообщения). Вам необходимо сохранить текущее состояние выбора фильтра для каждого пользователя в вашей таблице user. Я не могу себе представить, почему вы хотели бы сохранить это в истории, поэтому один столбец в вашей пользовательской таблице должен сделать свое дело.
Если непрочитанное в таблице сообщений равно «11», а непрочитанное в таблице пользователей также равно «11», то это нормально, но это случайное совпадение, и вы должны быть осторожны, делая какие-либо предположения в своем коде по этому поводу. Когда вы начнете добавлять другие комбинации фильтров, вся схема может обрушиться на вас, если вы не намерены использовать совпадающие пары атрибутов в вашей таблице выбора фильтра user / gui и любые атрибуты сообщений, соответствующие вашим параметрам фильтра.
Комментарии:
1. Ну, если я использую разные, то как насчет значений поиска для выпадающих списков. Скажите, что поиск «year» для 2011. Это может быть birth_year, а также может быть company_join_date. в обоих случаях это 2011 год. Итак, я предполагаю, что в этом случае это один и тот же идентификатор, даже когда данные хранятся в разных таблицах?
2. Сначала выясните, кто научил вас присваивать идентификационные номера годам. Затем найдите их и ткните пальцем в глаз.
3. Использование идентификаторов для дат, как у вас, распространено в DBS типа хранилища данных и может быть выполнено и в транзакционных. Но стоит ли оно того? Возможно, если вы используете его для предотвращения ввода текста пользователем. Однако, если вы пойдете по этому пути, нет ничего плохого в том, чтобы иметь значение поиска (в данном случае 2011), на которое ссылается ID в 2 разных таблицах с 2 разными значениями. Контекст обеспечивает значение. Обратимся к вашему вопросу: если вы записываете значение ‘2011’ в свою базу данных в поле A, нормально ли записывать ‘2011’ в поле B? Даже если они означают разные вещи (например, birth_year и company_join_date)
4. Чтобы расширить очень хороший момент Карла, когда у вас есть атрибут, который имеет жизнь за пределами вашего бизнеса (например, номер года), вам не нужно анонимизировать его с помощью бессмысленного ключа. 2011 всегда будет означать одно и то же в столбце даты, или, если по какой-то причине нет, тогда это будет означать то, что это означает в контексте столбца, в котором находится 2011. Наличие разных столбцов не делает данные несопоставимыми. Не могли бы вы задать вопрос, кто родился с тех пор, как X присоединился к компании? Наличие одного и того же значения данных в двух местах никогда не является гарантией того, что данные означают одно и то же.