架構設計：訂單和地址

這些是我用於維護自定義訂單的架構的簡化版本（所有表均在MySql中）。架構設計：訂單和地址

Order [Id, Shipping_AddressId, Receiving_AddressId] 
Address [Id, Contact, Line1, City]

訂單船舶及參考接收地址標識。情況：用戶A使用這些發貨地址和接收地址創建了10個訂單。之後，用戶決定編輯其中一個地址（比如R1）。由於我想保留原始訂單的細節，所以在編輯時，我會創建一個新地址並將舊地址標記爲不活動。（因此舊訂單保持不變）

Address [Id, Contact, Line1, City, Parent_AddressId, Status]

編輯時，我會拋出通知給每個人（用戶地址簿等）進行適當的更改。到目前爲止，這種方法一直「沒問題」。隨着移動應用程序進入，將被允許緩存一些數據和定期同步，我看到更多的問題會出現（有解決方案，但他們正在使操作昂貴）。

問題：是否有其他（標準）方法來處理這個問題？

來源

2015-12-12 TJ-

您應該將地址作爲參考數據，但是可以讓用戶爲您做一些編輯工作的維基式規則 –

最初，我使用了一個地址表，其中的主鍵類似於您正在這樣做的主鍵，但遇到了許多問題。我已經離開了這種方法，並且將我的訂單表中添加了「street_address_ship」，「city_ship」（州或省/等等，以及相同的接收），並且我的問題消失了。

似乎有一個辯論，我的方法是否正常化，但是，我覺得更是如此。由於任何地址都可以由street_address，city等唯一標識，因此該記錄的單獨主鍵是多餘的，不應使用。

來源

2015-12-12 14:25:22 user1032531

在我的地址表中，大約有10個字段（地址都是非標準的，包括農村地區和包含地理位置信息）。還有一些統計領域（有爭議的）。因此，將所有信息移至訂單可能無效。從您的解決方案看來，我認爲我可以將「顯示給用戶的地址信息快照」作爲列添加到訂單表中。但是，這些數據不會被查詢。地址的主鍵仍然保留在訂單中。現在我正在考慮這個問題的長期影響。 –

架構設計：訂單和地址

回答

相關問題