0

更新時維護鏈接數據實體完整性的最佳做法是什麼?更新時鏈接數據實體的完整性

我的情況

  1. 我有兩個實體 「客戶端和 發票」。 [客戶是定義和 發票是交易]。
  2. 向 客戶端發出許多發票後,發生客戶端 需要更改 例如, 「他的帳單地址/位置 已更改或企業名稱等...」。
  3. 這是正常的,用戶必須是 能夠更新客戶端 信息,以保持數據在系統中的完整性 。
  4. 發票「交易單位」 我並不只存儲客戶端ID,但 也都涉及到 發票,如「客戶名稱,地址, 接觸」的客戶信息,這是衆所周知的 方法將數據存儲在交易實體 中。
  5. 如果用戶創建了一個新的發票 新的客戶端信息將被存儲在發票記錄 沿 具有相同客戶端ID(很明顯 !)。

我的問題

  1. 是不是好來綁定數據實體 「客戶」從插入和更新不同位置 ? [說明:如果我跟着從步驟1-4的方法 我不得不 綁定從 客戶表中的客戶端實體在創造新 發票但在 更新的情況下/打印發票的情況下,我有 結合從 發票表的客戶端實體否則數據 不會是一致或整數...所以 我怎麼能保持數據完整性 沒有 創造意大利麪條代碼DAL來處理這個自定義的數據綁定 要求? ?]
  2. 我通過的系統是 sav在更新 「保留所有版本的歷史」之前更新 實體數據的所有先前版本。 如果我想使用相同的方法來 避免自定義綁定我怎麼可以 在數據庫設計方面做到這一點 「使用MYSQL」? [說明:與版本創建的一些 發票 客戶端1.0,則客戶端信息 更新和版本1.1開始和 與去年 版本創建新的發票......因此,它是很好的遵循 這種方法?以及我應該如何設計我的實體/表以滿足實體 版本控制和綁定的要求?
  3. 請提供任何書籍或參考 可以踢我在正確的 方向嗎?

感謝,

回答

0

你需要做的是按照原樣離開桌子。您是對的,您應該將發票上的客戶信息存儲在發貨地點的歷史記錄中。當它發生變化時,除了尚未發貨的任何發票外,您不應更新此信息。要維護這種類型的信息,您需要在客戶表上尋找尚未裝運的發票並自動更新這些地址的觸發器。

如果要保存客戶端信息的歷史版本,則正確的過程是創建一個審計表並通過觸發器填充它。

這種情況下的數據完整性僅僅是通過客戶ID的外鍵。該id本身不應該改變或被允許由用戶改變,並且應該是諸如整數的替代號碼。因爲您不應該更改實際發票中的地址信息(除非在此情況下尚未發貨,否則您最好更改發貨地址或將產品運送到錯誤的地方),這樣做足以保證數據的完整性。這也可以讓你看到東西在哪裏實際發貨,但仍然通過使用外鍵查找有關客戶端的當前信息。

如果您有更改的客戶端(其他公司購買的套餐),您可以在服務器上運行一個進程來更新舊記錄的客戶ID,或創建一個表結構來顯示哪個客戶端ID屬於當前父ID 。如果你不願意談論改變數以百萬計的記錄,第一個更容易做到。

+0

謝謝,這真的把我深深地踢向了正確的方向;) – 2010-01-26 11:18:17

-3

我不是你做了什麼完全清楚,但我想你想在規範化閱讀起來,在關係數據庫和SQL很多書可用。我想你最終會得到的是兩張表通過一個外鍵相連,但也許在前面的句子中有一些靈魂搜索會幫助你澄清你的想法。

+0

正常化!我不這麼認爲。請閱讀整個問題。 – 2010-01-24 16:37:18

+1

這是一個商業案例,其中數據必須非規範化以保留所發貨物的歷史記錄。他的設計沒有錯。 – HLGEM 2010-01-25 16:15:58

0

「這是一個商業案例,其中數據必須非規範化以保存所發貨物的歷史記錄,他的設計沒有錯誤。」

對不起,添加此作爲新的迴應,但「添加評論」按鈕仍然不顯示。

「他的設計」確實是不正確的......因爲它是正常化的!

這是正常化的,因爲它並不總是真的對應於發票的地址在功能上取決於客戶ID的排他性。

所以:正常化,是的,我確實這麼認爲。不是規範化是這裏涉及的唯一問題。

+0

老兄,實際上我怎麼會用歸一化技術來解決問題!到目前爲止,我所瞭解的是,審計和正常化之間存在權衡。那麼在這裏談論標準化作爲概念有什麼意義?我正在尋找一種解決方案,而不是數據模擬課程。 – 2010-01-26 21:13:20