Основная проблема, которую я вижу, заключается в том, что хотя все первичные ключи определены как Int, некоторые внешние ключи или ссылки определены как varchar.
- компания в контактной таблице
- user_role в пользовательской таблице
- parent_company в компании
- добавлено_ в пользовательской таблице
Кроме того, role_id имеет длину 10, а все остальные первичные ключи - 11.
Лично я предпочел бы имена таблиц с большой буквы, пользователя, компании и т. Д.
Обновление для отредактированной версии:
Возможно, вы захотите создать таблицу для телефона, почты, факса и т. Д., Скажем, contact_info, которая может содержать строковое поле, содержащее контактную информацию, и поле типа (электронная почта, телефон, факс и т. Д.). Таким образом, вы можете сохранить несколько телефонных номеров, например, если вы хотите ограничить адрес электронной почты одним, вы можете либо оставить его в таблице person и не разрешать его здесь, либо иметь бизнес-правило, разрешающее только одну строку электронной почты в contact_info ,
Эта таблица также может быть полезна для company, если вы хотите сохранить электронную почту или телефонные номера для company, например contact@somecompany.com или номер для коммутатора компании
Для типа члена таблицы должны ли company_id и typename быть PK?
Да
Второе обновление
Об адресном решении:
Если таблица address не содержит достаточно информации, чтобы сделать каждый адрес уникальным, я могу понять, что компания может иметь более одного адреса, но если разрешить двум компаниям иметь один и тот же адрес (под этим я подразумеваю одну и ту же строку в база данных), поэтому, возможно, его следует изменить на «один ко многим» с company и «адрес», но один на один в другом направлении.
Я также думаю, что было бы хорошо иметь какую-то метку в двух таблицах адресных ссылок, чтобы можно было легко идентифицировать такие адреса, как «дом», «работа», «офис», «склад» ...