データベースの設計が不十分です。最も重要なテーブルの 1 つには、11,000 以上のエントリがあります。システムを拡張したいのですが、このテーブルのサイズが 5 倍になったら問題になるのでしょうか? サイズは 15360 kB です...それが重要な場合。
私は phpMyAdmin を使用しています。サーバーは Fedora Linux ボックスです (派手なものは何もありません)。負荷は軽いです。システムが使用するほぼすべてのものを保存します。
4911 次
14 に答える
12
何のDBMS？何のサーバー？何の負荷？どんなアプリケーション？
その上: 11.000 レコードは本当に何でもありません。MSアクセスでも。:-)
編集:だから、MyISAM テーブルでかなり最近の MySQL を使用していると思います。理論的には、何百万ものレコードをテーブルに入力することができます。それらをどのように操作するか (多数の結合/または多数のクエリ/更新/削除/または非) に応じて、特別なことを行う必要はありません。テーブルに適切なインデックスを配置すれば、問題ありません。
于 2008-10-07T16:47:48.870 に答える
8
「設計が不十分なデータベース」でレコード数を 55,000 程度に増やすとパフォーマンスに影響するのではないかと心配されていることは承知しています。
システムが期待どおりに動作する場合は、わずかなパフォーマンスの問題がすでに発生していない限り、50.000 レコードでも問題ないと思います。
ほとんどの人が言及しているように、50k レコードはデータベース テーブルのサイズに比べて非常に小さい数字であり、正規化されていないデータベースでもパフォーマンスの問題は発生しないはずです。
システムの機能を拡張することを計画している場合は、データベースの設計も検討するのがよいでしょう。それ以外の場合は、そのままにしておくのが合理的に安全です。
于 2008-10-07T17:17:01.400 に答える
5
誰かが答えるのに十分な情報を提供しているとは思いません。なぜデザインが悪いのか？正規化されていませんか？インデックスはありませんか？何のDBですか？どのOSで実行されていますか？問題のテーブルからレコードをクエリするのにどれくらいの時間がかかりますか?
于 2008-10-07T16:49:07.663 に答える
4
11k エントリはそれほど多くありません。50Kも大きくありません。
(実行するクエリ用に最適化された) テーブルにインデックスを配置すると、想定しているよりもはるかに大きな量で優れたパフォーマンスが得られます。
ただし、設計が不十分な場合は、再設計のコストを検討することができます。
于 2008-10-07T16:50:22.967 に答える
1
テーブル構造についてもっと多くの情報を提供する必要があります。
一般に、テーブル内の15,000行は小さいと見なされ、実際には非常に小さいため、一部の設計者はインデックス作成に煩わされることさえありません。
于 2008-10-07T17:12:07.930 に答える
1
「不十分に設計されたデータベース」とはどういう意味ですか?
設計が不適切な場合は、再設計し、現在のテーブルから情報をドラッグして、新しいテーブルに入力します。
パフォーマンスを気にするなら、11000 エントリは大きくありません。15 メガバイトのデータベースは、db の標準では非常に小さいです。
于 2008-10-07T16:48:55.013 に答える
1
11K レコードは通常、データベース用語では何もありません。
1 つのテーブル内のレコード数以外に、データベースの設計が不十分だと思われる理由は何ですか?
于 2008-10-07T16:57:51.220 に答える
1
テーブルのサイズはそれほど重要ではありません。キー、インデックス、および関係の設計は、そこに含まれるデータのサイズよりも、設計の品質に大きく関係しています。これには明らかに注意点があります。しかし、パフォーマンスやデザインの問題に取り組んでいるとき、テーブルのサイズを最適化することは、私が最後に行うことのほとんどです。
このデータベースの設計が不十分であると考える理由と、問題を修正するために (簡単に) できることについて、さらに説明することをお勧めします。それに加えて、DBMS の種類と使用方法 (Web アプリ、カスタム アプリ、レポート作成など) を詳しく説明する必要があります。
于 2008-10-07T16:53:02.947 に答える
1
15MBは何もありません。同様に11k行。2 GB 以上のデータを持つデータベースがあり、一部のテーブルには 100 万行を超える行が含まれており、それは小規模と中規模の間のどこかにあると考えています。
于 2008-10-07T16:53:18.093 に答える
1
これが不十分に設計されたデータベースであるというあなたの主張を裏付ける証拠を本当に提供しませんでした. 設計が不十分な理由は何ですか？テーブルには 876 列ありますか? 列の名前は Col1、Col2、Col3... ですか? float と datetime を複合主キーとして使用していますか? それは正規化が不十分ですか？私たちが知っている唯一のことは、そのレコード数です。
于 2008-10-07T16:53:58.637 に答える
0
システムを拡張する場合は、必要に応じて今が再設計の時期です。11,000 件のレコードがある場合は、1,000 万件のレコードがある場合よりも、再設計の手間がはるかに少なくなります。しかし、あなたが言ったことは、あなたが再設計する必要があることを私に示していません。結合を行うことに本質的に問題はありません (実際、適切に設計されたデータベースには結合が必要です)。構造に関する詳細を投稿してください。再設計が必要かどうかを判断するのに役立ちます。
問題は、あなたや同僚がデータベース アクセスの経験がなく、効果的かつ簡単にクエリを実行する方法を知らないことにある可能性があります。あるいは、構造の詳細がわからないと、設計が悪いことが問題なのかもしれません。
于 2009-08-05T13:38:16.650 に答える
0
レコードが何から構成されているかは、テーブル内のレコード数よりも重要です。
私が働いている場所には、数万または数十万のレコード数を持つ多数のテーブルを持つデータベースがあります。ほとんどの場合、私たちのデータベースは小さいと考えられています。
于 2008-10-07T16:56:57.243 に答える
0
基礎が悪いと、最もコストのかかるミスになります。テーブルが重要な場合は、それを修正することがどれほど重要かを判断する必要があります。テーブル内の行の量は、テーブルからデータを引き出す速度にのみ影響します。しかし、最初からデータベースの設計に問題があった場合は、後々、特定の場所で手を縛られることになります。
于 2008-10-07T16:49:48.460 に答える
0
SQL Server 2005 について話している場合は、SQL Server プロファイラーを調べて、インデックス チューニング ウィザードを使用してください。
追加のパフォーマンスが必要な場合は、一部のデータベースでメモリへのテーブル固定もサポートされています。
于 2008-10-07T16:54:53.580 に答える