建站
咨詢
售后
建站咨詢
新聞中心
在《我們?cè)撊绾卧O(shè)計(jì)數(shù)據(jù)庫（二）》中，園友Jacklondon Chen提出了一些問題，大致如下：
創(chuàng)新互聯(lián)專注于平城網(wǎng)站建設(shè)服務(wù)及定制，我們擁有豐富的企業(yè)做網(wǎng)站經(jīng)驗(yàn)。 熱誠為您提供平城營銷型網(wǎng)站建設(shè)，平城網(wǎng)站制作、平城網(wǎng)頁設(shè)計(jì)、平城網(wǎng)站官網(wǎng)定制、微信小程序開發(fā)服務(wù)，打造平城網(wǎng)絡(luò)公司原創(chuàng)品牌,更為您提供平城網(wǎng)站排名全網(wǎng)營銷落地服務(wù)。
“man/woman應(yīng)該設(shè)計(jì)在同一張表中。 用戶表大多都設(shè)計(jì)成一個(gè)表。連分 administrator 和 user 都不應(yīng)該?！?/p>
我想還是因?yàn)槲遗e例太隨意，因?yàn)椴┪闹蠱an和Woman只有4個(gè)差異屬性：HasCar\HasHouse\HasMoney，以及IsBeauty。
其實(shí)對(duì)于這個(gè)問題我無力吐槽什么，簡單的說說吧：假設(shè)為Man用戶實(shí)現(xiàn)的是一個(gè)征婚系統(tǒng)，而Woman用戶實(shí)現(xiàn)的是一個(gè)選美系統(tǒng)。這么說應(yīng)該能理解Man和Woman的不能并同一張表的原因了吧。
廢話說完，正文開始
現(xiàn)在有一個(gè)系統(tǒng)，我們暫時(shí)假設(shè)為學(xué)校選課系統(tǒng)。有兩類用戶Teacher和Student，還有一張Curriculum表是課程總表，來儲(chǔ)存學(xué)校一共有哪些課程，每門課的學(xué)分什么的。然后一個(gè)老師，一門課程和多名學(xué)生，就可以開始上課了。
表結(jié)構(gòu)如下圖：
邏輯很簡單，一目了然。
但是問題在于，我們的系統(tǒng)要按學(xué)校來賣。每個(gè)學(xué)校的選課邏輯都是一樣的，而表中的數(shù)據(jù)有共性，但是也有差異性。比如說基本的Teacher表結(jié)構(gòu)是這樣的：
現(xiàn)在把系統(tǒng)賣給A學(xué)校。A學(xué)校除了的Teacher表除了用戶名和密碼之外，還要儲(chǔ)存老師的FirstName和LastName，那么表結(jié)構(gòu)變化如下：
現(xiàn)在B學(xué)校也買了我們的系統(tǒng)。他們的Teacher表不要FirstName和LastName，但是要儲(chǔ)存教師的工號(hào)“Number”，表結(jié)構(gòu)如下：
好，現(xiàn)在我們的問題出來了：怎么去解決這種差異性。
最簡單的思路莫過于表中加冗余字段。比如說將表設(shè)計(jì)成這樣：
如果我們的系統(tǒng)只賣兩三個(gè)學(xué)校，這樣是可行的。但是打個(gè)比方，我們的系統(tǒng)賣了30所學(xué)校，每個(gè)學(xué)校有一個(gè)自己的差異字段，那么這個(gè)表就要有30個(gè)冗余字段來應(yīng)對(duì)這種差異性。且不說每次加冗余都要改動(dòng)系統(tǒng)，且不說冗余多了浪費(fèi)空間降低傳輸效率，光說怎么維護(hù)這些冗余，我就已經(jīng)覺得是災(zāi)難了：Teacher表有差異字段，其他表也會(huì)有。假設(shè)一個(gè)中型系統(tǒng)，60張表，其中30張實(shí)體表30張關(guān)系表不算過分吧。那么總共要維護(hù) 30（表數(shù)量）*30（冗余數(shù)量）= 900 個(gè)差異字段。
第二個(gè)想法是建立一張冗余表來儲(chǔ)存差異。這種其實(shí)和表中加冗余異曲同工，就不多加分析了，留給大家自己思考。
第三個(gè)想法是建立不同的數(shù)據(jù)庫。其實(shí)本來每個(gè)學(xué)校的數(shù)據(jù)庫就是不同的，唔……怎么說呢，A學(xué)校自己的數(shù)據(jù)庫中的表，存的是A學(xué)校自己的特有字段，B學(xué)校存B學(xué)校的特有字段。兩者之間并無關(guān)系，然后Model用l繼承的思路來設(shè)計(jì)（詳見上一篇文章），通過配置文件來選擇恰當(dāng)?shù)臄?shù)據(jù)庫和其對(duì)應(yīng)的Model。
是的，這種方法挺好的，唯一的不足可能就是比較依賴于ORM——使用ORM來生成數(shù)據(jù)庫，以及T-SQL語句。
如果您是一個(gè)關(guān)系型數(shù)據(jù)庫的重度愛好者，那么這篇文章到這就結(jié)束了，下面的東西不會(huì)對(duì)您胃口的。
眾所周知，因?yàn)榇罅渴褂昧朔瓷?，ORM的效率不是那么的高，而且本身關(guān)系型數(shù)據(jù)庫的可拓展性也不是那么的好。
作為一個(gè)激進(jìn)的開發(fā)者，我一直希望在項(xiàng)目中嘗試NoSql。
下面的一篇文章我會(huì)講解如何用MongoDB來解決前文描述的差異性問題，敬請(qǐng)期待。
順便附上一個(gè)小測試：在.net 4環(huán)境下分別插入5W條數(shù)據(jù)，分別是EF5、Nhibernate、ADO.Net向Sql server 2008插入，以及MongoDB官方驅(qū)動(dòng)向MongoDB插入。
EF耗時(shí):00:00:25.4972758
ADO.NET耗時(shí):00:00:23.8307860
NHibernate耗時(shí):00:00:26.0199898
MongoDB耗時(shí):00:00:01.9474134
在這里，EF每次插入1000條數(shù)據(jù)（批量插入），其他方式都是單條插入；NHibernate關(guān)閉了一級(jí)緩存；
MongoDB使用的是“離弦之箭”的插入方式。
MongoDB使用的是安全的插入模式（不會(huì)丟失數(shù)據(jù)）。
分享題目：我們?cè)撊绾卧O(shè)計(jì)數(shù)據(jù)庫(三)
分享網(wǎng)址：http://www.5511xx.com/article/djjgjeo.html
