Создать еще одну таблицу, чтобы сохранить несколько вариантов?

Question

Я создаю базу данных с различными таблицами.Давайте возьмем пользовательскую таблицу, например.Он имеет такие поля, как семейное положение и системная роль.Каждое из этих полей имеет предопределенные параметры.Имеет ли смысл создавать две новые таблицы для каждого из этих полей, поэтому, когда пользователь добавляется в систему, можно сделать выбор для выбора, например, одинокий, женатый, разведенный?Это кажется немного излишним с точки зрения одного дополнительного запроса.Это лучший способ сделать это или у меня есть другие варианты?

Answer 1

Я бы определенно создал отдельные таблицы для хранения доступных опций для этих различных столбцов.Это хорошая вещь, которую нужно сделать, если идет нормализация, и она также избавит вас от головной боли в будущем, когда вам нужно добавить, удалить, отключить или изменить любой из параметров.Кроме того, если вы не создадите отдельную таблицу и не заполните значения непосредственно в пользовательской таблице, вам может понадобиться сделать что-то вроде select distinct RelationshipStatus from User, чтобы получить доступные параметры, что не так эффективно, как выбор 10 или сколь угодно многозначения из отдельной таблицы.

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

User
----
ID
RelationshipStatusId
...other columns


RelationshipStatus
------------------
ID
Value
Description

Answer 2

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

mysql> DESC Classes;
+-------+-----------------------+------+-----+---------+-------+
| Field | Type                  | Null | Key | Default | Extra |
+-------+-----------------------+------+-----+---------+-------+
| id    | int(11)               | NO   | PRI | NULL    |       |
| dept  | char(4)               | NO   |     | NULL    |       |
| level | enum('Upper','Lower') | NO   |     | NULL    |       |
+-------+-----------------------+------+-----+---------+-------+
3 rows in set (0.00 sec)

mysql> SELECT * FROM Classes;
+----+------+-------+
| id | dept | level |
+----+------+-------+
| 10 | MATH |       |
+----+------+-------+
1 row in set (0.00 sec)

mysql> INSERT INTO Classes VALUES (11, 'ENG', 'Upper')
    -> ;
Query OK, 1 row affected (0.00 sec)

mysql> SELECT * FROM Classes;
+----+------+-------+
| id | dept | level |
+----+------+-------+
| 10 | MATH |       |
| 11 | ENG  | Upper |
+----+------+-------+
2 rows in set (0.00 sec)

Answer 3

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

Если ваши предопределенные условия для семейного положения: женат, холост и разведен, я бы просто сохранил один символ, такой как: M, S и D, и предоставил бы эти опциив DropDown с фиксированными значениями.

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

Хотите развестись

Женат, но живу один.

Для пользователяРоль также, я бы сделал что-то вроде этого:

A - Администратор P - Опытный пользователь R - Ограниченный пользователь G - Гость

Если вам нужно что-то более сложное, я не буду создавать дальшетаблицы.

Answer 4

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

Answer 5

Ради дизайна, создайте другую таблицу (что вы не хотите делать) с правильным PK.Это даст дополнительную выгоду для экономии места, потому что представьте себе 10000 регистров со словом «замужем» на них.

Также альтернативой является использование в вашем приложении «словаря», сохраняющего в структуре и Id и значение, например:

Id   Marital Status
 1   Married
 2   Single
 ..  ......

Та же таблица, но небаза данных, но в приложении, в жестком коде, сериализовано или во внешнем файле.