簡體 English 中英

糟糕的數據庫設計 - 我的桌子太大了嗎？

[英]Bad Database Design - Is my table too large?

原文 2008-10-07 16:45:41 5 14 database/ database-design/ performance/ size

我有一個設計糟糕的數據庫。 其中一個最重要的表有11,000多個條目。 我們想擴展我們的系統，我想知道這個表是否增長到它的大小的5倍，這會是一個問題嗎？ 它的大小為15360 kB ......如果重要的話。

我正在使用phpMyAdmin，服務器是一個Fedora Linux盒子（沒什么特別的），負載很輕。 它存儲了我們系統使用的所有內容。

14 個解決方案

什么DBMS？ 什么服務器？ 什么負載？ 什么應用？

此外：11.000記錄什么都沒有，真的。 甚至在MS Access中。 :-)

編輯：所以我假設你使用一個相當新的MySQL與MyISAM表。 從理論上講，您可以繼續將表格填入數百萬條記錄中。 根據您使用它們的方式（很多連接/不連接，很多查詢/更新/刪除/不），您不需要做任何特殊的事情。 在桌子上放一個適當的索引，你應該沒事。

我知道您擔心在“設計不佳的數據庫”中將記錄數增加到55.000左右會影響性能。

如果您的系統按預期工作，我認為除非您有一些輕微的性能問題，否則您應該可以使用50.000記錄。

正如大多數人所提到的，50k記錄與數據庫表大小相關的數量非常少，即使沒有規范化的數據庫，也不會出現性能問題。

如果您計划擴展系統的功能，那么也許現在也是查看數據庫設計的好時機，否則保持原樣應該是合理安全的。

我認為你沒有提供足夠的信息給某人給出答案。 為什么設計不合理？ 它沒有正常化嗎？ 你沒有任何索引嗎？ 這是什么數據庫？ 它運行的操作系統是什么？ 現在查詢相關表中的記錄需要多長時間？

11k條目並不多。 50K也不大。

將索引放在表格上（針對您將在其上運行的查詢進行了優化）將允許比您想象的更大的數量的良好性能。

如果設計足夠差，你可能會考慮重新設計的成本。

“設計不佳的數據庫”是什么意思？

如果它的設計很糟糕，重新設計它，將信息拖出當前表格，然后填充新表格。

如果你擔心性能，11000個條目並不大。 按db標准，15兆字節的數據庫非常小。

表的大小不是很重要。 密鑰，索引和關系的設計與設計質量的關系遠遠大於其中包含的數據的大小。 這顯然有一些警告; 但是在處理性能或設計問題時，優化表的大小是我做的最后一件事。

您可能想要更多地解釋為什么您認為這是一個設計不佳的數據庫，以及您可以（輕松）做些什么來糾正問題。 除此之外，您還應詳細說明DBMS的類型以及用途（Web應用程序，自定義應用程序，報告等）。

15MB沒什么。 11k行也是如此。 我有2 GB以上的數據庫，有些表包含超過100萬行，我認為它介於中小尺寸之間。

你真的沒有提供任何證據支持你聲稱這是一個設計糟糕的數據庫。 是什么讓它設計不佳？ 該表有876列嗎？ 列是Col1，Col2，Col3 ......？ 它是否使用float和datetime作為復合主鍵？ 它很難正常化？ 我們唯一知道的是它的記錄數。

在數據庫方面，11K記錄通常沒什么。

除了一個表中的記錄數之外，還有什么能讓您認為數據庫的設計很差？

您需要提供有關表結構的更多信息。

一般來說，表中的15,000行會被認為很小，實際上很小，以至於某些設計人員甚至可能不會為索引編制索引。

如果您要擴展系統，現在是時候重新設計了。 當你擁有11,000條記錄而不是1000萬條記錄時，重新設計的痛苦要小得多。 但是，你所說的沒有告訴我你需要重新設計。 有連接沒有任何固有的錯誤（事實上，一個設計良好的數據庫應該有它們）。 發布關於結構的一些細節，我們可以幫助您決定是否需要重新設計。

可能的問題是您和您的同事根本沒有數據庫訪問經驗，也不知道如何有效和輕松地查詢它們。 或者問題可能是設計不好，沒有結構細節，很難說。

糟糕的基礎將是你最昂貴的錯誤。 如果表格很重要，那么您需要決定修復它的重要性。 表中的行數僅影響從中提取內容的速度。 但是，如果你的數據庫設計開始不好，那么你的雙手將會被困在某些地方。