第一種方案：
表為兩張，一張分類表，一張資訊表。
表1：
`id` int(10),
`cid` tinyint(3) ,
`title` varchar(255),
表2：`cid` tinyint(3) ,
`parentid` tinyint(3)，
`order` tinyint(3) ,
`name` varchar(255),
這樣可以根據cid = parentid來判斷上一級內容，運用遞迴至最頂層 。
第二種方案：
設定parentid為varchar型別，將父類id都集中在這個欄位裡，用符號隔開，比如：1,3,6
這樣可以比較容易得到各上級分類的id，而且在查詢分類下的資訊的時候，可以使用如：select * from information where cid like "1,3%"。不過在新增分類和轉移分類的時候操作將非常麻煩。
第三種方案：
每級分類遞增兩位數字，這樣，每級分類的數目限定在100個之間，分類方法主要為編碼法；
示例：一級分類：01，02，03
二級分類：0101，0102，0103，0201，0202........
**分類：010101，010102，010103，010104..........
資料庫查詢時使用 like '01%'就可得到一級分類01下的所有子分類，非常方便！
如果要列出所有分類的樹型結構，只需用一條語句select * from pro_class order by code，再稍微處理一下就可。（其中，pro_class為產品分類表，code為類別編碼）。
設計的資料庫結構如下：
id: 類別id，主鍵
classname: 類名
classcode: 類別編碼
parent: 父id
left_child: 最左孩子id（或第乙個孩子）
right_sibling: 右兄弟id
layer: 層級（第一級類別為1，第2級類別2，以此類推）
以上三種的缺點？優點？還有其它方案嗎？
**：
選單無限級設計思路
這思路估計在高手眼中不算什麼 下面這個是乙個編碼無限級選單 id myselfcode 選單每級編號限制2位數字 這種思路方便排序 麻煩的是錄入編碼問題 需要在pojo中的新增屬性 而新增的屬性又不會對映到資料庫中 idmyselfcode parentcode 上級編碼 parentname 上級...
無限級選單簡單的設計
策略 資料庫就一張表，前端查詢出所有的可顯示的選單，在前端進行迴圈展示。create table sys menu id intnot null auto increment,name varchar 64 not null url varchar 255 pid intnot null defau...
動態表單資料庫設計
儲存結構去業務化 引數key value 通常系統引數就是這樣，很多配置項也是鍵值的。例如 分配比例，title，某某時間。碼表分為兩種 1 一種是沒有層級的 也就是用組就可以表達的。例如 性別，狀態。2 一種是有層級的 樹形的。例如 地域，樹形分類。樹形有些是無限層級的，有些也就是幾層。碼表分組 ...