在做資料庫設計時，擴充套件性是乙個必須考慮的問題。例如有這樣的乙個需求：乙個地區表，存在地區的層次關係是國家-->省州-->城市。一開始只有前面的兩層關係，我也沒多想，就直接設計成了如下的結構：
regionid country state
1 中國 北京
2 中國 江蘇
這種設計的擴充套件性很差，資料也冗餘，在加上city的話，就會出現
regionid country state city
1 中國 北京 北京
2 中國 江蘇 南京
3 中國 江蘇 蘇州
對於這樣的結構，設計時應該通過每條記錄間的關係反映層次關係，而不是在一條記錄中羅列的反映層次關係。正常的設計應該如下：
regionid parentid region
1 0 中國
2 0 法國
3 1 江蘇
4 3 南京
5 3 蘇州
這樣的設計，表的擴充套件會好一點，冗餘也少很多。
NoSql的易擴充套件性
nosql現在很火很時髦，大家言必稱nosql，彷彿關係型資料庫已成陳舊落後的代名詞。但依我看，真正理解nosql的還不多，在實際專案中用過的應該就更少了。我也還不理解，更沒怎麼應用過，所以現在要努力學習。在學習過程中，常看到有吹噓nosql相比較關係型資料庫而言，有乙個優點是 易擴充套件。這怎麼理...
Flume的可擴充套件性
flume的可擴充套件性 flume採用了三層架構，分別為agent，collector和storage，每一層均可以水平擴充套件。其中，所有agent和 collector由master統一管理，這使得系統容易監控和維護，且master允許有多個 使用zookeeper進行管理和負載均衡 這就避 ...
Flume的可擴充套件性
flume的可擴充套件性 flume採用了三層架構，分別為agent，collector和storage，每一層均可以水平擴充套件。其中，所有agent和 collector由master統一管理，這使得系統容易監控和維護，且master允許有多個 使用zookeeper進行管理和負載均衡 這就避 ...