當(dāng)然你也可以嘗試下面這種寫法，我個人認(rèn)為這種寫法更優(yōu)雅
- var contact = 上面的SQL語句取出來的用戶所有的聯(lián)系方式;
- txtWorkPhone.Text = (from a in contact
- where a.ContactMethod == ContactMethod.Work_Phone
- select a.ContactInfo).ToString();
- //后面以此類推，你懂的
|
注意，請不要試圖使用類似下面這類語句來查詢某用戶的聯(lián)系方式：
- select ContactInfo from 表 where UserRole=某種用戶類型 and OwnerID=某用戶ID and ContactMethod=1 //取出某用戶的Email
- select ContactInfo from 表 where UserRole=某種用戶類型 and OwnerID=某用戶ID and ContactMethod=8 //取出某用戶的HomePhone
|
相信我，這種做法非常愚蠢：每當(dāng)你要取出這個用戶的一種聯(lián)系方式，就要和數(shù)據(jù)庫建立一次連接，打開/關(guān)閉一次數(shù)據(jù)庫；這種做法代價是十分巨大的，即使有數(shù)據(jù)庫連接池，即使有數(shù)據(jù)庫緩存，都應(yīng)該避免這種愚蠢的做法.
唔，用了那么多的代碼，終于查出了某個用戶的聯(lián)系信息了。反正我個人覺得這種設(shè)計方式在查詢的時候，是邏輯上的浩劫。什么？你說你很享受？好吧，看來是我腦容量不夠……
不過當(dāng)我們面臨需求變動的時候，那就非常愉快了。
什么，要加一類用戶？簡單，UserRole加一個枚舉就好了。
什么，要加一種聯(lián)系方式？ContactMethod加一個枚舉就OK。
使用了這種表設(shè)計的時候，相信你會微笑著面對需求變動的
二逼青年
昨天和同事也探討了下這個問題，按他的說法就是：哪個表要聯(lián)系方式，我就扔個字段進(jìn)去，存json
| Contact | varchar(8000) | 用于儲存json |
舉例來說，有這么一個用戶：
| ID：1 | Name：張三 | Telphone：1234 | Email:123@123.com | Fax：5678 |
那么數(shù)據(jù)庫中就這樣存：
[{"ID":1,"Name":"張三","Telphone":"1234","Email":"123@123.com","Fax":"5678"}]
當(dāng)我聽到這種設(shè)計思路的時候，虎軀微微一震：靠，這都行。按這種設(shè)計，我整張表都放進(jìn)一個json里面一股腦的存進(jìn)去就算了。不過震驚之后仔細(xì)想一想，其實(shí)這種設(shè)計也是有可取之處
首先，從查詢來說，和普通青年一樣，只需一句SQL：
| select Contact from 表 where 條件 |
查詢之后，就可以通過json處理函數(shù)將想要的數(shù)據(jù)取出來，在此就不贅述了
那么當(dāng)面臨需求變動的時候會發(fā)生什么：
加一類用戶的時候，要添加一張表。也是符合開閉原則，原有代碼沒有改動。
加一種聯(lián)系方式，只用存json的時候多存一點(diǎn)東西。
不過這種設(shè)計如果要更新某條數(shù)據(jù)的話要稍微麻煩一點(diǎn)：先查詢一條數(shù)據(jù)，重組json之后再Update。
寫了那么多，希望已經(jīng)將想要表達(dá)的問題表達(dá)清楚了。不足之處望海涵，也歡迎留言斧正。
PS：真的是一個規(guī)律，一個月才能寫出一篇博客……
再PS：就快能回家了，高興，開心。