資料庫中許可權表的設定

今天被分配到看許可權表也就是平常我們所說的，User表，Role表以及User_Role表，今天碰到的問題是:

1.以前從未在資料庫設計中見過的資料型別

1.bit資料型別，以前在資料庫中真的沒用到過，只是知道這是一個位元位能夠表示的值有0或者1，但是
資料庫中式這麼顯示的

欄位'status' 就是bit型別儲存的時候他會被標記為b'1'，學習到了，儲存的時候正常儲存就可以，下
面我把表結構以及Sql貼出來

CREATE TABLE t_bit (
 id INT PRIMARY KEY,
 NAME VARCHAR(30),
 STATUS BIT, -- 主要是為了測試後面這個東西
 address VARCHAR(30)
)

INSERT INTO t_bit(NAME,STATUS,address) VALUES('小白',1,'哈爾濱');
 

2.下面我們來探討下為什麼要進行許可權控制以及為什麼要新增中間表

1.我們來看下不加中間表會出現哪些情況

我們需要分配的許可權如下:

a.張飛 -----> 武將

b.關羽 -----> 武將，軍師

c.趙雲 -----> 武將，軍師

d.馬超 -----> 武將

我們看圖以及對應關係就可以大概瞭解到

一個使用者可能對應多個角色，就像上面的趙雲既可以是武將又可以是軍師(我感覺他比較足智多謀)，同時，一個角色也可能被多個使用者所具有
就像上面的軍師這個角色，可以張飛，關羽，趙雲等角色所擁有，他們的關係就是 多對多的關係M:N(我們用 M:N 來表示多對多的關係).
 

2.1下面我們來嘗試下在M:N的情況下，建立兩張表會發生什麼

首先,我們來建立兩張表 User表與Role表

CREATE TABLE USER(
  userid INT PRIMARY KEY,
  NAME VARCHAR(30),
  roleid INT
 )

CREATE TABLE role(
  roleid INT PRIMARY KEY,
  NAME VARCHAR(30),
  userid INT
)

  -- 看看錶結構對不對,之後分別將 user表的userid 和 role表的roleid分別改為 主鍵自增
SELECT * FROM USER;
SELECT * FROM role;


-- 構造出上面所敘述的使用者所對應的角色
-- insert into USER(name,roleid)   出現的第一種小情況: 名義上的外來鍵不存在,我們>     也可以以後在新增這個roleid這個欄位

INSERT INTO USER(NAME) VALUES('張飛');
INSERT INTO USER(NAME) VALUES('關羽');
INSERT INTO USER(NAME) VALUES('趙雲');
INSERT INTO USER(NAME) VALUES('馬超');

INSERT INTO role(NAME) VALUES('武將');
INSERT INTO role(NAME) VALUES('軍師');  
 

之後我們表裡面的內容為如下所示:

+ 1.User表

• 2.Role表

2.2下面我們進行簡單的分析

-- 寫著寫著發現了一個問題，不應該將userid放置到role表中，如果說像我這麼設計的話，那麼roleid就不   能作為主鍵去使用
    -- 因為這樣做的話，就起不到唯一標識的作用打個比方，在role表中roleid = 1可以代表武將可以是張飛，roleid = 2可以代表軍師趙雲，
-- 那麼當我儲存roleid = 3時 我想存關羽的時候，我該怎麼去定義？無法去定義 解決的辦法有兩個 1. 將roleid當成非主鍵欄位 2.建立關係關聯表

-- 如果說採取第一種解決方法的話，那麼第一種隱藏的問題也就解決了，那就是一個使用者可能具有多個許可權，只需要按上role表那樣將userid欄位設定成非主鍵，就可以了
-- 但是這樣子存在一個問題:
--      表的結構會變得很複雜很複雜約產生M*N條資料

2.3如何解決這個問題

我們可以新增一張中間表，在前面我們已經知道了，User於Role是 M：N的關係，那麼我們就將關係變成這樣M:1於N:1的關係，是這樣的我們將User與Role的
兩張表不變，新增一箇中間表User_Role表

表結構如下:

分析下:建立中間表的好處以及為何會變成M：1以及N:1,就上面的例項進行分析，將結構進行分析

1.插入張飛以及其他角色的資訊並且查找出來

INSERT INTO user_role(userid,roleid) VALUES(1,1);
INSERT INTO user_role(userid,roleid) VALUES(2,1);
INSERT INTO user_role(userid,roleid) VALUES(2,2);          
INSERT INTO user_role(userid,roleid) VALUES(3,1);
INSERT INTO user_role(userid,roleid) VALUES(3,2);
INSERT INTO user_role(userid,roleid) VALUES(4,1);          

查詢語句如下:

SELECT u.`name`,r.`name` FROM USER u
LEFT JOIN user_role ur ON u.`userid` = ur.`userid`
LEFT JOIN role r ON ur.`roleid` = r.`roleid`;         

2.4 展示效果如下:

如果不動用中間表會產生的效果我們分析如下:
    1.User表與Role表會多產生id，以及分別對應出roldid與userid的欄位
    2.需要產生大約M*N個條資料
    3.表結構很垃圾(我也不知道怎麼解釋好)

動用了中間表的好處
    1.當新增一個新的Role的話,我們只需要在Role表中新增欄位，當User表中需要進行關係對映的時候我們僅僅需要在中間表中新增一條對映就好，
    假設新增一個Role為"驃騎將軍的角色"，僅僅需要在user_role表表新增一條關係對映就好了，很方便。

可以自己按照程式碼仔細體會下，僅僅是看沒什麼用，領悟一下就明白了。