0

私は現在、php、javascript、および MySQL を使用して Web アプリケーションを設計しています。データベースには 2 つのオプションを検討しています。

すべてのトーナメントのマスター テーブルがあり、そこに基本情報がトーナメント ID と共に保存されています。次に、ディビジョン、ブラケット、試合などのテーブルを作成し、各テーブル名にトーナメント ID を追加します。次に、そのトーナメントにアクセスするときは、「SELECT * FROM BRACKETS_[ここにトーナメント ID を挿入]」のようにします。

私の他のオプションは、適切な列の外部キーによって、各レコードが適切なトーナメントにリンクされている一般的なブラケット、ディビジョン、試合などのテーブルを持つことです (または、ブラケットからディビジョンへの試合など)。

最初のアプローチに関する私の懸念は、それが私にとっては少しあまりにもオンザフライであり、データベースがすぐに乱雑になる可能性があることです。2 番目のアプローチに関する私の懸念は、パフォーマンスです。このプログラムは、国際的ではないにしても全国的に普及することを願っています.1つのテーブルに非常に多くのレコードがあり、非常に多くの人が同時にヒットする可能性があるため、問題が発生する可能性があります.

データベース管理に関しては、私はまったくの初心者ではありません。ただし、これは私が完全にソロで行った最初のものです。ありがとう！

4

4 に答える 4

3

トーナメントごとにテーブルを作成しないでください。テーブルは、エンティティのインスタンスではなく、エンティティのタイプです。これらの概念を混同すると、保守性とスケーラビリティは恐ろしいものになります。あなたは自分でもそう言います：

このプログラムは、国際的ではないにしても全国的に普及することを願っています。私は、単一のテーブルに非常に多くのレコードがあり、非常に多くの人が同時にヒットする可能性があるため、問題が発生する可能性があることを懸念しています.

レコードごとにテーブル全体を作成する必要がある場合、一体どのようにそのレベルにスケーリングしますか?

2 番目のアプローチのパフォーマンスに関して、なぜ懸念しているのですか? それらの懸念を裏付ける特定の指標はありますか? リレーショナル データベースは、リレーショナル データのクエリに非常に適している傾向があります。したがって、データの関係性を維持してください。創造的になろうとして、使用しているデータベース テクノロジの設計を台無しにしないでください。

いくつかの種類のエンティティに名前を付けました。

  • トーナメント
  • 分割
  • ブラケット
  • マッチ
  • 競合他社選手
  • 等

これらは私にはテーブルのように聞こえます。データのクエリ方法に基づいてインデックスを管理します (つまり、インデックスを過剰に作成しないでください。そうしないと、挿入/更新/削除で料金が発生します)。データを適切に正規化し、監査とレポートがより一般的である場合は非正規化します。パフォーマンスが心配な場合は、データにアクセスする方法のクエリ実行パスに注目してください。少しの調整で大きな違いが生まれます。

時期尚早に最適化しないでください。実際の理由がなくても、複雑さが増します。

于 2012-06-26T06:33:52.080 に答える
2

まず、保存する必要のあるエンティティを見つけます。トーナメント、イベント、チーム、競技者、賞品など。これらの各エンティティはおそらくテーブルになります。

それぞれに主キーを設定するのが標準的な方法です。行を一意に識別する列（または列のグループ）がある場合があるため、それを主キーとして使用できます。ただし、通常はID、数値型などの名前の付いた列を作成するのが最適です。RDBMSがそのような列のインデックスを作成して使用する方が速くて簡単です。

データが属する場所に保存します。イベントの日付と時刻は、eventsテーブルではなくテーブルに表示されると思いprizesます。

もう1つの重要なポイントは、データの原子性を保証するため、第一正規形に準拠することです。これは、後で多くの頭痛の種を減らすので重要です。これを正しく行うことで、正しい数のテーブルも得られます。

最後になりましたが、クエリで最も頻繁に表示される列に関連するインデックスを追加します。これはパフォーマンスに大いに役立ちます。RDBMSは、行数が多すぎるテーブルについて心配する必要はありません。最近では、数億行のテーブルを処理します。これらのテーブルは、それを効率的に実行できるように設計されています。

于 2012-06-26T06:43:54.113 に答える
1

アイテムの新しいインスタンスが表示されるたびに新しいテーブルを作成するという考えは本当に悪いです、申し訳ありません。

これが悪い考えである理由の（確かに不完全な）リスト：

  • 新しいディビジョンなどが作成されるたびに、コードは自動的にテーブルを追加する必要があります。これは間違いなく悪い習慣であり、非常にニッチなケースに限定する必要があります。これは間違いなくそうではありません。
  • 後でテーブル構造を追加または修正することにした場合（たとえば、新しいフィールドを追加する場合）、それを何百ものテーブルに追加する必要があります。これは、面倒で、エラーが発生しやすく、メンテナンスの大きな頭痛の種になります。
  • RDBMSは、テーブルや関連する（インデックス、トリガー、制約）要素ではなく、行の観点からスケーリングするように構築されているため、ツールではなくツールに対して作業を行っています。
  • これは本当のクリンチャーである必要があります-「日曜日に行われたすべての試合をリストする」または「フランクペリーがアクティブだった最新の3つのブラケットを見つける」などのリクエストをどのように処理する予定ですか？

あなたは言う：

データベース管理に関しては、私は完全な初心者ではありません。しかし、これは私が完全にソロでやった最初のものです...

新しいセットが必要になるたびにテーブルが複製された別のプロジェクトを覚えていますか？はいの場合、そのアプローチにいくつかの問題があることに気づきませんでしたか？そうでない場合は、これがDBAが何らかの理由で決して実行しないことであると正確に考えましたか？

于 2012-06-26T08:41:26.213 に答える
1

コードの品質と保守性を損なうことに加えて (他の人が指摘しているように)、実際にパフォーマンスが向上するかどうかも疑問です。

実行すると...

SELECT * FROM BRACKETS_XXX

...DBMS は、名前が「BRACKETS_XXX」に一致するテーブルを見つける必要があり、その検索は、それ自体が一連のテーブルである DBMS のデータ ディクショナリで行われます。つまり、テーブル内の検索をデータ ディクショナリ テーブル内の検索に置き換えています。いずれにせよ、あなたは検索の代償を払います。

(ディクショナリ テーブルは「実際の」テーブルである場合とそうでない場合があり、実際のテーブルと同様のパフォーマンス特性を持っている場合とない場合がありますが、これらのパフォーマンス特性が多数の行の「通常の」テーブルよりも優れている可能性は低いと思います。 、データ ディクショナリのパフォーマンスが文書化される可能性は低いため、文書化されていない機能に頼るべきではありません。)

また、DBMS は突然さらに多くの SQL ステートメントを準備する必要があり (それらは別のテーブルを参照する別のステートメントになっているため)、パフォーマンスにさらなるプレッシャーがかかることになります。

于 2012-06-26T10:30:15.740 に答える