資料庫中和

❶ 資料庫中char和varchar的區別

char是一種固定長度的類型，varchar則是一種可變長度的類型，它們的區別是：
char(m)類型的數據列里，每個值都佔用m個位元組，如果某個長度小於m，mysql就會在它的右邊用空格字元補足．（在檢索操作中那些填補出來的空格字元將被去掉）在varchar(m)類型的數據列里，每個值只佔用剛好夠用的位元組再加上一個用來記錄其長度的位元組（即總長度為l+1位元組）．
在mysql中用來判斷是否需早棚要進行對據列類型轉換的規則
1、在一個數據表裡，如果每一個數據列的長度都是固定的，那麼每一個數據行的長度也將是固定的．
2、只要數據表裡有一個數據列的脊睜帆長度的可變的，那麼各數據行的長度都是可變的．
3、如櫻雹果某個數據表裡的數據行的長度是可變的，那麼，為了節約存儲空間，mysql會把這個數據表裡的固定長度類型的數據列轉換為相應的可變長度類型．
例外：長度小於4個字元的char數據列不會被轉換為varchar類型

❷ 資料庫中Schema和Database有什麼區別

在MySQL中創建一個Schema好像就跟創建一個Database是一樣的效果，在SQLServer和Orcal資料庫中好像又不一樣.目前我只能理解，在mysql中schema<==>database。x0dx0ax0dx0a資料庫中User和Schema的關系x0dx0a假如我們想了解資料庫中的User和Schema究竟是什麼關系，首先必須了解一下資料庫中User和Schema到底是什麼概念。x0dx0ax0dx0a在SQLServer2000中，由於架構的原因，User和Schema總有一層隱含的關系，讓我們很少意識到其實User和Schema是兩種完全不同的概念，不過在SQLServer2005中這種架構被打破了，User和Schema也被分開了。x0dx0ax0dx0ax0dx0a首先我來做一個比喻，什麼是Database，什麼是Schema，什麼是Table，什麼是列，什麼是行，什麼是User？我們可以可以把x0dx0aDatabase看作是一個大倉庫，倉庫分了很多很多的房間，Schema就是其中的房間，一個Schema代表一個房間，Table可以看作是每個x0dx0aSchema中的床，Table（床）就被放入每個房間中，不能放置在房間之外，那豈不是晚上睡覺無家可歸了J。，然後床上可以放置很多物品，就好比x0dx0aTable上可以放置很多列和行一樣，資料庫中存儲數據的基本單元是Table，現實中肆薯每個倉庫放置物品的基本單位就是床，x0dx0aUser就是每個Schema的主人，（所以Schema包含的是Object，而不是User），其實User是對應與資料庫的（即User是每個對應x0dx0a資料庫的主人），既然有操作資料庫（倉庫）的權利，就肯定有操作資料庫中每個Schema（房間）的權利，就是說每個資料庫映射的User有每個x0dx0aSchema（房間）的鑰匙，換句話說，如果他是某個倉庫的主人，那麼這個倉庫的使用權和倉庫中的所有東西都是他的（包括房間），他有完全的操作權，可以x0dx0a扔掉不用的東西從每個房間，也可以放置一些有用的東西到某一個房間，呵呵，和現實也太相似了吧。我還可以給User分配具體的許可權，也就是他到某一個房間x0dx0a能做些什麼，是只能看（Read-Only），還是可以像主人一樣有所有的控制權（R/W），這個就要看這個User所對應的角色Role了，至於分配權x0dx0a限的問題，我留在以後單獨的blog中詳述。比喻到這里，相信大家都清楚了吧。x0dx0ax0dx0a在SQLServer2000中，假如我們在某一個資料庫中創建了用戶Bosco，按么此時後台也為我們默認地創建了默認Schema【Bosco】。Schema的名字和User的名字相同，這也是我們分不清楚用戶和Schema的原因。x0dx0ax0dx0ax0dx0a在SQLServer2005中，為了向後兼容，當你用sp_adser存儲過程創建一個用戶的時候，SQLx0dx0aServer2005同時也創建了一游槐個和用戶名相同的Schema，然而這個存儲過程是為了向後兼容才保留的，我們應該逐漸熟悉用新的DDL語言x0dx0aCreateUser和CreateSchema來操作資料庫。在SQLServer2005中，當我們用Createx0dx0aUser創建資料庫用戶時，我們可以為該用戶指定一個已經存在的Schema作為默認Schema，如果我們不指定，則該用戶所默認的Schema即為x0dx0adboSchema，dbox0dx0a房間（Schema）好比一個大的公共房間，在當前登錄用戶沒有默認Schema的前提下，如果你在大倉庫中進行一些操作，比如Createx0dx0aTabe，如果沒有指定特定的房間（Schema），那麼你的物品就只好放進公共的dbo房間（Schema）了。但是如果當前登錄裂磨者用戶有默認的x0dx0aSchema，那麼所做的一切操作都是在默認Schema上進行（比如當前登錄用戶為login1，該用戶的默認Schema為login1，那麼所做的x0dx0a所有操作都是在這個login1默認Schema上進行的。實驗已經證明的確如此）。估計此時你會有一點暈，為什麼呢？我剛才說dbo是一個x0dx0aSchema，但是你可以在資料庫中查看到，dbo同時也是一個user，暈了吧，呵呵。x0dx0ax0dx0a在SQLServer2005中創建一個資料庫的時候，會有一些Schema包括進去，被包括進去的Schema有：dbo，INFORMATION_SCHEMA,guest，sys等等（還有一些角色Schema，不提了，有暈了）。x0dx0ax0dx0ax0dx0a我在上文中已經提到了，在SQLServer2005中當用存儲過程sp_adser創建一個user時，同時SQLx0dx0aServer2005也為我們創建了一個默認的和用戶名相同的Schema，這個時候問題出來了，當我們createtablex0dx0aA時，如果沒有特定的Schema做前綴，這個A表創建在了哪個Schema上，即進入了哪個房間？答案是：x0dx0ax0dx0a1.如果當前操作資料庫的用戶（可以用Selectcurrent_user查出來）有默認的Schema（在創建用戶的時候指定了），那麼表A被創建在了默認的Schema上。x0dx0ax0dx0ax0dx0a2.如果當前操作資料庫的用戶沒有默認的Schema（即在創建User的時候默認為空），但是有一個和用戶名同名的Schema，那麼表A照樣被創建x0dx0a在了dbox0dx0aSchema上，即使有一個和用戶名同名的Schema存在，由於它不是該用戶默認的Schema，所以創建表的時候是不會考慮的，當作一般的x0dx0aSchema來處理，別看名字相同，可是沒有任何關系哦。x0dx0ax0dx0a3.如果在創建表A的時候指定了特定的Schema做前綴，則表A被創建在了指定的Schema上（有許可權嗎？）x0dx0ax0dx0ax0dx0a現在問題又出來了，在當前操作資料庫的用戶（用selectx0dx0acurrent_user可以查看到，再次強調）沒有默認Schema的前提下，當我們用CreatetableA語句時，A表會去尋找dbox0dx0aSchema，並試圖創建在dboSchema上，但是如果創建A表的用戶只有對dbox0dx0aSchema的只讀許可權，而沒有寫的許可權呢？這個時候A表既不是建立不成功，這個就是我以後會提及到的Login,User,x0dx0aRole和Schema四者之間的關系。在這里，為了避免混淆和提高操作資料庫的速度（在少量數據范圍內，對我們肉眼來說幾乎看不到差異），我們最好每次x0dx0a在操作資料庫對象的時候都顯式地指定特定的Schema最為前綴。x0dx0ax0dx0a現在如果登錄的用戶為Sue，該用戶有一個默認Schema也為Sue，那麼如果現在有一條查詢語句為Select*frommytable,那麼搜尋每個房間（Schema）的順序是怎樣的呢？順序如下：x0dx0ax0dx0a1.首先搜尋sys.mytable（SysSchema）x0dx0ax0dx0a2.然後搜尋Sue.mytable(DefaultSchema)x0dx0ax0dx0a3.最後搜尋dbo.mytable(DboSchema)x0dx0ax0dx0a執行的順序大家既然清楚了，那麼以後在查詢資料庫表中的數據時，最好指定特定的Schema前綴，這樣子，資料庫就不用去掃描SysSchema了，當然可以提高查詢的速度了。x0dx0ax0dx0a另外需要提示一下的是，每個資料庫在創建後，有4個Schema是必須的（刪都刪不掉），這4個Schema為：dbo，guest，sys和INFORMATION_SCHEMA，其餘的Schema都可以刪除。

❸ 資料庫中的集群和F5

分布式資料庫系統分布式資料庫系統有兩種：一種是物理上分布的，但邏輯上卻是集中的。這種分布式資料庫只適宜用途比較單一的、不大的單位或部門。另一種分布式資料庫系統在物理上和邏輯上都是分布的，也就是所謂聯邦式分布資料庫系統。由於組成聯邦的各個子資料庫系統是相對「自治」的，這種系統可以容納多種不同用途的、差異較大的資料庫，比較適宜於大范圍內資料庫的集成。
----- ----
分布式資料庫系統(DDBS)包含分布式資料庫管理系統(DDBMS)和分布式資料庫(DDB)。在分布式資料庫系統中，一個應用程序可以對資料庫進行透明操作，資料庫中的數據分別在不同的局部資料庫中存儲、由不同的 DBMS進行管理、在不同的機器上運行、由不同的操作系統支持、被不同的通信網路連接在一起。
一個分布式資料庫在邏輯上是一個統一的整體，在物理上則是分別存儲在不同的物理節點上。一個應用程序通過網路的連接可以訪問分布在不同地理位置的資料庫。它的分布性表現在資料庫中的數據不是存儲在同一場地。 更確切地講，不存儲在同一計算機的存儲設備上。 這就是與集中式資料庫的區別。從用戶的角度看，一個分布式資料庫系統在邏輯上和集中式資料庫系統一樣，用戶可以在任何一個場地執行全局應用。就好那些數據是存儲在同一台計算機上，有單個資料庫管理系統(DBMS)管理一樣，用戶並沒有什麼感覺不一樣。
分布式資料庫系統是在集中式資料庫系統的基礎上發展起來的，是計算機技術和網路技術結合的產物。分布式資料庫系統適合於單位分散的部門，允許各個部門將其常用的數據存儲在本地，實施就地存放本地使用，從而提高響應速度，降低通信費用。分布式資料庫系統與集中式資料庫系統相比具有可擴展性，通過增加適當的數據冗餘，提高系統的可靠性。在集中式資料庫中，盡量減少冗餘度是系統目標之一．其原因是，冗餘數據浪費存儲空間，而且容易造成各副本之間的不一致性．而為了保證數據的一致性，系統要付出一定的維護代價．減少冗餘度的目標是用數據共享來達到的。而在分布式資料庫中卻希望增加冗餘數據，在不同的場地存儲同一數據的多個副本,其原因是：①．提高系統的可靠性、可用性當某一場地出現故障時，系統可以對另一場地上的相同副本進行操作，不會因一處故障而造成整個系統的癱瘓。②．提高系統性能系統可以根據距離選擇離用戶最近的數據副本進行操作，減少通信代價，改善整個系統的性能。
分布式資料庫具有以下幾個特點：
(1)、數據獨立性與位置透明性。數據獨立性是資料庫方法追求的主要目標之一，分布透明性指用戶不必關心數據的邏輯分區，不必關心數據物理位置分布的細節，也不必關心重復副本（冗餘數據）的一致性問題，同時也不必關心局部場地上資料庫支持哪種數據模型．分布透明性的優點是很明顯的．有了分布透明性，用戶的應用程序書寫起來就如同數據沒有分布一樣．當數據從一個場地移到另一個場地時不必改寫應用程序．當增加某些數據的重復副本時也不必改寫應用程序．數據分布的信息由系統存儲在數據字典中．用戶對非本地數據的訪問請求由系統根據數據字典予以解釋、轉換、傳送．
(2)、集中和節點自治相結合。資料庫是用戶共享的資源．在集中式資料庫中，為了保證資料庫的安全性和完整性，對共享資料庫的控制是集中的，並設有DBA負責監督和維護系統的正常運行．在分布式資料庫中，數據的共享有兩個層次：一是局部共享，即在局部資料庫中存儲局部場地上各用戶的共享數據．這些數據是本場地用戶常用的．二是全局共享，即在分布式資料庫的各個場地也存儲可供網中其它場地的用戶共享的數據，支持系統中的全局應用．因此，相應的控制結構也具有兩個層次：集中和自治．分布式資料庫系統常常採用集中和自治相結合的控制結構,各局部的DBMS可以獨立地管理局部資料庫，具有自治的功能．同時，系統又設有集中控制機制，協調各局部DBMS的工作，執行全局應用。當然,不同的系統集中和自治的程度不盡相同．有些系統高度自治，連全局應用事務的協調也由局部DBMS、局部DBA共同承擔而不要集中控制，不設全局DBA,有些系統則集中控製程度較高，場地自治功能較弱。
(3)、支持全局資料庫的一致性和和可恢復性。分布式資料庫中各局部資料庫應滿足集中式資料庫的一致性、可串列性和可恢復性。除此以外還應保證資料庫的全局一致性、並行操作的可串列性和系統的全局可恢復性。這是因為全局應用要涉及兩個以上結點的數據．因此在分布式資料庫系統中一個業務可能由不同場地上的 多個操作組成．例如, 銀行轉帳業務包括兩個結點上的更新操作。這樣，當其中某一個結點出現故障操作失敗後如何使全局業務滾回呢？如何使另一個結點撤銷已執行的操作(若操作已完成或完成一部分）或者不必再執行業務的其它操作(若操作尚沒執行)？這些技術要比集中式資料庫復雜和困難得多，分布式資料庫系統必須解決這些問題．
(4)、復制透明性。用戶不用關心資料庫在網路中各個節點的復制情況，被復制的數據的更新都由系統自動完成。在分布式資料庫系統中，可以把一個場地的數據復制到其他場地存放，應用程序可以使用復制到本地的數據在本地完成分布式操作，避免通過網路傳輸數據，提高了系統的運行和查詢效率。但是對於復制數據的更新操作，就要涉及到對所有復制數據的更新。
(5)、易於擴展性。在大多數網路環境中，單個資料庫伺服器最終會不滿足使用。如果伺服器軟體支持透明的水平擴展，那麼就可以增加多個伺服器來進一步分布數據和分擔處理任務。
分布式資料庫的優點：
(1)具有靈活的體系結構 。
(2)適應分布式的管理和控制機構。
(3)經濟性能優越 。
(4)系統的可靠性高、可用性好 。
(5)局部應用的響應速度快。
(6)可擴展性好，易於集成現有系統。
分布式資料庫的缺點：
(1)系統開銷大，主要花在通信部分。
(2)復雜的存取結構，原來在集中式系統中有效存取數據的技術，在分成式系統中都不再適用。
(3)數據的安全生和保密性較難處理。
分布式資料庫系統的目標
分布式資料庫系統的目標，也就是研製分布式資料庫系統的目的、動機，主要包括技術和組織兩方面的目標．
1．適應部門分布的組織結構，降低費用。
使用資料庫的單位在組織上常常是分布的（如分為部門、科室、車間等等），在地理上也是分布的．分布式資料庫系統的結構符合部門分布的組織結構，允許各個部門對自己常用的數據存儲在本地，在本地錄入、查詢、維護，實行局部控制．由於計算機資源靠近用戶，因而可以降低通信代價，提高響應速度，使這些部門使用資料庫更方便更經濟。
2．提高系統的可靠性和可用性。
改善系統的可靠性和可用性是分布式資料庫的主要目標．將數據分布於多個場地，並增加適當的冗餘度可以提供更好的可靠性．一些可靠性要求較高的系統，這一點尤其重要．因為一個地出了故障不會引起整個系統崩潰．因為故障場地的用戶可以通過其它場地進入系統．而其它場地的用戶可以由系統自動選擇存取路徑，避開故障場地，利用其它數據副本執行操作，不影響業務的正常運行．
3．充分利用資料庫資源，提高現有集中式資料庫的利用率
當在一個大企業或大部門中已建成了若干個資料庫之後，為了利用相互的資源，為了開發全局應用，就要研製分布式資料庫系統．這種情況可稱為自底向上的建立分布式系統．這種方法雖然也要對各現存的局部資料庫系統做某些改動、重構，但比起把這些資料庫集中起來重建一個集中式資料庫，則無論從經濟上還是從組織上考慮，分布式資料庫均是較好的選擇．
4．逐步擴展處理能力和系統規模
當一個單位規模擴大要增加新的部門(如銀行系統增加新的分行，工廠增加新的科室、車間)時，分布式資料庫系統的結構為擴展系統的處理能力提供了較好的途徑：在分布式資料庫系統中增加一個新的結點．這樣做比在集中式系統中擴大系統規模要方便、靈活、經濟得多。
在集中式系統中為了擴大規模常用的方法有兩種：一種是在開始設計時留有較大的餘地．這容易造成浪費，而且由於預測困難，設計結果仍可能不適應情況的變化．另一種方法是系統升級，這會影響現有應用的正常運行．並且當升級涉及不兼容的硬體或系統軟體有了重大修改而要相應地修改已開發的應用軟體時，升級的代價就十分昂貴而常常使得升級的方法不可行．分布式資料庫系統能方便地把一個新的結點納入系統，不影響現有系統的結構和系統的正常運行，提供了逐漸擴展系統能力的較好途徑，有時甚至是唯一的途徑。
①資料庫系統與應用 趙致格編著 清華大學出版社p. 260
②資料庫原理及應用 張晉連 編著 電子工業出版社P.13

❹ 資料庫中表分割和表分區的區別是什麼

個人認為理論上使用表分割在性能上應該和建立表分區查不多，但是，表分割對於所有的資料庫都適用，而表分區只能用於oracle這樣的特定的資料庫；表分區屬於資料庫物理設計，表分割屬於邏輯設計。
表分區：
表分區是ORACLE對於非常大的表進行優化的一種有效方法, 是非常有效的一種手段, 在很多情況下,比你說的表分割更有效,比如,有一個代碼表,使用分區表把100萬紀錄分在10個分區中(ID 每從1到10萬為一個分區),那樣寫查詢語句的時候,只要給出查詢條件中所需要的代碼,ORACLE自動會定位到對應的分區進行查詢,大大降低的查詢時間. 而採用表分割,那必須先根據查詢的代碼指定所要查詢的表,才能找到相應的紀錄. 而且,如果有下面這樣的語句,查詢的條件是跨分區的:
SELECT * FROM MYTABLE WHERE ID BETWEEN 99000 AND 10111;
在分區表中是非常容易實現的,ORACLE會自動在兩個分區中查詢;而採用表分割的話是否必須寫成兩個查詢語句在UNION ALL。
事實上,大型的資料庫都有對大表的特殊處理方式(類似於分區表),如果太強調可移植性而放棄這些最重要的特性的話,那性能很可能受到很大的影響.
即便是oracle資料庫，當數據量很大時，用分表比用表分區要快些，尤其是在表用到group by求和等操作。
我也認為表分區要好一些，也就是一般說來的分區表，對這些表操作起來有很多強大的功能，說他強大主要是體現在對與表中有海量數據的情況之下的，試問大家一個其中有1億條記錄的表你是否會經常的將其移植到其他資料庫系統當中去呢？
表分區基於物理存儲，還有就是基於分區的索引可以使用，很不錯的，當然，這些都是在海量數據情況之下的比較，但是如果真要是數據量不大的情況下比較，我想要比較分區表和表分割就沒什麼意思了。
表分區的效果對硬體有所依賴，而且效果恐怕不如諸位想像中那麼好。我做過一點測試，很失望。
而表分割的效率提升在很多時候（不是所有時候）是很明顯的。
當然這都是在巨型表的前提下討論，縮小表和索引的規模有利於提高效率，這正是分割表的特點。
表分割：
1、水平分割：根據一列或多列數據的值把數據行放到兩個獨立的表中。
水平分割通常在下面的情況下使用:A 表很大，分割後可以降低在查詢時需要讀的數據和索引的頁數，同時也降低了索引的層數，提高查詢速度。B 表中的數據本來就有獨立性，例如表中分別記錄各個地區的數據或不同時期的數據，特別是有些數據常用，而另外一些數據不常用。C需要把數據存放到多個介質上。
例如法規表law就可以分成兩個表active－law和 inactive－law。activea－authors表中的內容是正生效的法規，是經常使用的，而inactive－law表則使已經作廢的法規，不常被查詢。水平分割會給應用增加復雜度，它通常在查詢時需要多個表名，查詢所有數據需要union操作。在許多資料庫應用中，這種復雜性會超過它帶來的優點，因為只要索引關鍵字不大，則在索引用於查詢時，表中增加兩到三倍數據量，查詢時也就增加讀一個索引層的磁碟次數。
2、垂直分割：把主碼和一些列放到一個表，然後把主碼和另外的列放到另一個表中。
如果一個表中某些列常用，而另外一些列不常用，則可以採用垂直分割，另外垂直分割可以使得數據行變小，一個數據頁就能存放更多的數據，在查詢時就會減少I/O 次數。其缺點是需要管理冗餘列，查詢所有數據需要join操作。

❺ 資料庫中某列的加和

不要想得太復雜了。
你手動賦值一次，就計算列5一次。
再次賦吵大值時，蘆臘根據時間（或者主鍵id什麼的）找到上一次列5結果加上此次賦值陪碰滑就是新的列5結果。

❻ 資料庫中drop和delete的區別

1. truncate和 delete只刪除數據不刪除表的結構(定義)
drop語句將刪除表的結構被依賴的約束(constrain),觸發器(trigger),索引(index); 依賴於該表的
存儲過程/函數將保留,但是變為invalid狀態.
2.delete語句是dml,這個操作會放到rollback segement中,事務提交之後才生效;如果有相應的trigger,
執行的時候將被觸發.
truncate,drop是ddl, 操作立即生效,原數據不放到rollback segment中,不能回滾. 操作不觸發
trigger.
3.delete語句不影響表所佔用的extent, 高水線(high watermark)保持原位置不動
顯然drop語句將表所佔用的空間全部釋放
truncate 語句預設情況下見空間釋放到 minextents個 extent,除非使用reuse storage; truncate
會將高水線復位(回到最開始).
4.速度,一般來說: drop> truncate > delete
5.安全性:小心使用drop 和truncate,尤其沒有備份的時候.否則哭都來不及.
使用上,想刪除部分數據行用delete,注意帶上where子句. 回滾段要足夠大.
想刪除表,當然用drop
想保留表而將所有數據刪除. 如果和事務無關,用truncate即可. 如果和事務有關,或者想觸發trigger,還
是用delete.

如果是整理表內部的碎片,可以用truncate跟上reuse stroage,再重新導入/插入數據/

總結：
DROP用於刪除表,資料庫等.
TRUNCATE和DELETE都是刪除表數據.
但是TRUNCATE相當於初始化,比如如果有自增長ID,用TRUNCATE刪除後,自增長Id會從1開始,（truncat會釋放表所佔的空間）
而delete則不會.

❼ 資料庫中char和varchar的區別

資料庫中char和varchar的區別為：長度不同、效率不同、存儲不同。

一、長度不同

1、char類型：char類型的長度是固定的。

2、varchar類型：varchar類型的長度是可變的。

二、效率不同

1、char類型：char類型每次修改的數據長度相同，效率更高。

2、varchar類型：varchar類型每次修改的數據長度不同，效率更低。

三、存儲不同

1、char類型：char類型存儲的時候是初始預計字元串再加上一個記錄字元串長度的位元組，佔用空間較大。

2、varchar類型：varchar類型存儲的時候是實際字元串再加上一個記錄字元串長度的位元組，佔用空間較小。

❽ 資料庫中Schema和Database有什麼區別

我實驗測試兩個完全不一樣。create database是創建一個資料庫，而create schema是創建一個架構。首先你瞎州要明白資料庫和架構的區別，還要明白登錄名和用磨判蔽戶名的區別。我們正常登陸名是sa,但是映射的用戶名是dbo,所有你打開資料庫看錶，前面都是dbo.XXX.你先用sa登陸，然後會看見安全性，安全性下面有個登錄名，打開就會看見sa這個登錄名，雙擊之後會看見一個用戶映射，點開之後有三項，資料庫，用戶名，默認架構，比如系統master資料庫用戶名就是dbo,默認架構dbo.到這里還是你肯定還是不明白。下面做個實驗，1.先創建一個用戶名se,在沖困安全性下面右擊登陸名就可以創建，驗證選擇sql身份驗證，輸入密碼即可。2.右擊資料庫然後創建一個資料庫test。3.打開資料庫test,也會看見一個安全性，安全性下面有用戶，點開你就會看見dbo,很多人問create schema authorization +用戶名，這個用戶名到底是什麼，系統默認就是dbo.所以create schema authorization dbo這條指令是不會報錯的。3.我們在test下面創建一個新用戶admin,右擊安全性下面用戶名就可以創建，用戶寫admin,登錄名選擇我們剛才的se,架構選擇默認的dbo.到此你就應該明白登錄名和用戶名的區別。登錄名可以設置查看資料庫許可權，而用戶名是資料庫下面可以設置查看架構的許可權。比如我們創建資料庫test1，test2,test3.然後我們創建登錄名se,se我可以給他查看test1資料庫許可權，但是不給他test2的許可權，這樣登陸se就只有查看test1許可權。

❾ 資料庫中主鍵和索引的區別

表中的 每一行都應該具有可以唯一標識自己的一列 (或一組列)。而這個承擔標識作用的列稱為 主鍵 。

主鍵的兩個作用：

(1) 惟一地標識一行 

(2) 作為一個可以被外鍵野簡脊有效引用的對象。 

1. 主鍵一定是唯一性索引，唯一性索引並不一定就是主鍵。

2. 一個表中可以有多個唯一性索引，但只能有一個主鍵。

3.主鍵列不咐凳允許空值，頌滲而唯一性索引列允許空值（不過最好都不要有null）。

4. 索引可以提高查詢的速度。