Вопрос проектирования базы данных MySQL - PullRequest
1 голос
/ 10 мая 2010

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

У меня есть пользователи моей системы, у которых есть только несколько обязательных элементов (имя пользователя, пароль). Затем они могут предоставить много дополнительной информации. Эта дополнительная информация продолжает расти по мере роста системы, поэтому я хочу сделать это таким образом, чтобы добавить новую дополнительную информацию было легко. В настоящее время у меня есть отдельная таблица для каждого элемента информации. Например, есть таблица с именем 'names', которая содержит 'user_id', 'first_name' и 'last_name'. Там есть «адрес», «род занятий» и т. Д. Вы получаете смещение.

В большинстве случаев, когда я общаюсь с моей базой данных, я ищу только пользователей с одним определителем (имя, адрес и т. Д.). Однако бывают случаи, когда я хочу посмотреть, какую информацию установил пользователь. Например, страница «Изменить учетную запись» должна выполнять запросы для каждой необходимой информации.

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

Заранее спасибо.

Ответы [ 4 ]

3 голосов
/ 10 мая 2010

Вы используете объединения для связывания таблиц, поэтому у вас остается только один запрос.

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

3 голосов
/ 10 мая 2010

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

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

1 голос
/ 24 августа 2014

В настоящее время я читаю книгу «Проектирование базы данных для простых смертных: практическое руководство по проектированию реляционной базы данных (3-е издание)», и в книге конкретно упоминается этот момент.

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

1 голос
/ 10 мая 2010

Вы можете использовать просмотров для создания комбинированных запросов.

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