Дизайн базы данных, как настроить таблицы

Question

У меня есть простой сайт типа электронной коммерции, на котором будут пользователи с учетными записями, заказами и контактной / биллинговой информацией для этих пользователей. Я просто хотел узнать, как лучше настроить эти таблицы с точки зрения эффективности и логики. Пока что у меня есть две разные сущности: пользователи и заказы. Пользователи будут иметь основную информацию об учетной записи, такую ​​как имя и пароль, Заказы будут содержать всю информацию о конкретном заказе.

Мой вопрос заключается в том, должен ли я включать всю контактную информацию / информацию для выставления счетов в таблицу User или создать две отдельные таблицы, содержащие контактную информацию и информацию для выставления счетов?

Answer 1

Возможно, вам придется подумать об этом немного больше:

У пользователей есть контактный и платежный адрес, а как насчет доставки и других адресов? Возможно ли иметь двух пользователей от одной компании, каждый с разными контактными адресами, но с одним и тем же платежным адресом? Возможно ли для одного пользователя иметь несколько платежных адресов, которые они выберут при оформлении заказа?

Затем, когда дело доходит до ваших заказов, что произойдет, если клиент обновит свой платежный адрес, а затем вы откроете заказ до того, как изменился платежный адрес. Должен ли адрес для выставления счета в старом заказе быть новым или адресом с момента заказа?

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

Answer 2

Контактная информация, информация для выставления счета и доставки (при необходимости) логически разделены. С точки зрения чистой нормализации, адрес должен быть отдельным объектом, и у вас должны быть отношения между клиентами и адресами. Наиболее «правильный» подход с точки зрения нормализации будет иметь отношение «многие ко многим» между клиентами и адресами, с типом для разграничения между адресами выставления счетов, контактами и доставкой (при условии, что допустимо иметь более одного каждого) .

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

Прежде чем кто-либо скажет, что я зашел слишком далеко: «простые» сайты часто развиваются. Правильное предварительное моделирование данных избавит вас от невыразимых мучений в будущем.

Answer 3

Если вы будете искать контактную информацию и одновременно и редко будете использовать только одну из них, то нет смысла разделять их на разные таблицы, так как вы будете все равно присоединяюсь к ним.

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

Лично я бы не стал их разлучать, так как не могу предвидеть много раз, когда не хочу их обоих.

Answer 4

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

Answer 5

Будут ли случаи, когда у "пользователя" может быть несколько контактов?

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