主要是要有ID，PID兩個字段，下面是我用的一個表，僅供參考：
公司主營業(yè)務：成都網(wǎng)站設計、網(wǎng)站制作、外貿(mào)營銷網(wǎng)站建設、移動網(wǎng)站開發(fā)等業(yè)務。幫助企業(yè)客戶真正實現(xiàn)互聯(lián)網(wǎng)宣傳，提高企業(yè)的競爭能力。創(chuàng)新互聯(lián)是一支青春激揚、勤奮敬業(yè)、活力青春激揚、勤奮敬業(yè)、活力澎湃、和諧高效的團隊。公司秉承以“開放、自由、嚴謹、自律”為核心的企業(yè)文化，感謝他們對我們的高要求，感謝他們從不同領域給我們帶來的挑戰(zhàn)，讓我們激情的團隊有機會用頭腦與智慧不斷的給客戶帶來驚喜。創(chuàng)新互聯(lián)推出安徽免費做網(wǎng)站回饋大家。
CREATE TABLE [dbo].[Sys_Menu](
[ID] [int] NOT NULL,
[Code] [varchar](50) NOT NULL,
[PID] [int] NOT NULL,
[Name] [nvarchar](50) NULL,
[Url] [varchar](100) NULL,
[STATE] [bit] NOT NULL,
[IsSelected] [bit] NULL
) ON [PRIMARY]
GO
NoSQL太火，冒出太多產(chǎn)品了，保守估計也成百上千了。
互聯(lián)網(wǎng)公司常用的基本集中在以下幾種，每種只舉一個比較常見或者應用比較成功的例子吧。
1. In-Memory KV Store : Redis
in memory key-value store，同時提供了更加豐富的數(shù)據(jù)結(jié)構(gòu)和運算的能力，成功用法是替代memcached，通過checkpoint和commit log提供了快速的宕機恢復，同時支持replication提供讀可擴展和高可用。
2. Disk-Based KV Store: Leveldb
真正基于磁盤的key-value storage, 模型單一簡單，數(shù)據(jù)量不受限于內(nèi)存大小，數(shù)據(jù)落盤高可靠，Google的幾位大神出品的精品，LSM模型天然寫優(yōu)化，順序?qū)懕P的方式對于新硬件ssd再適合不過了，不足是僅提供了一個庫，需要自己封裝server端。
3. Document Store: Mongodb
分布式nosql，具備了區(qū)別mysql的最大亮點：可擴展性。mongodb 最新引人的莫過于提供了sql接口，是目前nosql里最像mysql的，只是沒有ACID的特性，發(fā)展很快，支持了索引等特性，上手容易，對于數(shù)據(jù)量遠超內(nèi)存限制的場景來說，還需要慎重。
4. Column Table Store: HBase
這個富二代似乎不用贅述了，最大的優(yōu)勢是開源，對于普通的scan和基于行的get等基本查詢，性能完全不是問題，只是只提供裸的api,易用性上是短板，可擴展性方面是最強的，其次坐上了Hadoop的快車，社區(qū)發(fā)展很快，各種基于其上的開源產(chǎn)品不少，來解決諸如join、聚集運算等復雜查詢。
找樹葉簡單啊
SELECT
*
FROM
表 main
WHERE
NOT EXISTS (
SELECT * FROM 表 sub WHERE main.ID = sub.ParentID
)
也就是對于 表的 每一行， 不存在有其他行的數(shù)據(jù)， ParentID 等于 當前行的 ID
with?a?as?(
select?pk_comp,name,pk_fathercomp?from?company
union
SELECT?pk_dept,deptname,(CASE?WHEN?pk_fathedept=0?THEN?pk_comp?ELSE?pk_fathedept?END)?as?pk_comp?FROM?dept)
select?a.name,b.name?from?a?as?b
inner?join?a?on?a.pk_comp=b.pk_fathercomp
create?table?T1(this?varchar(10),?parent?varchar(10))
insert?into?T1(this,parent)
values?('id1',null)
,('id2',null)
,('id3','id1')
,('id4','id2')
,('id5','id3')
,('id6','id3')
,('id7','id4')
,('id8','id7')
--?sql?server的cte功能
with?tree(this,parent,root,depth)?as?(
select?this,parent,?this?as?root,?1?as?depth?from?T1?where?parent?is?null
union?all
select?a.this,a.parent,?b.root,?b.depth+1?as?depth?from?T1?a,?tree?b?where?a.parent=b.this
)
select?this,parent,root,depth
from?tree
order?by?root,depth,this
