A. 資料庫課程設計《某學校題庫管理系統》
兄弟，你設計好了嗎？現在我也需要啊。。。。
B. 怎麼做校園BBS論壇
想做個我自己大學的校園論壇，想把論壇直接架設到自己學校的網站上」
這個容易，只要你能做的了主，詳細步驟給你說下吧！
1、不需要購買域名，用你們學校原先的域名重新解析個域名比如原域名www.zhhsw.net ，na 那麼你解析個域名為bbs.zhhsw.net即可。
2、在原先的空間上新建一個文件夾，取名bbs，並且把新解析的域名綁定到這個文件夾，前提是你的空間必需支持一個子目錄。
3、下載程序安裝到你新建的子目錄內，一般用discuz！程序，免費的。（如果你做不來，我可以免費幫你下，其實很簡單）
4、你學校的官方網導航欄上加個bbs連接即可！
就這樣就可以了，還不要花錢，如果你的空間不支持子目錄，那麼你最多開個子目錄，30元就夠了，其它還有資料庫是否支持php的，如果支持更好，不支持再開，幾十元錢的！
C. sql資料庫課程設計
網路即時通信系統是為用戶開發研製的，用戶是系統的最終使用者和評價者，所以在網路通信系統的開發設計的過程中，我們樹立了從用戶的尋求出發，面向用戶，一切為了用戶的觀念，在分析與設計系統的前期，為了保證系統的功能的完善多次尋求周圍同學和老師的意見，了解他們的要求，依照功能完善，界面美觀，操作簡單的原則進行設計 。
嚴格按階段進行
系統的開發設計是一項較大的工程，所以應該將整個系統的開發設計過程劃分為若干階段，相應的階段又要分為若干個不同的步驟，每個階段和步驟都要有明確的工作任務和目標。這種有序的組織安排，條例清楚、層次分明，便於計劃的制定和控制，並且為後續工作的進行奠定了堅實的基礎，提高了工作效率和質量。
採用系統的觀點處理
在系統分析階段，在對原系統進行全面調查和分析的基礎上，構造系統的最佳邏輯模型，使用戶對將來完整系統的輪廓有個初步的了解和認識，以便及時和用戶進行交流和探討，不斷提高系統的完善性。在此基礎上進行系統的物理實現和設計，切實完成邏輯模型的具體功能。邏輯設計和物理實現二者是相輔相成、密不可分的，這樣使系統的設計更加穩妥合理。
整個系統的設計主要採用快速原形法
快速原形法是信息系統設計的一個重要方法。它是根據用戶提出的需求，由用戶和開發者共同確定系統的基本要求和主要功能，並在一個較短的時間內建立一個實驗性的、簡單的信息系統模型，通過用戶不斷提出的意見和建議，對模型進行不斷的修改和完善，直到用戶比較滿意為止，以便形成一個相對穩定、較為理想的管理信息系統。該方法的主要優點。
1.脈絡清楚，所有問題都圍繞一個模型展開，使彼此之間聯系緊密。
2.有助於發現用戶需求，通過對原形和用戶接觸，能夠啟發開發人員去挖掘問題，從而不斷的修正、完善，最終得到一個理想的系統。
3.系統開發效率高，此方法的開發周期短、使用靈活、容易修改，這對於管理體制不夠穩定的系統更加適合。
4.系統的可擴展性好，由於此方法是在原型應用中不斷發展完善和修改的，所以有較強的擴展性。
在進行代碼設計時，遵循了以下原則。
唯一性：在本系統中，每一個代碼都和系統中的每一個對象唯一確定。
標准性：主要體現在對程序文件名命名和對數據文件命名的標准化上，遵循簡單扼要，方便適用的原則。一目瞭然，無重復現象。為了系統維護人員便於進行系統維護，使用了統一的標准。
合理性：系統中代碼設計與編碼對象的分類相適應，以使代碼對編碼對象的分類據有標志作用。
簡單性：在設計過程中採用Code-Behind代碼分離，使資料庫操作代碼和前端調用代碼分離，頁面修改容易。
適應性：在代碼設計過程中，代碼反映了編碼對象的特點，便於識別和記憶，使系統維護人員容易了解和掌握，便於進行維護工作。
系統總體功能結構
網路通信系統包含以下主要功能。
用戶注冊；用戶登錄；
查找好友；查看好友資料；
添加好友；
刪除好友；
發送消息；
發送文件.
資料庫表主要用來存放用戶的注冊信息和用戶的好友資料，可利用兩張資料庫表來 存放用戶信息和用戶好友的資料。包括用戶的號碼，昵稱，密碼，在線與否，ip地址，資料，頭像號，性別，E-mail和籍貫等信息。其中，用戶昵稱和密碼是必需的欄位；在線與否是由系統自動設置的；其餘的信息是可選的欄位。
課題整體以JAVA為平台，採用Eclipse開發工具，並使用SQL Server 2000管理資料庫數據開發而成的基於Socket的集中式網路通信系統，系統採用客戶機/伺服器（C/S）的模式設計，是一個三層C/S結構，資料庫伺服器、應用程序伺服器端 、應用程序客戶端。系統採用C/S結構，可以將任務合理分配到客戶機端和伺服器端 ，從而降低了系統的通信開銷。
客戶層。
客戶層是應用程序的用戶介面部分，它擔負著用戶與應用間的對話功能，用於檢查用戶的輸入數據，顯示應用的輸出數據，為了直觀的進行操作，客戶層需要使用圖形用戶介面，若聊天用戶變更，系統只需改寫顯示控制和數據檢查程序即可，而不會影響其他兩層。
服務層。（功能層）
服務層相當於應用的本體，它是將具體的業務處理邏輯編入程序中。在應用設計中，必須避免在表示層和功能層之間進行多次的數據交換，這就需要盡可能進行一次性的業務處理達到優化整體設計的目的。
數據層
數據層是DBMS，本系統使用了Microsoft 公司的SQL Ssever2000資料庫伺服器來管理數據。SQL Ssever2000能迅速的執行大量數據的更新和檢索，因此，從功能層傳送到數
據層的要求一般都使用SQL語言。
這是我畢業論文一部分 做的是聊天系統 給你參考 無所謂給不給分~! 也不可能全給你 帶代碼有20兆
D. asp.net校園論壇，怎樣建立資料庫
一般就是文本、數字和布爾，
論壇一般ubb在線編輯器，
簡單點的圖片一般上傳傳到伺服器，資料庫儲存路徑，
超鏈接圖片路徑都是文本，
數據系統難的是構架，一開始做就上論壇，
上來就玩地獄模式是不是有點快。
E. 求推薦論壇或者網站可以找到計算機的課程設計或者畢業設計啊
我推薦你一些新穎的課題吧
基於JSP的萬科新聞發布系統-java新聞發布系統javaweb新聞發布mysql數據源
基於SpringBoot+Redis的在線考試系統-java在線考試系統mysql數據源javaweb在線考試系統-javaEE在線考試系統
基於JSP的教學在線留言答疑係統-java教學在線留言答疑係統mysql數據源
基於SSM的教務管理系統(選課課程評分)-java教務管理系統mysql數據源
基於SSM+bootstrap的校園訂餐系統-java校園訂餐系統mysql數據源
基於JSP的高校快餐店訂餐系統-java快餐店訂餐系統mysql數據源
基於SSM+Bootstrap的汽車銷售管理系統-java汽車銷售管理系統maven分布式mysql數據源
基於SSM+Redis的停車場管理系統-java停車場管理系統mysql數據源
基於SSM+bootstrap的停車場收費管理系統-java停車場收費管理系統mysql數據源
基於Mybatis的教學管理系統作業提交批改管理系統-java教學管理系統作業提交批改管理系統
基於SSM的醫院住院管理系統-java醫院住院管理系統mysql數據源
基於SSM的醫院葯品管理系統(葯品采購處方開具櫃台倉庫多角色)-java醫院葯品管理系統mysql數據源
基於JSP的在線預約掛號系統-java在線預約掛號系統mysql數據源
基於SSM的實驗室管理系統-java實驗室管理系統mysql數據源
基於SSM的社區矯正工作信息管理平台-java社區矯正工作信息管理平台mysql數據源基於redis的分布式session實現『
基於SSH的校園食堂點餐系統-java校園食堂點餐訂餐系統mysql資料庫
基於Spring+SpringMvc+Hibernate的家政服務網-java家政服務網
基於SSM的家政服務管理系統-java家政服務管理系統家政平台mysql數據源
這些都很不錯 還有很多我沒發的課題，你自已找找 你應該明白 一貼就知道
F. 論壇的資料庫怎麼設計
常用的論壇設計方法，總結如下：
一 分割思想：
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 定期對表進行轉儲
G. 資料庫系統課程設計 BBS論壇系統
到網上down個好了 一大堆
H. 資料庫課程設計，校園一卡通設計
校園一卡通顧名思義，使用一張卡完成校園所有電子業務的應用。當前學校電子業務應用主要分為兩類：消費和身份識別。
1、消費：包括餐廳吃飯消費、澡堂洗浴消費、超市消費、醫務室、體育場館收費等。
2、身份識別類：新生注冊（數字迎新）、圖書借閱、寢室和教學樓的門禁和考勤識別等。
而使用的校園卡多為mifare卡，根據卡中存放信息分為ic卡和id卡：
1、IC卡是集成電路卡，通過卡里的集成電路存儲信息，此類卡存放的有各種人員信息和賬戶信息，與應用終端（消費機、考勤機）交互後需要上傳到資料庫人員信息表中，使得資料庫與卡片同步，與資料庫交互不夠及時，批量上傳數據。
2、ID卡是身份識別卡，卡中只存放一條帳號信息，每次與應用終端交互都需要與資料庫交互，此類卡的應用終端必須實時聯網，寫校園一卡通設計的話推薦此種卡片。資料庫建一組相互關聯的表，使得能存放完整的人員信息，人員信息主要欄位自少包括：姓名、學號、班級信息、卡號、賬戶金額（消費金額）、消費各種狀態信息（）、許可權類別（考勤的許可權、食堂消費許可權、洗浴消費許可權、門禁刷卡許可權）等，消費記錄表包括交易流水、交易時間、交易地點、交易金額等。
卡與消費終端交互流程：
1、鑒權：根據應用終端的類別，交互資料庫取出該賬戶許可權類別，判斷是否有資格。
2、如鑒權通過，上傳消費終端上輸入的消費金額，平台根據上傳金額與資料庫提取出來的賬戶余額對比，判斷金額是否合理。
3、平台自動操作資料庫更改消費後的賬戶余額及相關信息。
註：一卡通的充值流程同消費流程，純手工敲的，歡迎採納，一卡通業務方面問題可以[email protected]。