#sql #database-design
#sql #проектирование базы данных
Вопрос:
Я борюсь с дизайном базы данных для хранения адресов клиентов и связывания их с заказами в системе инвентаризации. В настоящее время у меня есть следующие идеи схемы и 3 варианта:
Клиенты
CustomerID
имя_клиента …..
CustomerAddress
AddressID
CustomerID
Тип адреса (выставление счетов, доставка и т. Д.)
Адресный1
адресный2 Город
Штат
Страна Почтовый индекс
Заказы (вариант 1)
Идентификатор заказа
Идентификатор
клиента Адрес выставления счетов Адрес
доставки
Заказы (вариант 2)
OrderID
CustomerID
BillingAddressLine1
BillingAddressLine2
BillingCity
BillingState
BillingCountry
BillingPostCode
ShippingAddressLine1
ShippingAddressLine2
ShippingCity
ShippingState
ShippingCountry
ShippingPostCode
Заказы (вариант 3)
OrderID
CustomerID
BillingAddressBlob
ShippingAddressBlob
Мне нужен адрес для заказа, чтобы оставаться статичным сверхурочно. Поэтому, если я оглянусь на заказ два года назад, я увижу, что правильные адреса тоже были отправлены и выставлены счета.
Ответ №1:
Обновление ответа с момента предыдущего ответа не помогло пользователю.
Вы можете иметь таблицу OrderAddress для сохранения адреса
Таблица адресов заказов со следующими столбцами
- Идентификатор заказа
- AddressID
Чтобы связать клиента с адресом, у вас может быть таблица CustomerAddress со следующими столбцами
- CustomerID
- AddressID
- Улица
- Город
- PIN-КОД
- Телефон
- Состояние
- Активен
Столбец Isactive будет использоваться для определения того, какой адрес активен в данный момент. Кроме того, из этой таблицы вы можете увидеть, сколько разных адресов существовало для клиента
Чтобы найти точный адрес, по которому был отправлен заказ, вы можете проверить таблицу OrderAddress
Надеюсь, что это соответствует вашим потребностям
Комментарии:
1. Привет, спасибо, я уже видел этот веб-сайт и связанные с ним shema. К сожалению, они не помогают, поскольку в этой схеме нет связи между заказами и адресами.
2. Спасибо, Шива, не могли бы вы объяснить, почему вы создаете отдельную таблицу для orderaddress. Поскольку для каждого заказа может быть только один адрес доставки и один платежный адрес, почему бы просто не указать два addressid в таблице заказов — (вариант 1)?
3. — Адрес для адреса — это сопоставление 1-1, адрес клиента может быть сопоставлением от 1 до многих. Может быть более 1 адреса, но должен присутствовать только активный адрес. При обновлении заказа с помощью нового адреса запись будет обновляться в таблице OrderAddress. Скорее в таблицу CustomerAddress будет добавлена новая запись. Кроме того, при запросе записей вы можете искать количество заказов для клиента. Вам может не понадобиться адрес, связанный с клиентом, если вам не нужны дополнительные сведения. Это основано на использовании запросов (с моей точки зрения)
4. Мне очень жаль, но я просто не понимаю. Я думаю, что у меня сложилось определенное мышление. Я просто не вижу преимущества в дополнительной таблице, в отличие от хранения идентификаторов адресов в таблице заказов. Я действительно ценю вашу помощь.
5. Сегодня утром у меня был свежий взгляд. Не могли бы вы еще раз объяснить свою идею, пожалуйста?