woaidongmao

在博客園上看到了一篇關(guān)于數(shù)據(jù)庫范式的文章《數(shù)據(jù)庫設(shè)計(jì)中的五個(gè)范式》：
 第三范式規(guī)則查找以消除沒有直接依賴于第一范式和第二范式形成的表的主鍵的屬性。我們?yōu)闆]有與表的主鍵關(guān)聯(lián)的所有信息建立了一張新表。每張新表保存了來自源表的信息和它們所依賴的主鍵。  
 關(guān)于第三范式的思想，我想有很多朋友都熟悉，在數(shù)據(jù)庫設(shè)計(jì)時(shí)，也是我們盡可能采用的范式之一，第三范式的出發(fā)點(diǎn)是什么？就是盡可能的減小“數(shù)據(jù)冗余”、并也能得到“數(shù)據(jù)”的整潔性，提高維護(hù)性，不容懷疑，第三范式是我們努力、必須要去遵從的。
 然而，有很多朋友把第三范式作為“不死的法寶”，但其實(shí)在實(shí)際的應(yīng)用中，我們還是要從不同的業(yè)務(wù)出發(fā)，要合理的應(yīng)用“第三范式”。下面我也就簡單的舉個(gè)例子：
    一張訂單會關(guān)聯(lián)很多的基礎(chǔ)資料，如：客戶，付款條款，貨運(yùn)方式等，這些信息是有專門表進(jìn)行維護(hù)的，在下訂單時(shí)也是用下拉框選擇的，在保存訂單信息時(shí),按照“第三范式”的要求，那應(yīng)該只保存對應(yīng)的主鍵值就OK了。因?yàn)檫@樣可以避免數(shù)據(jù)冗余，但對我來說，我不會這樣做，我會把客戶的名稱、聯(lián)系電話、付款條款名稱等訂單上要求記錄的信息直接COPY到訂單的表中。
   這樣看來，我們違背了“第三范式”，是的，但在這里，我們違背“第三范式”也是有理由的：
   1我不想在訂單下達(dá)完以后，刪除了某條付款條款，導(dǎo)致這些訂單無法知道“真實(shí)的付款條款”了，這肯定不合理。
   2我也不想，因?yàn)橄铝诉@張訂單了，而“嚴(yán)格控制”付款條款的“刪除”功能，這也不合理，憑啥不能刪除了？下個(gè)月這個(gè)“條款”確實(shí)永遠(yuǎn)不會采用了。
   3我也不想，付款條款修改后，導(dǎo)致以前所有采用此付款條款的訂單都變成新的條款，那在系統(tǒng)中的訂單如何與手頭的紙張訂單再對應(yīng)，這肯定也不合理。

  所以，我的設(shè)計(jì)原則是，對于這種訂單我們應(yīng)該采用“隔離”的方式來對待，讓基礎(chǔ)數(shù)據(jù)COPY到訂單中，這當(dāng)然會違背所謂的“第三范式”，但這也是實(shí)際的需要啊。理論與實(shí)際是有差別的。
  訂單--這種在現(xiàn)實(shí)中以實(shí)物的方式存在，實(shí)物具有與基礎(chǔ)數(shù)據(jù)的參考性，而不是關(guān)聯(lián)性，基礎(chǔ)數(shù)據(jù)只能是作為訂單這個(gè)實(shí)物的一個(gè)“參考”，而不是“關(guān)聯(lián)”，這可以稱為“獨(dú)立性”;再者，訂單具有一定的歷史性，因?yàn)槭菍?shí)物，在實(shí)際的過程中，是即時(shí)生成的，那么在生成的當(dāng)時(shí)去參考了基礎(chǔ)數(shù)據(jù)，訂單就在當(dāng)時(shí)被確定，確對不能因?yàn)榛A(chǔ)數(shù)據(jù)的修改而導(dǎo)致訂單被“無辜變性”了，這也就是訂單的“歷史性”，當(dāng)以后翻閱這些紙張訂單時(shí)也能對應(yīng)上系統(tǒng)里的訂單。

   這是我所理解的最典型的例子，在實(shí)際的系統(tǒng)設(shè)計(jì)中，我們應(yīng)該多思考一下，是不是要采用“第三范式”，不要再盲目追捧了。

  以上純屬我個(gè)人意見，僅供參考，歡迎大家討論。

Feedback

#1樓    回復(fù)  引用  查看    

2005-05-08 14:23 by Lostinet     

例如今天賣了2個(gè)面包，價(jià)格是3塊，那么Sales表里應(yīng)該把當(dāng)時(shí)的價(jià)格也紀(jì)錄了。而不只是紀(jì)錄了這個(gè)面包的型號，因?yàn)槊姘膬r(jià)格是會變化的。
關(guān)鍵是要對數(shù)據(jù)的含義與關(guān)系有清晰的認(rèn)識。而這種紀(jì)錄本身不屬于冗余，并不和數(shù)據(jù)庫設(shè)計(jì)的理論有沖突的地方。

就客戶改名字的說法，訂單紀(jì)錄的數(shù)據(jù)可以當(dāng)作是“訂單時(shí)的客戶名稱”，與客戶表的“當(dāng)前名稱”有著不同的意義，這就不是冗余。

#2樓    回復(fù)  引用  查看    

2005-05-08 14:25 by 嘿嘿     

范式原則是用于指導(dǎo)性地設(shè)計(jì)數(shù)據(jù)的存儲結(jié)構(gòu)的，僅僅只是理論。必要的時(shí)候是需要反范式，或者容忍一定的數(shù)據(jù)冗余，使得系統(tǒng)的性能或邏輯清晰性上更好。

范式是一種基于純粹的從數(shù)據(jù)存儲量上來優(yōu)化數(shù)據(jù)結(jié)構(gòu)的方式，并不是一個(gè)非常通用的東西。

另外：
“1我不想在訂單下達(dá)完以后，刪除了某條付款條款，導(dǎo)致這些訂單無法知道“真實(shí)的付款條款”了，這肯定不合理。
　2　我也不想，因?yàn)橄铝诉@張訂單了，而“嚴(yán)格控制”付款條款的“刪除”功能，這也不合理，憑啥不能刪除了？下個(gè)月這個(gè)“條款”確實(shí)永遠(yuǎn)不會采用了。”

上述情況，實(shí)際上可以考慮采用倉庫性質(zhì)的數(shù)據(jù)管理方法：即，對于所有的數(shù)據(jù)，分為可用與不可用，放在不同的表間，然后可以把其中的數(shù)據(jù)挪來挪去。

你說的情況非常現(xiàn)實(shí)，從業(yè)務(wù)角度出發(fā)，將數(shù)據(jù)結(jié)構(gòu)優(yōu)化為最高存儲效率的是沒有意義的，范式更多是一種指導(dǎo)，而不是原則。

#3樓    回復(fù)  引用  查看    

2005-05-08 14:39 by 寒楓天傷     

我覺得這是理論與實(shí)踐中的區(qū)別，或者說，一般人對范式的理解并不對。

一般而言，范式是作為指導(dǎo)性原則存在的，范式提供了一種指導(dǎo)性的依據(jù)，可以實(shí)現(xiàn)最終冗余數(shù)據(jù)的消除。但在實(shí)際上，冗余數(shù)據(jù)并不是違法的，也不是不允許的，除了性能上的需要外，很多情況下都需要冗余數(shù)據(jù)來實(shí)現(xiàn)參照完整性。

數(shù)據(jù)庫設(shè)計(jì)最主要的概念之一就是參照完整性，一個(gè)完整的數(shù)據(jù)庫中，存儲的關(guān)聯(lián)信息，應(yīng)該是要么都存在，要么都消失，如樓主說的：
“我不想在訂單下達(dá)完以后，刪除了某條付款條款，導(dǎo)致這些訂單無法知道“真實(shí)的付款條款”了，這肯定不合理。”
理論上，如果依照范式實(shí)施的參照完整性，要求這里的付款條款所關(guān)聯(lián)的訂單全部都刪除，否則的話，該付款條款是不應(yīng)該刪除的。

不過，更重要的是：樓主所說的“付款條款”與“訂單”間應(yīng)該是弱耦合關(guān)系，它們應(yīng)該是分開的。這個(gè)矛盾產(chǎn)生兩張有關(guān)聯(lián)的表的存儲方式上。這個(gè)情況而言，付款條款應(yīng)該是作為輔助表而存在的，有可能這個(gè)表僅僅是為了提供下拉列表或其它什么方式的便利性輸入接口，那么“付款條款”本質(zhì)上只是存儲了的數(shù)據(jù)，它與“訂單”間不應(yīng)該有關(guān)系。

樓主的做法從這個(gè)角度上而言，并未違反第三范式。第三范式應(yīng)該集中應(yīng)用于有業(yè)務(wù)關(guān)系的表，而不應(yīng)將輔助表也包括在內(nèi)。

#4樓    回復(fù)  引用  查看    

2005-05-08 14:56 by hudan     

基本同意樓主的觀點(diǎn),但就樓主提出的例子談一下我的想法:
就你說的這種,我的做法是在"付款條款"基本表中增加一列是否刪除的標(biāo)識列,刪除的時(shí)候修改"刪除標(biāo)識"列,以后用戶下訂單的時(shí)候就不會看到這個(gè)條款了,但是查詢歷史數(shù)據(jù)的時(shí)候仍然可以查詢到以前的條款.
對于你說的第三點(diǎn)"系統(tǒng)中的訂單如何與手頭的紙張訂單再對應(yīng)",我的這種做法就無法實(shí)現(xiàn)對應(yīng)了.就會全部顯示修改后的條款.

有些情況下為了提高查詢速度也冗余幾個(gè)字段,我認(rèn)為是值得的.

#5樓    回復(fù)  引用  查看    

2005-05-08 15:07 by mikespook     

《迦勒比海盜》里面有一句話：“法典，更像是指南，而不是準(zhǔn)則……”

#6樓 [樓主]   回復(fù)  引用  查看    

2005-05-08 15:21 by 聽棠.NET     

@寒楓天傷 :
我覺得這也是指關(guān)聯(lián)，因?yàn)槲覀円部梢圆捎玫谌妒絹韺?shí)現(xiàn)，只是訂單在這種情況下會遇到好多的問題.

在訂單的設(shè)計(jì)中，我一般會有“條款ID”、“條款名稱”，也就是我會把主鍵對應(yīng)上以后，把Name也帶過來，之所以要帶入"條款ID"，主要還是因?yàn)橛唵涡枰薷模谛薷臅r(shí)，可以默認(rèn)選中原來的值。而“條款名稱”的帶入就是我前面的說的原因。
因此，從這一點(diǎn)來說，這些確實(shí)是違背了“第三范式”。

#7樓    回復(fù)  引用  查看    

2005-05-08 18:17 by lay     

呵呵，我覺得樓主舉的例并不是違反了，字典表相對來說要特殊些。最終還是得根據(jù)具體業(yè)務(wù)來定

#8樓    回復(fù)  引用  查看    

2005-05-08 18:58 by 上山砍柴去     

“1我不想在訂單下達(dá)完以后，刪除了某條付款條款，導(dǎo)致這些訂單無法知道“真實(shí)的付款條款”了，這肯定不合理。
＝＝為何要允許刪除付款條件？不可以設(shè)為失效嗎？

2我也不想，因?yàn)橄铝诉@張訂單了，而“嚴(yán)格控制”付款條款的“刪除”功能，這也不合理，憑啥不能刪除了？下個(gè)月這個(gè)“條款”確實(shí)永遠(yuǎn)不會采用了。
＝＝不能刪除就是不能刪除，規(guī)定下來不可以嗎？同樣，設(shè)為失效不行嗎？

3我也不想，付款條款修改后，導(dǎo)致以前所有采用此付款條款的訂單都變成新的條款，那在系統(tǒng)中的訂單如何與手頭的紙張訂單再對應(yīng)，這肯定也不合理。
＝＝付款條件可以隨意修改的嗎？同樣，需要修改的不可以新建一個(gè)條件嗎？

我認(rèn)為，你的數(shù)據(jù)庫這樣設(shè)計(jì)是非常不成功的。就因?yàn)槟闵厦娴睦碛删驮斐沙汕先f條記錄的冗余？這合理嗎？

一已之見，只承擔(dān)有限責(zé)任。。。

#9樓    回復(fù)  引用  查看    

2005-05-08 19:26 by 好     

其實(shí)樓主說的很有理，好多時(shí)候，我們要因事而宜不能把住死理不放，但是一個(gè)理論的存在是有一定的道理的，起碼在一段時(shí)間內(nèi)，所以我想去應(yīng)用第三式，還是必要的

#10樓    回復(fù)  引用  查看    

2005-05-08 20:12 by 紅移     

可以這樣設(shè)計(jì)

訂單表：
訂單號（主鍵）
條款號（外鍵）
[其它內(nèi)容]

條款表：
條款號（主鍵）
有效標(biāo)記（bit）
條款內(nèi)容
[其它內(nèi)容]

列訂單時(shí)只列出條款表中有效標(biāo)記為1的條款。刪除條款的前提是該條款不再有人用到（在訂單表中）。如果有人用到，則只是把有效標(biāo)記設(shè)為0。當(dāng)刪除訂單時(shí)，檢查條款表中相應(yīng)的條款，如果它已經(jīng)無效并且除了本訂單外無其它人用到，則順便刪除該條款。

#11樓    回復(fù)  引用  查看    

2005-05-08 20:29 by 一川煙草     

我搞8年的業(yè)務(wù)系統(tǒng)，從單機(jī)程序到800多個(gè)表的大系統(tǒng)。
我的感覺是冗余確實(shí)是非常必要的。
用空間換取效率。
我有一個(gè)check表，餐飲系統(tǒng)的。
包括了開單員
開單銷售點(diǎn)
開單餐段

結(jié)單員
結(jié)單銷售點(diǎn)
結(jié)單餐段

#12樓    回復(fù)  引用  查看    

2005-05-08 20:36 by 一川煙草     

我的感覺是冗余確實(shí)是非常必要的。
用空間換取效率。
我有一個(gè)check表，餐飲系統(tǒng)的。
包括了開單員
開單銷售點(diǎn)
開單餐段
開單終端
結(jié)單員
結(jié)單銷售點(diǎn)
結(jié)單餐段
結(jié)單終端
這些都是外鍵，而且每個(gè)外鍵的描述都包括，中文，英文，其它語言三個(gè)描述。
在給客戶顯示數(shù)據(jù)的時(shí)候，得根據(jù)當(dāng)前語言顯示對應(yīng)描述。這樣的查N個(gè)表返回?cái)?shù)據(jù)，一個(gè)稍有規(guī)模的餐廳，每天的單數(shù)有上千張。這樣的查詢效率極地下。
經(jīng)過冗余之后，以上8個(gè)字段我們把它冗余為32個(gè)。把全部描述都丟到check表，查詢效率成倍提升。并且簡化了程序員的開發(fā)。
對于設(shè)置表的刪除，我的看法是為什么要真的刪除呢？設(shè)置表的主鍵完全可以設(shè)計(jì)成用戶不可見的。用戶仍然可以刪除，不過真實(shí)的數(shù)據(jù)只不過作了個(gè)刪除標(biāo)記而已。

#13樓 [樓主]   回復(fù)  引用  查看    

2005-05-08 21:27 by 聽棠.NET     

@上山砍柴去 :
其實(shí)我非常不想跟你討論這些問題，你說的幾個(gè)跟我的意思根本不是一回事。你可以用“是否有效”來實(shí)現(xiàn)，你的意思是所有的基礎(chǔ)都有“是否有效”，可客戶就是不喜歡這種“是否有效”的標(biāo)志，"是否有效"是在客戶"暫時(shí)不用"的情況下會采用，知道什么叫"暫時(shí)"嗎？再者，時(shí)間一長你搞那么多"無效"的多惡心啊。
還有我說的就是能允許客戶刪除，你憑什么不讓客戶刪除，你以為這是給客戶考慮嗎？
自己去悟吧。

#14樓    回復(fù)  引用  查看    

2005-05-08 21:52 by rIPPER     

客戶一定要直接看到這個(gè)有效標(biāo)志么，他不喜歡看，你可以不讓他看到，這很容易嘛。

要玩客戶不要被客戶玩，他說要刪除你就真從數(shù)據(jù)庫里面刪掉一條記錄？

#15樓    回復(fù)  引用  查看    

2005-05-08 22:10 by 一川煙草     

我道是同意作標(biāo)記，對于用戶來說，什么叫刪除？界面上看不到了就是刪除。

#16樓 [樓主]   回復(fù)  引用  查看    

2005-05-08 22:25 by 聽棠.NET     

我知道大家可以作標(biāo)記，我也是對一些需要用到“標(biāo)記”的我會用，但如果那些根本沒必要用的，都采用“標(biāo)記”的方式來處理，我覺得很不爽，明明已經(jīng)不再可用的東西，在數(shù)據(jù)庫里放著，太惡心了。。還招來程序的麻煩。。

#17樓    回復(fù)  引用  查看    

2005-05-08 22:40 by 小陸     

我覺得冗余帶來的最大的問題在于難以同步，占用空間倒是其次。

#18樓    回復(fù)  引用  查看    

2005-05-08 23:01 by 楚瀟     

經(jīng)過實(shí)際的項(xiàng)目的話，就明白樓主所說的道理了。
做一個(gè)刪除標(biāo)志也是可行的，但是很多的時(shí)候，沒有樓主說的方法好。

#19樓    回復(fù)  引用  查看    

2005-05-09 00:12 by yfmine     

To:hudan
個(gè)人意見，在數(shù)據(jù)庫里只添加新規(guī)則，不能改變已有規(guī)則，任何改動都視作新添加，這樣就能實(shí)現(xiàn)第三點(diǎn)了。不過這樣的數(shù)據(jù)也。。。

#20樓    回復(fù)  引用  查看    

2005-05-09 00:57 by wljcan     

同意 寒楓天傷 的觀點(diǎn)。


從文中的描述來看，應(yīng)該是弱耦合，但是這段話又有些問題：

*****在訂單的設(shè)計(jì)中，我一般會有“條款ID”、“條款名稱”，也就是我會把主鍵對應(yīng)上以后，把Name也帶過來，之所以要帶入"條款ID"，主要還是因?yàn)橛唵涡枰薷模谛薷臅r(shí)，可以默認(rèn)選中原來的值。而“條款名稱”的帶入就是我前面的說的原因。

既然已經(jīng) 將Name copy過來了，為什么還要ID呢？ “默認(rèn)選中原來的值” 好像不成立。

另外，技術(shù)討論沒有必要有這么濃的火藥味。 ：=）

#21樓    回復(fù)  引用  查看    

2005-05-09 08:56 by 老翅寒暑     

關(guān)于文中的訂單中客戶信息部分一定是需要copy到訂單表中的。這么多人考慮問題，怎么沒有人從法律效力方面來考慮呢？做一個(gè)系統(tǒng)首要要保證的是呈現(xiàn)的統(tǒng)一性，一個(gè)訂單錄入之后，只要沒有修改，無論多長時(shí)間，它的輸出格式和內(nèi)容都不能有變化。這個(gè)是法律意義上的完整性。總不能今天訂單上是xx公司，明天xx公司改名成了xxx有限公司，難道之前和xx公司的訂單（或者合同）就要自動變成xxx有限公司？

#22樓 [樓主]   回復(fù)  引用  查看    

2005-05-09 09:15 by 聽棠.NET     

@老翅寒暑 :
我說的就是你指的意思，一張訂單已經(jīng)確定，那么具有獨(dú)立性與歷史性。

@ 上山砍柴去 :
客戶說是保留，那你當(dāng)然保留好了，我沒有否認(rèn)這一點(diǎn)啊，但就怕客戶說不要保留，你卻偏偏要保留啊。至于數(shù)據(jù)冗余你看下面的。

至于“為什么還要ID呢？”就是有可能會進(jìn)行修改，那么如果不帶ID過去，修改時(shí)如何選中默認(rèn)值，要是不能默認(rèn)選中，結(jié)果客戶修改只是為了修改其它的一個(gè)屬性，而這個(gè)ID可能會在不注意的情況下被修改掉了。因?yàn)槭窍吕虻摹?span lang="EN-US">
至于作標(biāo)記，也是一種方式，比如客戶說給作個(gè)標(biāo)記或者是此值是應(yīng)該具有“暫時(shí)不用”的情況，那么用標(biāo)識當(dāng)然是最好的。
就像老翅寒暑 說的，一張訂單是實(shí)物，在業(yè)務(wù)實(shí)際中明明確確存在，要是從法律上講也具有法律，就算沒有法律性，我們也要把它視為一個(gè)獨(dú)立性，有朋友說，以后修改怎么辦？一張訂單在當(dāng)時(shí)下達(dá)，就具有當(dāng)時(shí)的即時(shí)性與歷史性，不可能因?yàn)槟阋院蟮幕A(chǔ)數(shù)據(jù)的修改而導(dǎo)致訂單失去原來的屬性，因此這些所謂的“冗余”只是從"第三范式"上講的，而在實(shí)際的業(yè)務(wù)中，其實(shí)沒有所謂的“冗余”。

#23樓    回復(fù)  引用  查看    

2005-05-09 09:39 by na     

如果你要隔離，那還有很多要隔離哦....
為何不在刪除條款時(shí)看看是不是已經(jīng)用過這個(gè)條款呢？
基礎(chǔ)數(shù)據(jù)如果使用過是不給刪除的。

#24樓    回復(fù)  引用  查看    

2005-05-09 09:41 by 上山砍柴去     

同意樓上的。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
我并沒有受傷，比你刻薄的人多的是。
有人附和是因?yàn)樗麄儽饶愀鼪]有經(jīng)驗(yàn)，至少站在管理的角度來講，你這樣的觀點(diǎn)更是不恰當(dāng)?shù)摹?span lang="EN-US">
作為基礎(chǔ)數(shù)據(jù)，修改和刪除的權(quán)限都是比較高的，特別是這種有關(guān)聯(lián)其它數(shù)據(jù)的基礎(chǔ)數(shù)據(jù)，使用后更是不能隨意修改和刪除的，這在系統(tǒng)一級就應(yīng)該予以禁止。系統(tǒng)級不能解決的，就要在管理一級予以解決。
如果依你這樣的設(shè)計(jì)，那么其它的基礎(chǔ)數(shù)據(jù)不都要帶進(jìn)別的表中去？產(chǎn)品數(shù)據(jù)，供貨商數(shù)據(jù)，客戶數(shù)據(jù)，。。。。等等等等。你這樣的數(shù)據(jù)設(shè)計(jì)有你認(rèn)為是成功的嗎？
你認(rèn)為沒法跟我說，至少你覺得說服我有難度，我認(rèn)為你這樣的觀念去做需求分析肯定是失敗的。最終出來的產(chǎn)品也肯定是個(gè)N不像產(chǎn)品。懂系統(tǒng)設(shè)計(jì)沒什么也不起，隨便找?guī)讉€(gè)人來都會做。反正都是客戶說了算。出了錯(cuò)也是客戶自已找的。

#25樓    回復(fù)  引用  查看    

2005-05-09 09:56 by 小陸     

根據(jù)文中的描述, 訂單記錄以后, 需要保留當(dāng)時(shí)即時(shí)性和歷史性, 所以, 保留這些數(shù)據(jù)不能叫做冗余, 因?yàn)檫@些信息是必要. 所以從原則上說不違反第三范式.

關(guān)鍵在于保留的方式. 既然將name已經(jīng)復(fù)制過來了, id我覺得就是冗余了, 并且這兩個(gè)數(shù)據(jù)可能是不一致的, 如果以后需要修改的話, 直接顯示name就是了. 如果要便于用戶輸入, 可以使用輸入+選擇的方式.
另一種做法就是保留每一個(gè)配置的版本, 每當(dāng)用戶修改或者刪除一個(gè)配置數(shù)據(jù), 不是實(shí)際的進(jìn)行修改, 而是添加新的version, 這樣的方式是最好的, 完全符合第三范式.

至于客戶要求刪除, 我理解是: 客戶看不見的就可以認(rèn)為刪除了, 沒必要真的從物理上刪除掉.

沒有什么原則是"不得不違背"的, 干出違背原則的事情一定要有更加有力的原則作為后盾. 比如: 適當(dāng)冗余可以提高運(yùn)行效率, 合理冗余可以增加系統(tǒng)容錯(cuò)性. 如果單純?yōu)榱撕喕_發(fā)的過程, 我的體會是: 沒有冗余開發(fā)最簡單.

#26樓 [樓主]   回復(fù)  引用  查看    

2005-05-09 10:20 by 聽棠.NET     

@小陸 :
ID可以考慮不保留，確實(shí)可以直接修改NAME，因?yàn)閺哪撤N意義上說，參考的數(shù)據(jù)COPY過來后，就認(rèn)為已經(jīng)確定了。

至于刪除的控制，有些基礎(chǔ)數(shù)據(jù)是需要使用“控制來限制的”，但不是全部。為何有人不思考實(shí)際中的一些差別呢。
na說有很多要隔離？？也不是啊，具有獨(dú)立性與歷史性的實(shí)物，是建議要隔離的。

上山砍柴去說這么多人都是沒有經(jīng)驗(yàn)的？？
我真不知道，是不是很有經(jīng)驗(yàn)的人跟你一樣，所有的基礎(chǔ)數(shù)據(jù)都采用“刪除控制”來做的，你可以去調(diào)查一下。

#27樓    回復(fù)  引用  查看    

2005-05-09 10:37 by ayya__@hotmail.com     

對于主表的刪除當(dāng)然是用標(biāo)記來做最好.
如果以后客戶又需要用已經(jīng)刪除的數(shù)據(jù)怎么辦?

#28樓 [樓主]   回復(fù)  引用  查看    

2005-05-09 10:41 by 聽棠.NET     

@ayya__@hotmail.com :
對，如果那些需要“暫時(shí)”不用的，是應(yīng)該要用標(biāo)記來做的。應(yīng)該可以修改狀態(tài)，也可以刪除吧，要是他們確實(shí)想刪除。
其實(shí)這種刪除不刪除無所謂了，問題是基礎(chǔ)數(shù)據(jù)應(yīng)該COPY過去。

#29樓    回復(fù)  引用  查看    

2005-05-09 10:59 by Laser.NET     

我個(gè)人比較贊同Lostinet的看法，其實(shí)不能算是違反第三范式。

你在 “訂單表” 中存儲的是 “那個(gè)訂單當(dāng)時(shí)的客戶信息” 和 “那個(gè)訂單當(dāng)時(shí)的付款條款” 這些信息離開了那個(gè)訂單就沒有意義，所以它們完全依賴于訂單主鍵，而那個(gè)訂單也需要這些信息，在你所講的業(yè)務(wù)環(huán)境下它們對訂單來講必不可少，所以這本來就符合第三范式：）

#30樓    回復(fù)  引用  查看    

2005-05-09 11:02 by Austin leng     

有道理喲，想問一下聽棠.NET，一個(gè)表里的字段數(shù)如果太多，你說有沒有問題，比如有張表TestTable，里面包含了60多個(gè)字段，你認(rèn)為這有不有問題？

#31樓    回復(fù)  引用  查看    

2005-05-09 11:05 by Austin leng     

數(shù)據(jù)庫設(shè)計(jì)，唉，很重要，哪位牛人推薦一本牛書，謝謝啦

#32樓 [樓主]   回復(fù)  引用  查看    

2005-05-09 11:15 by 聽棠.NET     

其實(shí)從業(yè)務(wù)角度講，這種數(shù)據(jù)的COPY不能算是違反第三范式，那看一張主表可能會有相當(dāng)多的關(guān)聯(lián)，那么也是要根據(jù)這張主表的信息情況，比如訂單，那些訂單本身所固有的屬性應(yīng)該從基礎(chǔ)表COPY過來，而對于“訂單類型”可能不屬于訂單本身客觀存在的屬性，那么我們可以采用外鍵關(guān)聯(lián)的方式。象這種那么在刪除上是需要作限制的。

#33樓    回復(fù)  引用  查看    

2005-05-09 14:50 by Arming     

大家討論這么多，我看基本上是兩種觀點(diǎn)：1是Copy。2是外鍵引用，但通過“刪除標(biāo)志”控制。
第一種表面上看是不違反第三法則，因?yàn)樗蓱]到條款的變更。寒楓天傷和 聽棠.NET都說了相應(yīng)理由。
這里的關(guān)鍵也就在于“條款”，老翅寒暑也明確提出了條款的業(yè)務(wù)含義。那么條款信息也不是簡單的數(shù)據(jù)字典業(yè)務(wù)所能涵蓋。條款的信息維護(hù)和訂單引用條款的地方就必須有些特殊的代碼來體現(xiàn)這個(gè)特殊性。
通過直接Copy來保證訂單的“法律性”和新訂單使用最新條款，確實(shí)能節(jié)省代碼量，但數(shù)據(jù)冗余也是毋庸置疑的，試想，一個(gè)2000字左右的協(xié)議，每個(gè)訂單都擁有一份，而我這條款實(shí)際上也就兩三年一變。
如果對條款信息引入一個(gè)版本概念，或者是否啟用概念(上山砍柴的一個(gè)觀點(diǎn)，不過他的口氣確實(shí)不好，不是討論問題的態(tài)度)，實(shí)際上確實(shí)也應(yīng)該存在這么一個(gè)概念，（注意，不是所有的引用信息都是如此維護(hù)。比如性別）。條款一旦被某訂單引用，就不允許修改或刪除，只能以版本變更方式變更。
對無效條款的刪除（太多了確實(shí)不爽），可以在條款維護(hù)業(yè)務(wù)里控制，比如顯示某條款當(dāng)前有多少訂單引用了，不過這只是易用性問題。可以通過增強(qiáng)界面控制實(shí)現(xiàn)。
至于新訂單時(shí)能使用什么條款，這也是具體業(yè)務(wù)決定，我覺得界面上如何顯示，下拉框，還是彈出窗口，都不應(yīng)該在此問題內(nèi)討論。通常會在一個(gè)條款集合類提供一個(gè)靜態(tài)方法，提取合適的條款集合作為新訂單的選擇。
訂單修改時(shí)，是否能重新選擇條款，或者此時(shí)條款剛剛更新，是否自動啟用新條款，這些都由具體業(yè)務(wù)來決定，也不是此問題范疇。

BW：我在設(shè)計(jì)或開發(fā)時(shí)也不喜歡被條條框框約束。一切根據(jù)具體情況而定，假如項(xiàng)目小，或時(shí)間緊，資源不足，再或者這個(gè)條款長度也不長，我會毫不猶豫地使用Copy。
但假如條款確實(shí)長到讓我感覺冗余比較大，以及后期的可維護(hù)性。確實(shí)應(yīng)該花時(shí)間考慮如何設(shè)計(jì)條款信息維護(hù)的業(yè)務(wù)。

#34樓    回復(fù)  引用  查看    

2005-05-09 15:30 by step     

我碰到的應(yīng)用也用到了冗余，當(dāng)時(shí)覺得不符合范式要求，總是不情愿的認(rèn)同，今天終于心服了。總是被理論束縛的心態(tài)很不舒服啊！

#35樓 [樓主]   回復(fù)  引用  查看    

2005-05-09 15:38 by 聽棠.NET     

@Arming :
你的觀點(diǎn)跟我們大致一樣，只是你可能沒搞清楚什么叫“付款條款”，英文名叫“Payment Term”，它不是一個(gè)2000字的協(xié)議，只是說明30天付款還是60天付款。
給你看個(gè)圖：

#36樓    回復(fù)  引用  查看    

2005-05-09 16:46 by rIPPER     

payment term 的 term在這里翻譯作條款，還要搞清楚？

term
n.

1.
A. A limited period of time.
B. A period of time that is assigned to a person to serve: a six-year term as senator. See Synonyms at period.
C. A period when a school or court is in session.

2.
以下略 ...

你們那兒做l10n的太爛了，趕快建議老板辭掉他 :)

#37樓 [樓主]   回復(fù)  引用  查看    

2005-05-09 17:08 by 聽棠.NET     

老兄，在SAP里全都翻譯成“付款條款”的！！

你查了查字典就以為可以想翻什么就翻什么嗎？

不了解ERP也不至于要把老板炒了吧？？？

早知道我就把文章寫成Payment Term了，那估計(jì)你肯定知道是什么意思了。哦，你不信的話用Google搜一下吧。

#38樓    回復(fù)  引用  查看    

2005-05-09 18:35 by james wong     

Shit, 各人應(yīng)用的環(huán)境不一樣，各人的經(jīng)驗(yàn)也不一樣。干嘛爭來爭去的？哪個(gè)你用好了沒問題就是對的，否則就是錯(cuò)的。別人是對的你拿過來不一定是對的，別人是錯(cuò)的也不一定在你那里就也是錯(cuò)的。既然別人是對的你也不一定是對的，別人是錯(cuò)的你也不一定是錯(cuò)的，那這個(gè)問題也就是不對不錯(cuò)的。那么，那么還要討論誰對誰錯(cuò)做什么呢？？

打雷了。。下雨了。。。大家快收衣服啊。。。

#39樓    回復(fù)  引用  查看    

2005-05-09 19:17 by Arming     

在SAP里全都翻譯成“付款條款” ,這樣看起來應(yīng)該是沒有什么討論必要了。

#40樓    回復(fù)  引用  查看    

2005-05-09 19:39 by rIPPER     

原來是sap的l10n做得爛 ；） 不知道包給哪個(gè)公司做的，嘿嘿

#41樓    回復(fù)  引用  查看    

2005-05-09 20:49 by 知道得越多知道的越少     

"有道理喲，想問一下聽棠.NET，一個(gè)表里的字段數(shù)如果太多，你說有沒有問題，比如有張表TestTable，里面包含了60多個(gè)字段，你認(rèn)為這有不有問題？"

 字段多不是問題,你可以去看看SPS的數(shù)據(jù)表Userdata,微軟為每一種數(shù)據(jù)類型預(yù)留了64個(gè)字段,該表的字段數(shù)超過300個(gè),記錄數(shù)在100萬條以上,也沒有見嚴(yán)重影響性能.

很多時(shí)候,數(shù)據(jù)冗余是提升性能最有效的方法,特別是三個(gè)以上的表間聯(lián)接,通過數(shù)據(jù)冗余來改善性能是非常明顯的,同時(shí)也減小了SQL的復(fù)雜度.

#42樓    回復(fù)  引用  查看    

2005-05-09 21:33 by 一川煙草      

為什么會認(rèn)為ID不用保留呢？
如果要針對付款方式做統(tǒng)計(jì)，沒有ID,難道就用名稱來統(tǒng)計(jì)嗎？
例如某付款方式曾經(jīng)叫 牡丹卡（當(dāng)時(shí)工行只有一種卡） 后來增加了牡丹靈通卡，牡丹儲蓄卡，原來的牡丹卡名稱改為牡丹信用卡，但ID不變。
那么請問贊成不保留id的朋友，怎么統(tǒng)計(jì)訂單中付款方式為牡丹信用卡的總金額呢？

#43樓    回復(fù)  引用  查看    

2005-05-09 21:42 by 小陸     

冗余這樣的方式一般都用于提高系統(tǒng)的性能和增強(qiáng)系統(tǒng)的容錯(cuò)性，并且一般說來，冗余會增加開發(fā)的復(fù)雜度。在冗余數(shù)據(jù)之間進(jìn)行同步是需要耗費(fèi)精力的，要在開發(fā)團(tuán)體中形成一致的意見，并且要保持后來加入人員認(rèn)識的統(tǒng)一。這需要嚴(yán)明的紀(jì)律和充分的交流。如果一個(gè)數(shù)據(jù)只有一個(gè)來源，大家的認(rèn)識很容易一致。如果一個(gè)數(shù)據(jù)要保存在多個(gè)位置，則團(tuán)體的每個(gè)人中對一個(gè)數(shù)據(jù)的來源，更新的時(shí)候要不要同步，選取的時(shí)候到底從哪里取等一些事項(xiàng)上容易產(chǎn)生分歧，極易造成臟數(shù)據(jù)。
冗余要有明確的目的，不能貪圖一時(shí)之便，否則帶來的可能是麻煩。第三范式是一個(gè)正確的準(zhǔn)則，也許有時(shí)可以違背，但是一定要有一個(gè)更加強(qiáng)的準(zhǔn)則作為支持，要考慮具體的情況。這個(gè)更強(qiáng)的準(zhǔn)則，我想應(yīng)該不是“可以省一點(diǎn)事”。

#44樓 [樓主]   回復(fù)  引用  查看    

2005-05-09 22:29 by 聽棠.NET     

@小陸 :
現(xiàn)在我現(xiàn)在討論根本不是指你說的冗余，我所指的這種冗余是必須，根本不需要同步不同步的。因?yàn)橛唵蔚哪切┬畔⒕哂袣v史性。從一點(diǎn)上來說，你說的冗余是另一回事。

#45樓    回復(fù)  引用  查看    

2005-05-12 11:42 by 平常     

1我不想在訂單下達(dá)完以后，刪除了某條付款條款，導(dǎo)致這些訂單無法知道“真實(shí)的付款條款”了，這肯定不合理。
2我也不想，因?yàn)橄铝诉@張訂單了，而“嚴(yán)格控制”付款條款的“刪除”功能，這也不合理，憑啥不能刪除了？下個(gè)月這個(gè)“條款”確實(shí)永遠(yuǎn)不會采用了。
3我也不想，付款條款修改后，導(dǎo)致以前所有采用此付款條款的訂單都變成新的條款，那在系統(tǒng)中的訂單如何與手頭的紙張訂單再對應(yīng)，這肯定也不合理。

參照（Reference）
參照在數(shù)據(jù)庫設(shè)計(jì)中是一個(gè)比較復(fù)雜的問題，它是實(shí)現(xiàn)數(shù)據(jù)的完整性主要要素之一，詳細(xì)論述參考后面數(shù)據(jù)的約束。

在PowerDesigner中，可對參照完整性進(jìn)行各項(xiàng)設(shè)置，參照的基數(shù)從0到n，對修改和刪除約束可分別設(shè)置為None、Restrict、Cascade、Set Null、Set Default。由于INSERT包含在UPDATE操作中，因此沒有單獨(dú)的INSERT約束。

約束的不同設(shè)置產(chǎn)生不同的效果，以修改為例（刪除相同）：
None：父表修改，子表不影響。
Restrict：父表修改，如果子表存在，則出錯(cuò)。
Cascade：父表修改，如果子表存在，則相應(yīng)的修改。
Set Null：父表修改，如果子表存在，則相應(yīng)置空。
Set Default：父表修改，如果子表存在，則相應(yīng)置默認(rèn)值。

#46樓    回復(fù)  引用  查看    

2005-05-12 11:50 by 平常     

數(shù)據(jù)庫的完整性
數(shù)據(jù)庫完整性可通過存儲過程、聲明性參照完整性（DRI）、
數(shù)據(jù)類型、約束、規(guī)則、默認(rèn)值，以及觸發(fā)器來實(shí)現(xiàn)。在數(shù)據(jù)庫內(nèi)，這些功能各以特有的方式發(fā)揮作用。綜合利用這些完整性功能，可以使數(shù)據(jù)庫靈活，易于管理，而且很安全。
數(shù)據(jù)完整性概念分為幾個(gè)方面。
◆ 表域完整性
通過主鍵來強(qiáng)制表的域完整性。
◆ 引用完整性
利用參照來加強(qiáng)表之間的邏輯關(guān)系。
◆ 數(shù)值域完整性
任何輸入的數(shù)據(jù)在類型和范圍上必須與指定的數(shù)據(jù)類型相匹配，只有當(dāng)某列被說明允許NULL值，才允許向該列輸入NULL。
數(shù)據(jù)庫的性能測試
生成數(shù)據(jù)庫之后，應(yīng)進(jìn)行數(shù)據(jù)庫性能測試，以便優(yōu)化數(shù)據(jù)庫的設(shè)計(jì)，因此需要生成測試數(shù)據(jù)，由于是性能測試，數(shù)據(jù)的規(guī)范性要求不高。通過PowerDesigner可方便地生成測試數(shù)據(jù)（Generate Test Data），完成性能測試。
數(shù)據(jù)的約束
O-O約束
對父表的INSERT、UPDATE、DELETE操作沒有限制。
M-O約束
對父表操作的約束：
父表的INSERT操作，對M-O約束，父表中間的記錄可以沒有任何約束地添加到表中，因?yàn)檫@種約束中不一定必須有子女。
父表的鍵值修改操作，只有在子表中其所有的子女對應(yīng)均做修改后，才能修改，即一般采用級聯(lián)更新的方法。
父表的刪除，父親只有在其所有子女均被刪除或重新分配之后該父親才能被刪除。
強(qiáng)制對可選（M-O）約束
O-M約束
父表操作的約束：
父表的INSERT操作，對O-M約束，一個(gè)父親只有當(dāng)至少當(dāng)它的一個(gè)、子女同時(shí)被加入或至少存在一個(gè)合法的子女時(shí)，才能被加入。
父表的鍵值修改操作，只有當(dāng)一個(gè)子女被創(chuàng)建或已經(jīng)有一名子女存在才行。
父表的刪除，理論上刪除父親是沒有限制的，實(shí)際上，刪除主表記錄時(shí)，不采用級聯(lián)刪除子表的方案，而采用將子表的外鍵置空。
可選對強(qiáng)制（O-M）約束

M-M約束
父表操作的約束：
父表的INSERT操作，可能隨后需要生成子女，即在子表中創(chuàng)建新的行。也可能通過對子表的重新分配來實(shí)施完整行限制。
父表的鍵值修改操作，只有在子表對應(yīng)的外鍵的值修改成新值時(shí)才能進(jìn)行。實(shí)際可能是先創(chuàng)建新的父表紀(jì)錄，接著修改子表所有對應(yīng)的紀(jì)錄，使其與父表的新紀(jì)錄關(guān)聯(lián)，最后刪除原父表紀(jì)錄。
父表的刪除，只有在子表中所有相關(guān)的行全部刪除或重新分配之后，才能刪除父表中的紀(jì)錄，一般對子表也進(jìn)行刪除操作。
強(qiáng)制對強(qiáng)制（M-M）約束

在四類約束：M-M、M-O、O-M、O-O。鍵值的修改可能會改變表之間的關(guān)系，而且可能違反一些約束。違反約束的操作是不允許的。具體的應(yīng)用必須根據(jù)實(shí)際的要求和商業(yè)規(guī)則進(jìn)行適當(dāng)?shù)倪x擇。但在設(shè)計(jì)和開發(fā)時(shí)，必須考慮所分析的約束。

#47樓    回復(fù)  引用  查看    

2005-05-13 01:26 by magic007     

1、要看開發(fā)的這個(gè)系統(tǒng)是個(gè)什么樣的系統(tǒng)，僅僅是一個(gè)OLTP系統(tǒng)，或者還要在系統(tǒng)上進(jìn)行數(shù)據(jù)分析和數(shù)據(jù)挖掘。如果僅僅是一個(gè)事務(wù)處理系統(tǒng)，則以樓主所說的做法，行得通，否則的話，最好不要那樣做。
2、以我的經(jīng)驗(yàn)，數(shù)據(jù)冗余在開發(fā)上更方便一點(diǎn)，效率可能會高一點(diǎn)，但是后期可維護(hù)性和擴(kuò)展性是比較差的。
3、關(guān)系數(shù)據(jù)庫一個(gè)核心的理念應(yīng)該就是“關(guān)系”了，數(shù)據(jù)關(guān)系。設(shè)計(jì)數(shù)據(jù)庫，準(zhǔn)確的說是設(shè)計(jì)數(shù)據(jù)模型，一是保證整個(gè)數(shù)據(jù)模型具有良好的擴(kuò)展性，也就是說為以后業(yè)務(wù)的發(fā)展，需求的變化提供足夠的可擴(kuò)展性。開發(fā)的方便來說應(yīng)該是次要的，無非就是多點(diǎn)編碼。
4、在樓主的例子中，我從數(shù)據(jù)關(guān)系上談一下，訂單與客戶之間是很強(qiáng)的耦合關(guān)系，沒有客戶，那么訂單就沒有存在的意義。所以肯定是需要主外鍵關(guān)聯(lián)的。對于“付款條款”，在業(yè)務(wù)領(lǐng)域內(nèi)，對于訂單來說是必須具備的，那么也需要主外健關(guān)聯(lián)。比如客戶有同名的情況，怎么標(biāo)識多張相同客戶名的訂單是同一客戶還是不同的客戶？客戶改名了，如何標(biāo)識改名前的訂單和改名后的訂單是同一張訂單？為了避免在客戶改名后，改名前的訂單的客戶名變成新的客戶名，可以在客戶表中建立組合主鍵，如cust_id與cust_seq_id。

#48樓    回復(fù)  引用  查看    

2005-06-04 17:27 by 小李程序?     

感覺到有時(shí)冗余是有必要的，我相信這里講的冗余并不是為了提高系統(tǒng)的容錯(cuò)，它也不是我們在這里討論的范疇。我最關(guān)心的就是冗余帶來的性能上的提高，因?yàn)樗鼧O大地減少了在做交集運(yùn)算的時(shí)間。
況且這種冗余完全可以交個(gè)我們的DBA去做，我們只關(guān)系他提供給我們的數(shù)據(jù)即可，至于因?yàn)閿?shù)據(jù)冗余可能帶來的不一致，完全可以用觸發(fā)器來實(shí)現(xiàn)。

#49樓    回復(fù)  引用  查看    

2005-06-07 21:45 by shewo     

你把把客戶的名稱、聯(lián)系電話、付款條款名稱等訂單上要求記錄的信息直接COPY到訂單的表中，造成了“重復(fù)存儲”，重復(fù)存儲的結(jié)果就是數(shù)據(jù)冗余，冗余的結(jié)果很可能就是更新異常，因?yàn)橛锌赡苣愀铝丝蛻舯碇懈铝丝蛻舻拿Q、電話，你必須還要更新訂單中的相應(yīng)信息，反而造成了效率的下降，如果你疏忽忘記更新這些信息了，結(jié)果便是“數(shù)據(jù)不一致”。

#50樓 [樓主]   回復(fù)  引用  查看    

2005-06-08 08:20 by 聽棠.NET     

@shewo ：
老兄啊。你怎么還在講這個(gè)理論呢，前面的回復(fù)你看了嗎？我文章的主要目的就是寫給你這樣的人看的。
一般的人都是以為這樣想的，這個(gè)誰都知道，我的文章中也指出了，對于象訂單這種客觀存在的東西，不能死板的搬那種理論。
你說的這種數(shù)據(jù)不一致，你覺得需要保持嗎？已經(jīng)成為歷史的訂單，你認(rèn)為以后因?yàn)榛緮?shù)據(jù)的修改，需要全部修改進(jìn)去嗎？那么歷史訂單怎么辦？？客戶會把已經(jīng)完成的訂單存檔作為備案，你的意思是客戶還要把以前的訂單找出來一個(gè)個(gè)修改。。最好再理解一下我文章的意思。真沒想到，你什么也沒看懂。

#51樓    回復(fù)  引用  查看    

2005-06-13 13:20 by skyworht     

第三范式要求是屬性不依賴于其它非主屬性。我對編程還沒入門，只是瀏覽過幾個(gè)比較正規(guī)的軟件。我覺得兩種方法都是可行的，不過是應(yīng)用的環(huán)境要因?qū)嵍x。聽棠.NET方法對一些數(shù)據(jù)量較小、應(yīng)用中改變較為頻繁的數(shù)據(jù)，比較適用。外鍵引用，對無效標(biāo)記的方法在與上相反的情況下應(yīng)用也許更好。

拋磚引玉，各位指教。

#52樓    回復(fù)  引用  查看    

2005-06-13 21:01 by Peter     

"third normal form" should be used as a guideline to control the database design. I don't think the original design is against "third normal form". To copy extra information to "Order" such as payment term, delivery method etc, I think this is a correct way to do it as the author explained.

When you look at a design and to determine if it follows "third normal form" rule, there is a "time" factor in it. The original setting such as payment term and delivery method are the default setting, which don't determine every single order.

Another way to do it is to design a base level table that has a "time" factor it in.

Just some ideas and I found it's every hard to understand most comments here.

P.S. There is no right and wrong in relational database design, the only crieria is to test it in a real life situation.


P.

#53樓    回復(fù)  引用  查看    

2005-07-01 23:15 by min     

學(xué)習(xí)。。。

#54樓    回復(fù)  引用    

2005-08-04 15:54 by tx-zero [未注冊用戶]

終于看了一半，累死我了，呵呵。
看到大家都是在討論一個(gè)問題，就是碰到樓主的情況，
是1，copy保存，還是2，設(shè)置標(biāo)志的問題。

就我看，還得根據(jù)客戶業(yè)務(wù)的需要而決定。

我做過一些系統(tǒng)，由于是關(guān)系到一些企業(yè)內(nèi)部比較重要的資料。因此，客戶都要求操作要能夠恢復(fù)，當(dāng)然恢復(fù)是在一定的條件之下的。但是記錄客戶的操作還是必須的，并且需要記錄用戶操作了什么，改變了什么數(shù)據(jù)。

針對我說的這種客戶，我大多會采用，做標(biāo)志，并且copy的方法。
呵呵。
不寫了，寫得太多，別人看得也累，呵呵。

#55樓    回復(fù)  引用  查看    

2005-08-05 17:46 by kilnt     

學(xué)院派設(shè)計(jì)要死人的，維護(hù)冗余數(shù)據(jù)一樣也夠死人，這個(gè)要權(quán)衡了。

另：別看啥大系統(tǒng)，很多大系統(tǒng)細(xì)節(jié)技術(shù)實(shí)現(xiàn)很爛的，庫結(jié)構(gòu)也很爛。

#56樓    回復(fù)  引用    

2005-08-15 16:08 by nwc [未注冊用戶]

這個(gè)問題討論很激烈啊！我沒什么經(jīng)驗(yàn)，也想談點(diǎn)看法。
系統(tǒng)怎么設(shè)計(jì)？要不要冗余？要多少靈活性？這些都是和用戶需要
相關(guān)的。上面說到條款的改變和訂單的歷史性、一致性問題，既然
條款經(jīng)常要改變，為什么不做一個(gè)條款改變的歷史記錄表，其中有
條款不同版本的有效時(shí)間段和實(shí)際內(nèi)容，這樣每個(gè)訂單都有當(dāng)時(shí)的
條款內(nèi)容可查，只不過還是要加一個(gè)時(shí)間字段。新的訂單就用新的
條款內(nèi)容。
這種靈活性是增加了，不過復(fù)雜度也同樣增加了，減少冗余，就要
增加計(jì)算的時(shí)間。怎樣在效率與空間上取得平衡還是要看用戶的需
要了。

#57樓    回復(fù)  引用    

2005-08-15 16:39 by nwc [未注冊用戶]

原來peter說過了，我多嘴了。

#58樓    回復(fù)  引用    

2005-09-28 11:01 by 榴彈炮 [未注冊用戶]

上面的東西太多了,簡單發(fā)表一下看法:
1. 范式不是籠子,達(dá)不達(dá)成,要看情況;
2. 腦子里沒有范式的人去談上面這條,還是補(bǔ)了課再來;
3. 訂單上的數(shù)據(jù)冗余要看情況,如果要保存訂單的歷史紀(jì)錄而紀(jì)錄詳細(xì)的客戶信息,不算違反第三范式,因?yàn)榭蛻舯韮?nèi)的數(shù)據(jù)與訂單上表的歷史紀(jì)錄意義并不相同,用tag的方式來記錄歷史的客戶信息更不違反范式,但要看情況而定.因?yàn)闅v史的客戶信息可能與現(xiàn)有的客戶信息Code/name相同而違反鍵的約束,另外,由于單據(jù)要進(jìn)行EDI,保存詳細(xì)的客戶信息更加重要.
4. 純數(shù)據(jù)表(不參與EDI與證據(jù)紀(jì)錄)要嚴(yán)格遵守第三范式,否則數(shù)據(jù)一致性問題會讓你知道什么叫做"維護(hù)"!這個(gè)等式用空間換效率來寫太膚淺,應(yīng)該是用空間+編程錯(cuò)誤率+維護(hù)效率來換執(zhí)行效率+編程效率.
5. 再次打倒那些腦子里沒有范式的變態(tài)份子!我已經(jīng)快被他們的程序煩死了.

#59樓    回復(fù)  引用    

2005-09-28 12:45 by luckcp [未注冊用戶]

我認(rèn)為樓主說的應(yīng)該是標(biāo)準(zhǔn)引用，而本身就不應(yīng)該做成外鍵，所以不違反三范式。
以訂單為例：有兩個(gè)屬性分別是客戶與付款條例。客戶屬性應(yīng)該用外鍵做，而且盡量使用數(shù)據(jù)庫的外鍵機(jī)制（存在訂單引用的客戶不能刪除，不要設(shè)置為級聯(lián)刪除）。客戶信息的修改反映到訂單是應(yīng)該的（一條歷史訂單跟隨客戶名稱的變化而變化對查詢是沒有影響的，況且客戶資料的修改本身就應(yīng)該謹(jǐn)慎）。付款條例應(yīng)該做成一個(gè)付款標(biāo)準(zhǔn)表（標(biāo)準(zhǔn)引用），訂單存儲的是付款標(biāo)準(zhǔn)表的實(shí)際數(shù)據(jù)項(xiàng)。

#60樓    回復(fù)  引用  查看    

2005-11-08 23:37 by 綸巾客     

我覺得不違背“第三范式”也是可以的，一般來說，我們會有一張WasteBook表，記錄當(dāng)時(shí)的信息，保存歷史數(shù)據(jù)。這樣的話，既可以保證數(shù)據(jù)庫設(shè)計(jì)的規(guī)范，也可以提供靈活性。

#61樓    回復(fù)  引用  查看    

2006-05-07 17:22 by 月色瘋狂     

理論就是理論。要么就對，要么就不對。這個(gè)沒有什么可含糊的。
樓主的問題，實(shí)際上是個(gè)版本問題。每次條款修改，都會產(chǎn)生一個(gè)歷史版本。這個(gè)歷史版本是只讀的。并且是不可改變的。可以刪除某個(gè)條款，但是歷史是不能刪除的。因?yàn)樗灰昧恕?span lang="EN-US">
只要抽象出歷史版本的概念，就可以解決樓主所說的問題，并且可以不違反3nf。
歸根結(jié)底，還是樓主對業(yè)務(wù)的概念抽象得不對，不是3nf的問題。
對于類似的問題，都可以通過引入歷史版本的問題。在設(shè)計(jì)的時(shí)候就要考慮是引用對象本身，還是引用對象的歷史版本，不要把概念搞錯(cuò)了，更不要以此來懷疑3nf。

#62樓    回復(fù)  引用    

2007-01-30 16:16 by 雨恨云愁 [未注冊用戶]

個(gè)人強(qiáng)烈同意
上山砍柴去 的觀點(diǎn)

#63樓    回復(fù)  引用    

2007-08-28 09:30 by zhanglin [未注冊用戶]

第三范式在大的應(yīng)用系統(tǒng)，想完全遵循是不可能的。

#64樓    回復(fù)  引用    

2008-06-04 02:58 by solidco2 [未注冊用戶]

我比較贊同2樓的這種做法。如果你要查找用同樣的條款下的訂單怎么辦？也要復(fù)制過來吧。
那匯總更不用說了。
我認(rèn)為數(shù)據(jù)存入了數(shù)據(jù)庫，除了錯(cuò)誤的之外，理論上應(yīng)該永遠(yuǎn)不會被刪除。就像發(fā)生過的事無法抹去一樣。你可以把它塵封，但不能把它永遠(yuǎn)消除。
這一點(diǎn)也許是我從“自動編號”屬性得到的啟示。因?yàn)椋詣泳幪柈a(chǎn)生了#1，#2，刪掉#2，再產(chǎn)生也會是#3。這是因?yàn)?span lang="EN-US">dbms認(rèn)為這條記錄并沒有消失，只是你無法找回了。
扯多了，我確實(shí)同意你的結(jié)論，不得不違背范式，滿足范式的表會很羅索。倒庫的方法我其實(shí)用的不多，更多的是“啟用”字段，或者狀態(tài)字段。



--------------------------------------------------
嘿嘿: 范式原則是用于指導(dǎo)性地設(shè)計(jì)數(shù)據(jù)的存儲結(jié)構(gòu)的，僅僅只是理論。必要的時(shí)候是需要反范式，或者容忍一定的數(shù)據(jù)冗余，使得系統(tǒng)的性能或邏輯清晰性上更好。

范式是一種基于純粹的從數(shù)據(jù)存儲量上來優(yōu)化數(shù)據(jù)結(jié)構(gòu)的方式，并不是一個(gè)非常通用的東西。

另外：
“1我不想在訂單下達(dá)完以后，刪除了某條付款條款，導(dǎo)致這些訂單無法知道“真實(shí)的付款條款”了，這肯定不合理。
　2　我也不想，因?yàn)橄铝诉@張訂單了，而“嚴(yán)格控制”付款條款的“刪除”功能，這也不合理，憑啥不能刪除了？下個(gè)月這個(gè)“條款”確實(shí)永遠(yuǎn)不會采用了。”

上述情況，實(shí)際上可以考慮采用倉庫性質(zhì)的數(shù)據(jù)管理方法：即，對于所有的數(shù)據(jù)，分為可用與不可用，放在不同的表間，然后可以把其中的數(shù)據(jù)挪來挪去。

你說的情況非常現(xiàn)實(shí)，從業(yè)務(wù)角度出發(fā)，將數(shù)據(jù)結(jié)構(gòu)優(yōu)化為最高存儲效率的是沒有意義的，范式更多是一種指導(dǎo)，而不是原則。
--------------------------------------------------------

#65樓    回復(fù)  引用    

2008-06-04 03:32 by 還是上面那個(gè)人 [未注冊用戶]

不好意思沒有注意已經(jīng)是幾年前的討論了。
不過還是順便再提一下，保證是前面討論中都沒有說的：
一個(gè)公司在04年叫“河北科技有限公司”開始下訂單。記錄了。05年改名為“北方科技有限公司”，繼續(xù)下訂單。他們是一個(gè)公司嗎？查找這個(gè)公司的全部訂單怎么辦？
那就是還要記錄一個(gè)營業(yè)執(zhí)照號碼。這個(gè)營業(yè)執(zhí)照和ID就是等同地位了，為什么不用ID做一個(gè)唯一索引

#66樓    回復(fù)  引用    

2008-12-11 17:30 by 用版本控制來解決 [未注冊用戶]

月色瘋狂說的非常對，
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
“理論就是理論。要么就對，要么就不對。這個(gè)沒有什么可含糊的。
樓主的問題，實(shí)際上是個(gè)版本問題。每次條款修改，都會產(chǎn)生一個(gè)歷史版本。這個(gè)歷史版本是只讀的。并且是不可改變的。可以刪除某個(gè)條款，但是歷史是不能刪除的。因?yàn)樗灰昧恕?span lang="EN-US">
只要抽象出歷史版本的概念，就可以解決樓主所說的問題，并且可以不違反3nf。
歸根結(jié)底，還是樓主對業(yè)務(wù)的概念抽象得不對，不是3nf的問題。
對于類似的問題，都可以通過引入歷史版本的問題。在設(shè)計(jì)的時(shí)候就要考慮是引用對象本身，還是引用對象的歷史版本，不要把概念搞錯(cuò)了，更不要以此來懷疑3nf。”
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

其實(shí)這就和我們用cvs或subversion等版本控制系統(tǒng)一樣，應(yīng)該讓客戶表成為一個(gè)時(shí)間機(jī)器，只能進(jìn)行查詢和新增操作，而不可能進(jìn)行真正的刪除和修改操作，我的解決方案是對客戶表加三個(gè)字段：ID（Int類型），SerialID（自增，標(biāo)記版本），deletemark（boolean），對客戶表的修改就是新增一條ID相同的記錄，SerialID不同以反映版本，刪除就是標(biāo)記對應(yīng)ID的deletemark字段。

以上方案可以完美的解決樓主提出的問題，邏輯自洽且不違反范式要求。
同時(shí)也能解決
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
一個(gè)公司在04年叫“河北科技有限公司”開始下訂單。記錄了。05年改名為“北方科技有限公司”，繼續(xù)下訂單。他們是一個(gè)公司嗎？查找這個(gè)公司的全部訂單怎么辦？
那就是還要記錄一個(gè)營業(yè)執(zhí)照號碼。這個(gè)營業(yè)執(zhí)照和ID就是等同地位了，為什么不用ID做一個(gè)唯一索引
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
的問題，因?yàn)?span lang="EN-US">ID不變。

大家以為如何？