2010-04-08 51 views
12

我忙於使用MySql數據庫開發2個基於Web的系統,並且表/視圖/存儲例程的數量變得非常多,處理複雜性的難度也越來越大。如何使用大型數據庫的命名約定?

現在,在編程語言中,我們有命名空間, Java軟件包,用於劃分軟件的C++命名空間,將它們分組在一起,使事情變得更容易理解。另一方面,數據庫具有更多的扁平結構(至少MySql),例如表和存儲過程處於同一級別。所以人們必須更具創造性,創建命名約定,可能使用多個數據庫或使用工具來可視化事物。

你用什麼方法來緩解疼痛?在開發數據庫時要有效嗎?不要迷失在海洋中的桌子和田地裏,存儲過程?

隨意提及您使用的工具,但嘗試將其限制爲開放源代碼,最好是Linux解決方案,如果確實如此。

b.t.w數據庫在設計方面需要考慮多少個表?

+1

它並沒有直接的幫助,但你可能想看看數據庫重構(http://databaserefactoring.com/index.html) – 2010-04-08 20:25:23

+0

啊,在我的心願單上。感謝:-) – 2010-04-08 20:28:24

回答

3

我發現的唯一通用的解決方案是開發一系列前綴並將它們應用於表格(例如,主要與人力資源有關的表格都將啓動hr_)。我通常將前綴傳遞給應用程序中的其他「對象」(表單,報告,視圖,存儲過程)。

這個解決方案遠非完美,而且有點破綻,但它確實給系統帶來了一點點的順序。

1

當然,絕對使用命名約定。 MySQL數據庫設計是我使用匈牙利符號的最後一個地方之一,但我用「tbl」開始我所有的表格,所有我的意見與「v」等。

此外,我在MySQL Workbench中構建多個數據庫圖,通常每個域集合至少有一個圖,這有助於我可視化架構中的「模塊」。

這是一個像Sql Server這樣的產品具有很大優勢的領域,因爲數據庫對象可以屬於數據庫內的多個模式,非常類似於編程中的命名空間。

1

那麼......在MySQL中沒有真正的解決方案。對於某些數據庫(例如PostgreSQL),您確實有名稱空間,您可以執行此操作。

你可以通過使用多個數據庫來模擬命名空間,但這可能會帶來很多問題。

就我個人而言,我只是簡單地用管理工具來區分它(就像phpMyAdmin自動使用下劃線來分組數據庫一樣)。

+0

phpMyAdmin,承認下劃線是不錯的。我猜如果一個人的命名約定是正確的,那麼應該能夠生成代碼,例如將數據庫結構映射到名稱空間,類和方法的數據訪問對象。關鍵是一致性。 – 2010-04-08 20:40:46

+0

我會投票反對創建多個數據庫只是爲了「組織」你的表。我認爲這會產生比它值得的更多的問題。比如,你的數據庫管理系統會讓你加入數據庫嗎?我不認爲大多數人會這麼做,所以就在那裏引入了一個巨大的問題。 – Jay 2010-04-08 21:57:46

+0

@Jay:就MySQL而言,您可以跨數據庫加入,這是我作爲選項給出的唯一原因。但是我同意你的看法,這遠沒有推薦,我真的不知道查詢規劃人員如何處理這個問題。 – Wolph 2010-04-08 22:48:25

1

在一些數據庫中,您可以使用模式,但我認爲不在mySQL中。命名約定將相關表保存在一起是最好的選擇。我特別試圖做的一件事是在命名不同表中的字段時完全一致。如果我的用戶表調用user_id,那麼我不希望在不同的相關表中將其視爲person_id,userid,User等。同樣,當從表到表使用相同類型的字段時,使用相同的數據類型(如果是字符串數據,則使用大小)。那麼你將不會不斷地將數據轉換成連接。

至於需要成爲一個大型數據庫的表有多少個,這更多的是表中有多少記錄而不是多少個表的函數。許多小型數據庫都有數百個表。我幾乎從來不擔心表的數量,除非我看到有人在創建表像Financials2009,Financials2010等

+0

你可以在MySQL中從dbname.tablename中選擇*。 – 2010-04-08 21:47:02

+2

同上使用一致的字段名稱。這些日子裏我正在研究一個數據庫,不僅有很多未規範化的冗餘數據,而且當他們複製這些字段時,他們給了他們不同的名字!所以在一張表中我們有「基本成本」,而在另一張表中我們有「成本」,而在另一張表中我們有「金額」。另一個字段在此處爲「送達日期」,在那裏爲「日期送達」,在另一個表中爲「送達日期」。而那些你至少可以猜到。誰知道「prodid」和「style」是一回事?等Argggh! – Jay 2010-04-08 21:47:20

2

Oracle電子商務套件有超過25,000表和周圍33000意見。我會說這是一個很大的模式。

1

一個項目對我來說效果很好的解決方案是我們將數據庫分成了幾塊,然後我們畫了一個大的ERD(實際上我們使用Corel,雖然有許多更好的工具可用),但是我們用顏色標記了每張桌子上都顯示了每個組塊的大小,然後我們將它打印在大幅面打印機上,這樣它就像5英尺高,10英尺寬,我們把它掛在我助理辦公室的牆上。不是高科技的解決方案,但它非常實用。

我們對一致的命名也非常謹慎,以迴應HLGEM的回答。

現在回想起來,這將有前綴的每個表名以「塊名」的命名慣例可能會是一個不錯的主意,但我們考得不錯,沒有它。

至於有多大?我不知道,這是一個非常主觀的問題。我一般認爲,當我無法在頭腦中描繪整個事物時,數據庫很大。實際上,我想當你通過幾十個表。記錄數量幾乎無關緊要:具有兩個表格的數據庫每個都有十億條記錄,這些數據很容易理解;具有1000個表格的數據庫每個都有10個記錄,這很難理解。在另一方面

0

數據庫具有更平坦結構(MySQL的至少)

的...但你可以對同一MySQL實例,例如運行多個數據庫(注意儘量避免使用mysql'USE dbname')。在查詢中標準化別名是個好主意。

數據庫在設計方面需要考慮多少個表?

我不認爲有一個標準的度量。我可能會開始感到困惑圍繞50.在Oracle DB的我看有後1567(是的,這是標準化(排序))