Реляционная база данных с базами данных для статуса и типов

Question

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

Существует «нормальная» база данных с информацией о пользователе и бизнесе. Для «типов» в этой базе данных, например, user, существует таблица в двух отдельных базах данных, а именно: status и types.

Статус для пользователя - это просто имя и описание (например, активные или удаленные).

Тип для users не совсем ясен для меня, но таблица состоит из имени, описания, подмножества и поля уровня.

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

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

Answer 1

такие пользователи могут быть новичками, поэтому вы можете решить, проверен ли ваш статус пользователя в коде, например, когда вы входите в систему, если у вас есть запрос: where status = 'active' или вот так, чтобы в этом случае вам не нужна таблица и пользователь статус - это статические значения, которые вы можете включить в свой исходный код, также вы должны рассмотреть язык для этого состояния, если ваша система поддерживает несколько языков. то же самое с полем типа.

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

Answer 2

Я думаю, что ваш вопрос охватывает два различных аспекта:

1) единство и целостность данных - ссылок на данные из других таблиц, которые могут или не быть в той же базе данных

2) нормализация - мне нужен статус и типы в других таблицах, или они могут быть включены в одну и ту же таблицу?

1) Если вы не работаете с огромными данными (не менее десятков миллионов записей), я бы рекомендовал реплицировать таблицы status и types в «нормальную» базу данных. Это особенно рекомендуется, если данные из них редко меняются.

Это позволяет применять ссылочные ограничения (FK), а также иметь более быстрый JOIN s.

2) Несмотря на то, что добавляет некоторую сложность (за дополнительную таблицу, задающие ограничения и т.д.), то, ваши данные нормализованы может принести некоторые важные преимущества:

• гибкость - если статус или тип добавляется, он просто означают простую вставку в таблице

• таблицы меньшего размера - таблица users хранит только некоторые идентификаторы для статуса и типа, а не строки или значения для угадывания (например, 0 - неактивные, 1 - активные и т. д.)

• упрощенное обслуживание - имя типа изменяется? Просто обновить запись в таблице

нормализованной структуры обычно говорят сами за себя, если должным образом продуманы (PKs, ФКС, проверочные ограничения и т.д.), а также обеспечить разделение проблем (возможно, вы реализуете конструктор для пользовательских типов в какой-то момент в будущем)

Обычно разделение базы данных должно быть сделано на основе вида деятельности:

• оперативные (много INSERT с, UPDATE с, DELETE ы подле SELECT с)
• отчетности (в основном SELECT s)
• ETL назначения - тяжелые INSERT с, UPDATE s и т.д.