Концепции дизайна базы данных

Question

Я только начал проект и мне нужно немного подтолкнуть в правильном направлении. Вот моя структура таблицы:

users         departments     sub-departments
-------       -------         -------
id            id              id
name          name            name
email
password
created
modified

posts         photos        profiles
-------       -------       -------
id            thumbnail     id
content       large         photo_id
created       created       user_id
user_id       profile_id    department_id
profile_id    id            sub-department_id

В таблице профилей есть еще около 5 полей, которые не имеют значения. Если что-то из этого выглядит немного не так, вероятно, так и есть.

users have one department
users have one sub-department
users have many posts
users have one photo
users have one profile

Что я «хотел» сделать, так это создать все необходимые мне таблицы и собрать их все вместе в таблице профилей с использованием внешних ключей. Фрагмент CakePHP моей модели профиля выглядит так:

var $belongsTo = array('User', 'Department', 'Sub_Department', 'Photo')
var $hasMany = array('Comment');

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

Я все еще новичок в ERD и CakePHP. Должен ли я объявить все, что принадлежит пользователю и по моему запросу ProfilesController оттуда, как $ this-> Profile-> User-> find ('all', array ('contains' => ....));

Я немного растерялся на этом этапе. Любая помощь будет оценена. Как бы вы это реализовали?

Answer 1

Вы сказали:

• пользователи имеют один отдел
• пользователей имеют один отдел
• пользователей имеют много сообщений
• пользователи имеют одну фотографию
• пользователи имеют один профиль

Забавная терминология ... пользователи работают в одном отделе и, фактически, работают в одном подразделении. Поскольку, по-видимому, подразделение является частью только одного отдела, вам не нужно регистрировать как отдел, так и подразделение в таблице профиля. На самом деле, если вы делаете запись обоих, у вас есть сложное ограничение для применения. Так что, если вы что-то не сказали нам, отдел не нужен в профиле. Тем не менее, я отмечаю, что фактически нет перекрестных ссылок между департаментами и департаментами, поэтому один департамент, очевидно, может быть связан с несколькими департаментами - ничто не мешает подразделению № 1 быть связанным с одним человеком, который работает в отделе 1 и другой человек, который работает в отделе 2. Это необычно - не обязательно неправильно, но не так, как работает большинство организаций.

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

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

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

Вы говорите, что у пользователя есть одна фотография, но это не то, что вы смоделировали. Вы смоделировали «у каждого профиля есть фотография, и фотография используется только одним профилем». Кроме того, на самом деле вы не смоделировали «пользователи имеют один подраздел»; Вы смоделировали «профили имеют один подотдел». Скорее всего, это проблема с неаккуратными определениями, но вы должны быть осторожны, потому что неаккуратные определения приводят к неаккуратным базам данных, а неаккуратные базы данных приводят к неправильным ответам и плохой производительности.

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

Answer 2

Я предоставил вам пример схемы / схемы для просмотра.

Несколько замечаний. Модель Post (таблица сообщений) имеет слаг поля. Используйте поведение Sluggable для создания здесь слагов.

Модель отдела (таблица отделов) имеет поле с именем Department_id, это должно быть parent_id, но инструмент построителя выдает ошибки при этом. Измените это, как вам нужно. Поля lft, rght и parent_id соответствуют поведению дерева. Использование древовидного поведения в модели отделов позволит отделам произвольно принадлежать к «родительским» отделам. Это исключает необходимость в таблице sub_departments, поскольку подотдел - это действительно отдел, для которого parent_id установлен идентификатор другого отдела.

Прикрепленный профиль для пользователя и профиль habtm для фотографий, так что вы можете иметь неограниченное количество фотографий, прикрепленных к пользователю. Мне нравится сохранять свою модель пользователя стройной, используя только то, что нужно для компонента Auth. Модель профиля - это место, где я буду хранить имя, фамилию, возраст, город и т. Д.

Используйте поведение загрузки (MeioUpload) на фотомодели для автоматической загрузки.

Это должно стать хорошей отправной точкой для пересмотра вашего дизайна.

http://cakeapp.com/sqldesigners/sql/centro

пароль: centro

Answer 3

Вы можете протестировать концепцию проектирования базы данных CakePHP в режиме реального времени на CakeApp.com .