Дизайн базы данных: 1 таблица или 2?

Question

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

Я видел несколько других, у которых есть две таблицы

имя пользователя (или адрес электронной почты), пароль, состояние (активировано и т. Д.), Группа (администратор, владелец, пользователь и т. Д.)

и

nameFirst, nameLast, дата рождения, день рождения, год рождения и т. Д.

Каковы плюсы и минусы вышеуказанных методов?

Answer 1

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

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

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

Answer 2

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

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

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

Answer 3

Хранение информации в отдельных таблицах, если мы говорим об одном и том же «объекте» (пользователь и его дополнительная информация принадлежат друг другу), - это то, чего я предпочитаю избегать. Но я могу придумать две веские причины разделить их:

• Если вы разработали или используете отдельную систему аутентификации со своей таблицей, например, User, но вам нужно добавить дополнительную информацию. Или у вас есть стандартная система, но информация / поля для пользователя зависят от вашего клиента: имена полей, количество полей ... Тогда вы можете поддерживать стандартную часть аутентификации, а дополнительная информационная часть, как известно, является гибкой.

• Если внутри вашей модели данных у вас есть сложная модель Person/People с адресами, датами рождения, а что нет, вы можете использовать ту же таблицу для хранения этой информации и для ваших пользователей. Таким образом, у вас user будет также person_id или что-то подобное.

Надеюсь, это поможет.

Answer 4

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

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

В любом случае для получения и / или манипулирования данными из одной или двух таблиц требуется всего 1 оператор запроса.