資料庫怎麼設計

⑴ 資料庫怎麼設計呢

create table 角色表( 編號 int primary key identity(1,1) not null, 角色名稱 varcahr(20) not null, 角色狀態 int default(1))create table 用戶表( 編號 int primary key identity(1,1) not null, 用戶名稱 varchar(20) not null, 用戶密碼 varchar(10) not null, 用戶狀態 int default(1))create table 許可權表( 編號 int primary key identity(1,1) not null, 職權名稱 varchar(30) not null, 狀態 int default(1))create table 角色_許可權( 編號 int primary key identity(1,1) not null, 角色編號 int foreign key references 角色表 not null, 許可權編號 int foreign key references 許可權表 not null, 狀態 int default(1)
)create table 角色_用戶( 編號 int primary key identity(1,1) not null, 角色編號 int foreign key references 角色表 not null, 用戶編號 int foreign key references 用戶表 not null, 狀態 int default(1)
)沒在SQL上寫有些錯了的話不好意識的咯，每張表都有狀態，因為在表直接有約束，所以刪除信息的時候很難刪掉，如果要刪掉的話就直接修改狀態，0為有效，1為有效。

⑵ 資料庫伺服器怎麼設計

我理解你問的是硬體，一般思路： 1.選平台：windows，linux還是unix 2.挑主機：哪個廠商，什麼樣的性能要求（TPCC,TPCH），什麼樣的RAS要求，什麼特殊要求如分區、虛擬化等 3.搭架構：這個和你自身的應用以及選的資料庫有關，比如oracle資料庫，是單機單實例還是RAC或者其他方式 4.配存儲：I/.O常常是資料庫的瓶頸，要配合適的存儲才能發揮伺服器性能 當然理論設計還要看實際預算，暫時想到的，供你參考 藍屏

⑶ 網站的資料庫如何設計

什麼是好的資料庫設計？

一些原則可為資料庫設計過程提供指導。第一個原則是，重復信息（也稱為冗餘數據）很糟糕，因為重復信息會浪費空間，並會增加出錯和不一致的可能性。第二個原則是，信息的正確性和完整性非常重要。如果資料庫中包含不正確的信息，任何從資料庫中提取信息的報表也將包含不正確的信息。因此，基於這些報表所做的任何決策都將提供錯誤信息。

所以，良好的資料庫設計應該是這樣的：

• 將信息劃分到基於主題的表中，以減少冗餘數據。

• 向 Access 提供根據需要聯接表中信息時所需的信息。

• 可幫助支持和確保信息的准確性和完整性。

• 可滿足數據處理和報表需求。

設計過程

設計過程包括以下步驟：

• 確定資料庫的用途：這可幫助進行其他步驟的准備工作。

• 查找和組織所需的信息：收集可能希望在資料庫中記錄的各種信息，如產品名稱和訂單號。

• 劃分到表中的信息：將信息項劃分到主要的實體或主題中，如「產品」或「訂單」。每個主題即構成一個表。

• 關閉信息項目導入的列 確定希望在每個表中存儲哪些信息。每個項將成為一個欄位，並作為列顯示在表中。例如，「雇員」表中可能包含「姓氏」和「聘用日期」等欄位。

• 指定為主鍵：選擇每個表的主鍵。主鍵是一個用於唯一標識每個行的列。例如，主鍵可以為「產品 ID」或「訂單 ID」。

• 設置表關系：查看每個表，並確定各個表中的數據如何彼此關聯。根據需要，將欄位添加到表中或創建新表，以便清楚地表達這些關系。

• 優化您的設計：分析設計中是否存在錯誤。創建表並添加幾條示例數據記錄。確定是否可以從表中獲得期望的結果。根據需要對設計進行調整。

• 應用規范化規則：應用數據規范化規則，以確定表的結構是否正確。根據需要對表進行調整。

參考：資料庫設計基礎

⑷ 資料庫如何設計

資料庫設計的基本步驟

按照規范設計的方法，考慮資料庫及其應用系統開發全過程，將資料庫設計分為以下6個階段

1.需求分析

2.概念結構設計

3.邏輯結構設計

4.物理結構設計

5.資料庫實施

6.資料庫的運行和維護

資料庫設計通常分為6個階段1分析用戶的需求，包括數據、功能和性能需求；2概念結構設計：主要採用E-R模型進行設計，包括畫E-R圖；3邏輯結構設計：通過將轉換成表，實現從E-R模型到關系模型的轉換；4：主要是為所設計的資料庫選擇合適的和存取路徑；5資料庫的實施：包括編程、測試和試運行；6資料庫運行與維護：系統的運行與資料庫的日常維護。）,主要討論其中的第3個階段,即邏輯設計。

在資料庫設計過程中，需求分析和概念設計可以獨立於任何資料庫管理系統進行，邏輯設計和物理設計與選用的DAMS密切相關。

1.需求分析階段（常用自頂向下）

進行資料庫設計首先必須准確了解和分析用戶需求（包括數據與處理）。需求分析是整個設計過程的基礎，也是最困難，最耗時的一步。需求分析是否做得充分和准確，決定了在其上構建資料庫大廈的速度與質量。需求分析做的不好，會導致整個資料庫設計返工重做。

需求分析的任務，是通過詳細調查現實世界要處理的對象，充分了解原系統工作概況，明確用戶的各種需求，然後在此基礎上確定新的系統功能，新系統還得充分考慮今後可能的擴充與改變，不僅僅能夠按當前應用需求來設計。

調查的重點是，數據與處理。達到信息要求，處理要求，安全性和完整性要求。

分析方法常用SA(Structured Analysis) 結構化分析方法，SA方法從最上層的系統組織結構入手，採用自頂向下，逐層分解的方式分析系統。

數據流圖表達了數據和處理過程的關系，在SA方法中，處理過程的處理邏輯常常藉助判定表或判定樹來描述。在處理功能逐步分解的同事，系統中的數據也逐級分解，形成若干層次的數據流圖。系統中的數據則藉助數據字典（data dictionary，DD）來描述。數據字典是系統中各類數據描述的集合，數據字典通常包括數據項，數據結構，數據流，數據存儲，和處理過程5個階段。

2.概念結構設計階段（常用自底向上）

概念結構設計是整個資料庫設計的關鍵，它通過對用戶需求進行綜合，歸納與抽象，形成了一個獨立於具體DBMS的概念模型。

設計概念結構通常有四類方法：

• 自頂向下。即首先定義全局概念結構的框架，再逐步細化。

• 自底向上。即首先定義各局部應用的概念結構，然後再將他們集成起來，得到全局概念結構。

• 逐步擴張。首先定義最重要的核心概念結構，然後向外擴張，以滾雪球的方式逐步生成其他的概念結構，直至總體概念結構。

• 混合策略。即自頂向下和自底向上相結合。

3.邏輯結構設計階段（E-R圖）

邏輯結構設計是將概念結構轉換為某個DBMS所支持的數據模型，並將進行優化。

在這階段，E-R圖顯得異常重要。大家要學會各個實體定義的屬性來畫出總體的E-R圖。

各分E-R圖之間的沖突主要有三類：屬性沖突，命名沖突，和結構沖突。

E-R圖向關系模型的轉換，要解決的問題是如何將實體性和實體間的聯系轉換為關系模式，如何確定這些關系模式的屬性和碼。

4.物理設計階段

物理設計是為邏輯數據結構模型選取一個最適合應用環境的物理結構（包括存儲結構和存取方法）。

首先要對運行的事務詳細分析，獲得選擇物理資料庫設計所需要的參數，其次，要充分了解所用的RDBMS的內部特徵，特別是系統提供的存取方法和存儲結構。

常用的存取方法有三類：1.索引方法，目前主要是B+樹索引方法。2.聚簇方法（Clustering）方法。3.是HASH方法。

5.資料庫實施階段

資料庫實施階段，設計人員運營DBMS提供的資料庫語言（如sql）及其宿主語言，根據邏輯設計和物理設計的結果建立資料庫，編制和調試應用程序，組織數據入庫，並進行試運行。

6.資料庫運行和維護階段

資料庫應用系統經過試運行後，即可投入正式運行，在資料庫系統運行過程中必須不斷地對其進行評價，調整，修改。

資料庫設計5步驟
Five Steps to design the Database

1.確定entities及relationships

a)明確宏觀行為。資料庫是用來做什麼的？比如，管理雇員的信息。

b)確定entities。對於一系列的行為，確定所管理信息所涉及到的主題范圍。這將變成table。比如，僱用員工，指定具體部門，確定技能等級。

c)確定relationships。分析行為，確定tables之間有何種關系。比如，部門與雇員之間存在一種關系。給這種關系命名。

d)細化行為。從宏觀行為開始，現在仔細檢查這些行為，看有哪些行為能轉為微觀行為。比如，管理雇員的信息可細化為：

· 增加新員工

· 修改存在員工信息

· 刪除調走的員工

e)確定業務規則。分析業務規則，確定你要採取哪種。比如，可能有這樣一種規則，一個部門有且只能有一個部門領導。這些規則將被設計到資料庫的結構中。

====================================================================
範例：
ACME是一個小公司，在5個地方都設有辦事處。當前，有75名員工。公司准備快速擴大規模，劃分了9個部門，每個部門都有其領導。
為有助於尋求新的員工，人事部門規劃了68種技能，為將來人事管理作好准備。員工被招進時，每一種技能的專業等級都被確定。


定義宏觀行為
一些ACME公司的宏觀行為包括：
● 招聘員工
● 解僱員工
● 管理員工個人信息
● 管理公司所需的技能信息
● 管理哪位員工有哪些技能
● 管理部門信息
● 管理辦事處信息
確定entities及relationships
我們可以確定要存放信息的主題領域(表)及其關系，並創建一個基於宏觀行為及描述的圖表。
我們用方框來代表table，用菱形代表relationship。我們可以確定哪些relationship是一對多，一對一，及多對多。
這是一個E-R草圖，以後會細化。



細化宏觀行為
以下微觀行為基於上面宏觀行為而形成：
● 增加或刪除一個員工
● 增加或刪除一個辦事處
● 列出一個部門中的所有員工
● 增加一項技能
● 增加一個員工的一項技能
● 確定一個員工的技能
● 確定一個員工每項技能的等級
● 確定所有擁有相同等級的某項技能的員工
● 修改員工的技能等級

這些微觀行為可用來確定需要哪些table或relationship。

確定業務規則
業務規則常用於確定一對多，一對一，及多對多關系。
相關的業務規則可能有：
● 現在有5個辦事處；最多允許擴展到10個。
● 員工可以改變部門或辦事處
● 每個部門有一個部門領導
● 每個辦事處至多有3個電話號碼
● 每個電話號碼有一個或多個擴展
● 員工被招進時，每一種技能的專業等級都被確定。
● 每位員工擁有3到20個技能
● 某位員工可能被安排在一個辦事處，也可能不安排辦事處。

2.確定所需數據

要確定所需數據：

a)確定支持數據

b)列出所要跟蹤的所有數據。描述table(主題)的數據回答這些問題：誰，什麼，哪裡，何時，以及為什麼

c)為每個table建立數據

d)列出每個table目前看起來合適的可用數據

e)為每個relationship設置數據

f)如果有，為每個relationship列出適用的數據

確定支持數據

你所確定的支持數據將會成為table中的欄位名。比如，下列數據將適用於表Employee，表Skill，表Expert In。

Employee

Skill

Expert In

ID

ID

Level

Last Name

Name

Date acquired

First Name

Description

Department

Office

Address


如果將這些數據畫成圖表，就像：



• 需要注意：


• ● 在確定支持數據時，請一定要參考你之前所確定的宏觀行為，以清楚如何利用這些數據。


• ● 比如，如果你知道你需要所有員工的按姓氏排序的列表，確保你將支持數據分解為名字與姓氏，這比簡單地提供一個名字會更好。


• ● 你所選擇的名稱最好保持一致性。這將更易於維護資料庫，也更易於閱讀所輸出的報表。


• ● 比如，如果你在某些地方用了一個縮寫名稱Emp_status，你就不應該在另外一個地方使用全名(Empolyee_ID)。相反，這些名稱應當是Emp_status及Emp_id。


• ● 數據是否與正確的table相對應無關緊要，你可以根據自己的喜好來定。在下節中，你會通過測試對此作出判斷。

3.標准化數據

標准化是你用以消除數據冗餘及確保數據與正確的table或relationship相關聯的一系列測試。共有5個測試。本節中，我們將討論經常使用的3個。
關於標准化測試的更多信息，請參考有關資料庫設計的書籍。

標准化格式
標准化格式是標准化數據的常用測試方式。你的數據通過第一遍測試後，就被認為是達到第一標准化格式；通過第二遍測試，達到第二標准化格式；通過第三遍測試，達到第三標准化格式。

如何標准格式：
1． 列出數據
2． 為每個表確定至少一個鍵。每個表必須有一個主鍵。
3． 確定relationships的鍵。relationships的鍵是連接兩個表的鍵。
4． 檢查支持數據列表中的計算數據。計算數據通常不保存在資料庫中。
5． 將數據放在第一遍的標准化格式中：
6． 從tables及relationships除去重復的數據。
7． 以你所除去數據創建一個或更多的tables及relationships。
8． 將數據放在第二遍的標准化格式中：
9． 用多於一個以上的鍵確定tables及relationships。
10． 除去只依賴於鍵一部分的數據。
11． 以你所除去數據創建一個或更多的tables及relationships。
12． 將數據放在第三遍的標准化格式中：
13． 除去那些依賴於tables或relationships中其他數據，並且不是鍵的數據。
14． 以你所除去數據創建一個或更多的tables及relationships。

數據與鍵
在你開始標准化（測試數據）前，簡單地列出數據，並為每張表確定一個唯一的主鍵。這個鍵可以由一個欄位或幾個欄位（連鎖鍵）組成。

主鍵是一張表中唯一區分各行的一組欄位。Employee表的主鍵是Employee ID欄位。Works In relationship中的主鍵包括Office Code及Employee ID欄位。給資料庫中每一relationship給出一個鍵，從其所連接的每一個table中抽取其鍵產生。

RelationShip

Key

Office

*Office code

Office address

Phone number

Works in

*Office code

*Employee ID

Department

*Department ID

Department name

Heads

*Department ID

*Employee ID

Assoc with

*Department ID

*EmployeeID

Skill

*Skill ID

Skill name

Skill description

Expert In

*Skill ID

*Employee ID

Skill level

Date acquired

Employee

*Employee ID

Last Name

First Name

Social security number

Employee street

Employee city

Employee state

Employee phone

Date of birth


將數據放在第一遍的標准化格式中
● 除去重復的組
● 要測試第一遍標准化格式，除去重復的組，並將它們放進他們各自的一張表中。
● 在下面的例子中，Phone Number可以重復。（一個工作人員可以有多於一個的電話號碼。）將重復的組除去，創建一個名為Telephone的新表。在Telephone與Office創建一個名為Associated With的relationship。

將數據放在第二遍的標准化格式中
● 除去那些不依賴於整個鍵的數據。
● 只看那些有一個以上鍵的tables及relationships。要測試第二遍標准化格式，除去那些不依賴於整個鍵的任何數據（組成鍵的所有欄位）。
● 在此例中，原Employee表有一個由兩個欄位組成的鍵。一些數據不依賴於整個鍵；例如，department name只依賴於其中一個鍵（Department ID）。因此，Department ID，其他Employee數據並不依賴於它，應移至一個名為Department的新表中，並為Employee及Department建立一個名為Assigned To的relationship。


將數據放在第三遍的標准化格式中
● 除去那些不直接依賴於鍵的數據。
● 要測試第三遍標准化格式，除去那些不是直接依賴於鍵，而是依賴於其他數據的數據。
● 在此例中，原Employee表有依賴於其鍵（Employee ID）的數據。然而，office location及office phone依賴於其他欄位，即Office Code。它們不直接依賴於Employee ID鍵。將這組數據，包括Office Code，移至一個名為Office的新表中，並為Employee及Office建立一個名為Works In的relationship。

4.考量關系

當你完成標准化進程後，你的設計已經差不多完成了。你所需要做的，就是考量關系。

考量帶有數據的關系
你的一些relationship可能集含有數據。這經常發生在多對多的關系中。

遇到這種情況，將relationship轉化為一個table。relationship的鍵依舊成為table中的鍵。

考量沒有數據的關系
要實現沒有數據的關系，你需要定義外部鍵。外部鍵是含有另外一個表中主鍵的一個或多個欄位。外部鍵使你能同時連接多表數據。

有一些基本原則能幫助你決定將這些鍵放在哪裡：

一對多在一對多關系中，「一」中的主鍵放在「多」中。此例中，外部鍵放在Employee表中。

一對一在一對一關系中，外部鍵可以放進任一表中。如果必須要放在某一邊，而不能放在另一邊，應該放在必須的一邊。此例中，外部鍵（Head ID）在Department表中，因為這是必需的。

多對多在多對多關系中，用兩個外部鍵來創建一個新表。已存的舊表通過這個新表來發生聯系。

5.檢驗設計

在你完成設計之前，你需要確保它滿足你的需要。檢查你在一開始時所定義的行為，確認你可以獲取行為所需要的所有數據：
● 你能找到一個路徑來等到你所需要的所有信息嗎？
● 設計是否滿足了你的需要？
● 所有需要的數據都可用嗎？
如果你對以上的問題都回答是，你已經差不多完成設計了。

最終設計
最終設計看起來就像這樣：

設計資料庫的表屬性
資料庫設計需要確定有什麼表，每張表有什麼欄位。此節討論如何指定各欄位的屬性。

對於每一欄位，你必須決定欄位名，數據類型及大小，是否允許NULL值，以及你是否希望資料庫限制欄位中所允許的值。

選擇欄位名
欄位名可以是字母、數字或符號的任意組合。然而，如果欄位名包括了字母、數字或下劃線、或並不以字母打頭，或者它是個關鍵字（詳見關鍵字表），那麼當使用欄位名稱時，必須用雙引號括起來。

為欄位選擇數據類型
SQL Anywhere支持的數據類型包括：
整數（int, integer, smallint）
小數（decimal, numeric）
浮點數（float, double）
字元型（char, varchar, long varchar）
二進制數據類型（binary, long binary）
日期/時間類型（date, time, timestamp）
用戶自定義類型

關於數據類型的內容，請參見「SQL Anywhere數據類型」一節。欄位的數據類型影響欄位的最大尺寸。例如，如果你指定SMALLINT，此欄位可以容納32,767的整數。INTEGER可以容納2,147,483,647的整數。對CHAR來講，欄位的最大值必須指定。

長二進制的數據類型可用來在資料庫中保存例如圖像(如點陣圖)或者文字編輯文檔。這些類型的信息通常被稱為二進制大型對象，或者BLOBS。

關於每一數據類型的完整描述，見「SQL Anywhere數據類型」。

⑸ 怎麼去設計一個資料庫

第一：首先分析資料庫應該包含幾個表，每個表裡面有多少項內容，這些需要根據資料庫管理系統功能來說的！
第二：開始建立資料庫表以及裡面的欄位
第三：就是資料庫開發了
第四：功能的完善

建議你先分析一下都需要什麼功能！然後在網路裡面搜索一下！現在有很多現成的資料庫管理系統的，直接下載一個根據你所需要的功能進行修改就可以了！

網上很多，如果自己開發太累，也沒有那些高手開發的功能全的！

⑹ 怎麼設計這個資料庫

問這種問題通常都不容易說清楚，只能勉強做一下。要更清楚得詳談。
對於第2個問題：
分成：
一級類表：一級類id（主鍵），類名稱 .....(描述，備注等欄位)，43條記錄
二級類表：二級類id（主鍵），類名稱 .....(描述，備注等欄位)，855條記錄
屬性表：屬性id（主鍵），屬性名稱 .....(描述，備注等欄位)，6000條記錄左右，這里我假設你的意思不是6000種屬性值呢，而是6000種屬性，不同產品規格型號不同。
下面的產品記錄若理解為產品，而不是同一產品的不同個體都有一條記錄。則
產品類型表：產品類型id（主鍵），產品名稱（同一類型產品名字是一樣的），屬性1 id，屬性1值，屬性2 id，屬性2值，屬性3 id，屬性3值 .....(描述，備注等非關鍵欄位)，220萬條記錄左右。其中屬性id都是外鍵，和屬性表關聯。這不太符合實際：因為有220萬種產品，似乎規模太大了。可能空間很浪費，因為如果某產品有最多100個屬性，則其它產品記錄中會有大量空屬性，如果使用關系和XML混合資料庫，可避免該問題，可是在檢索中效率如何等方面需要仔細考慮。另外可能還需要考慮諸如生產廠家、銷售者等問題，所以問題的規模不見得僅僅是這一點。
若是產品個體的記錄，則：
產品類型表還是要的。然後
產品表：產品id（主鍵），其餘諸如出廠日期，描述，備注等非關鍵欄位。
對於第1個問題：
則是資料庫優化問題，要根據資料庫訪問特點，包括提高硬體性能（更好的機器、伺服器群集）、加適當索引、採用適當的並發機制等方式來解決問題。而且最好有一個具體需求，然後盡快測試系統原型是否滿足要求，不滿足就設法改進直到滿足要求為止。

⑺ 論壇的資料庫怎麼設計

常用的論壇設計方法，總結如下：
一 分割思想：
1 資料庫切分：用戶庫、主題庫、回復庫
2 數據表水平切分：用戶庫1-n、主題庫1-n、回復庫1-n （比如按時間分）
3 分布式資料庫：每台計算機中都有DBMS的一份完整拷貝副本，並具有自己局部的資料庫，位於不同地點的許多計算機通過網路互相連接，共同組成一個完整的、全局的大型資料庫。
4 論壇功能可以進行分隔，不同的伺服器負責不同的功能
5 用主從資料庫，master是寫， slave是讀
6 把內容與其它信息分開，好處就是可以讓每個表的文件最小化,對資料庫操作壓力會減小，這樣保證每張表數據量很小，操作速度會快，也可以在這里使用緩存
二 索引：
針對是否建立索引有著一定的分歧：
我覺得建立索引還是很有必要的。理由如下：
1）建立索引可以加快檢索速度，對於論壇讀和寫的比例相差很大，用戶體驗當然是讀多寫少，所以綜合考慮還是要用索引，而且是加在常用的讀關鍵字上。
2）索引之所以會降低更新的速度，是因為更新還包括對索引的更新，從更新帖子10萬左右，這句話是說，我們可能對發帖標題，發帖內容，回復標題，回復內容這4個欄位做更新。需要注意的是，這四個欄位並不是用來建立表連接的欄位，為了優化查詢速度我們不會在這四個欄位上建立索引，所以從這道題目出發，我們建立的索引不會影響更新帖子的性能。只要被索引的列（例如回復表的標題ID）不被頻繁更新,即使索引所在地行的其它列被頻繁update,索引也不會被更新從而產生性能消耗,一張表一天30萬次的索引更新,因它引起的性能消耗小到即使資料庫安裝在奔騰3單核CPU下都能輕松承擔下來。
3）對於更新的速度慢的問題，我們有解決的方法，你提交更新了後，前台可以讓程序返回一個正確結果，後台開個線程非同步慢慢跟新資料庫就是了，反正更新成功的前提就是假設資料庫連接永遠正確並處於可靠狀態。在資料庫和用戶之間建立一個緩沖區。(如，將更新的數據放到內存中，達到一定數量的時候再統一更新資料庫。假如以100條為例，一旦內存中達到100條數據量將這100條數據統一入庫。減少insert操作)

三 緩沖：
讀的時候的緩沖：緩存路由表
主題緩存表（這個取每個區的前面100條記錄），一般來說負載最大的就是主題的第一頁，所以緩存表是個小表。

另外使用hibernate，在資料庫上面加了一層緩存。
生成靜態頁，緩存最熱，最新的帖子。
對於經常更新的數據都設計成單獨表 ，這樣可以最大程度的利用hibernate緩存
緩存常用的數據和表，利用緩存來將經常被訪問的帖子留在內存中，為每條緩存的記錄添加一個訪問時間，如果長時間沒被訪問就從緩存中刪除掉，
避免內存過大，每次用戶看帖的時候，首先檢索緩存中時候有需要的帖子，沒有的話再訪問資料庫，然後將資料庫返回的帖子信息存儲到緩存中。

寫的時候的緩沖：資料庫和用戶之間建立緩存，將更新的數據放在內存中，非同步操作的。所有的寫貼操作 放到一個隊列然後批量執行插入資料庫操作。

預估計的緩沖：假如用戶第一次打開某標題，那將此標題的相關的前100條數據緩存到客戶斷。這樣避開對資料庫的直接查詢，減少資料庫壓力。
四 代碼優化
1盡量避免表的連接約束通過代碼來實現約束 例如用戶id的驗證在用戶登錄時驗證這樣就可以把帖子表的用戶id外鍵去掉這樣就成了單表操作、查詢 而連接可以通過觸發來實現這樣最多是查詢了3個表而不是連接中的笛卡爾笛卡爾積 回復表的查詢限定每次查詢的記錄數例如限定10條其它的通過點擊觸發來操作"注代碼優化容易出現bug 原因有些開發工具本身有優化"
五 資料庫性能調優
盡量用硬體來代替軟體優化 原則就是能用硬體的盡量用硬體 比如磁碟陣列 RAID0 有條件用RAID10 加大內存 .避免小表上建索引 對論壇來說數據帖子和回復不是很重要 可以定期刪除一些垃圾帖子 樓主說的幾百萬條記錄的論壇對現在的資料庫管理系統和計算機來說永不著刻意的優化,定期維護打包備份資料庫就可以了
提高速度的關鍵:
1.建立合理的索引並在查詢時充分利用;
2.避免使用關聯,這樣避免整表掃描;使用關聯不如多次使用主鍵查詢來的快;
3.一些處理的功能盡可能放到內存中來做,比如組織主題和回復;
4.海量緩存（使用靜態頁面也是個不錯的做法）
5 定期對表進行轉儲