問題タブ [database-design]

すべてのプロジェクトの開始時に、Dia を開いてデータベース ダイアグラムを作成するのにうんざりしています。特定のテーブルを選択し、MySQL データベースに基づいてデータベース ダイアグラムを作成できるツールはありますか? 外部キーが設定されていないため、後でダイアグラムを編集できるようにすることをお勧めします...

これが私がダイアグラム的に描いているものです（恐ろしいデータ設計を許してください、私はそれを設計していません.この例でそれが表す実際のデータではなく、ダイアグラムの概念に焦点を当てましょう;））：

フルサイズの図を見る

データベースを設計するときはいつでも、データベース内の項目に名前を付ける最良の方法があるかどうかを常に考えています。かなり頻繁に、私は次の質問を自問します。

1. テーブル名は複数形にするべきですか?
2. 列名は単数形にする必要がありますか?
3. テーブルまたは列にプレフィックスを付ける必要がありますか?
4. アイテムの命名には大文字と小文字を使用する必要がありますか?

データベース内の項目に名前を付けるための推奨ガイドラインはありますか?

複数のテーブルで動的検索を実行するためのパターンを探しています。

従来の（そして不十分に設計された）データベーステーブル構造を制御することはできません。

ユーザーが履歴書内のデータのいずれかに対して検索を実行し、検索条件に一致する履歴書のリストを取得したい場合がある履歴書検索に似たシナリオを考えてみます。任意のフィールドをいつでも、1つ以上の他のフィールドと組み合わせて検索できます。

実際のSQLクエリは、検索されるフィールドに応じて動的に作成されます。私が見つけたほとんどの解決策は複雑なifブロックを含みますが、これは今では解決された問題であるに違いないので、もっと洗練された解決策が必要だと思わずにはいられません。

ええ、それで私はコードでSQLを動的に構築する道を歩み始めました。ひどいようです。任意のテーブルの任意のフィールドの任意の組み合わせをクエリする要求された機能を実際にサポートしようとすると、これはifステートメントの1つのMASSIVEセットになります。 震える

COALESCEは、データにNULLが含まれていない場合にのみ機能することを読んだと思います。あれは正しいですか？もしそうなら、私はいたるところにNULL値があるので、行きません。

複数のクライアント用に設計されたデータベース中心のアプリケーションでは、すべてのクライアントに単一のデータベースを使用する方が「良い」と常に思っていました。つまり、レコードを適切なインデックスとキーに関連付けます。Stack Overflowポッドキャストを聞いていると、JoelがFogBugzがクライアントごとに1つのデータベースを使用していると聞いた（したがって、1000のクライアントがある場合は1000のデータベースがある）。このアーキテクチャを使用する利点は何ですか？

一部のプロジェクトでは、クライアントがすべてのデータに直接アクセスする必要があることを理解しています。このようなアプリケーションでは、各クライアントが独自のデータベースを必要とすることは明らかです。ただし、クライアントがデータベースに直接アクセスする必要がないプロジェクトの場合、クライアントごとに1つのデータベースを使用することに利点はありますか？柔軟性の観点から、テーブルの単一のコピーで単一のデータベースを使用する方がはるかに簡単なようです。新しい機能の追加、レポートの作成、および管理が簡単になります。

Joel（経験豊富な開発者）が彼のソフトウェアは別のアプローチを使用していると言うのを聞くまで、私は「すべてのクライアントに1つのデータベース」の方法にかなり自信を持っていました。

多数のレコードがあるとデータベースの速度が低下すると言われていると聞きましたが、特に適切なインデックスとキーが使用されている場合は、メリットのあるリレーショナルデータベースでその問題が発生することはありません。

どんな入力でも大歓迎です！

これまで、私はデータベース テーブルでトリガーを使用するのが好きではありませんでした。私にとって、それらは常に、アプリケーション コードの制御から遠く離れたデータベース側で発生する「魔法」を表していました。また、DB は一般に共有リソースであり、高負荷のシナリオではトリガーが高価になる可能性があると常に想定していたため、DB が実行しなければならない作業量を制限したいと考えていました。

そうは言っても、トリガーを使用するのが理にかなっている例をいくつか見つけました (少なくとも私の意見では、トリガーは理にかなっています)。しかし最近、トリガーを「バイパス」する必要がある場合があることに気付きました。これを行う方法を探さなければならないことに本当に罪悪感を覚えましたが、データベースの設計を改善すれば、このバイパスの必要性が軽減されると今でも思っています。残念ながら、この DB は複数のアプリケーションで使用されており、そのうちのいくつかは、スキーマの変更について大声で叫ぶ非常に非協力的な開発チームによって維持されているため、行き詰まりました。

トリガーに関する一般的な意見は何ですか? 好きですか？嫌いですか？いくつかのシナリオで目的を果たすと思いますか? トリガーをバイパスする必要があるということは、「やり方が間違っている」ことを意味すると思いますか?

Web アプリケーションを作成していて、ユーザーがファイルをアップロードできるサイトの領域がいくつかあります。これに対する私の基本的な作業方法は、実際のファイルをサーバーに保存し、保存されたファイル名を関連するレコードに接続するデータベース テーブルを用意することです。

私の質問は次のとおりです。ファイルの「タイプ」ごとに異なるテーブルが必要ですか? また、ファイルはサーバー上のコンテキストに関連する場所に保存する必要がありますか、それともすべてまとめて保存する必要がありますか?

例: ユーザーのプロフィール写真、求人応募履歴書、CMS ページ上の関連ドキュメントなど。

これが可能かどうか、またはピボット テーブルのカテゴリに該当するかどうかはよくわかりませんが、プロのところに行って確認することにしました。

Card、Property、および CardProperty という 3 つの基本テーブルがあります。カードには同じプロパティがなく、多くの場合、同じプロパティに対して複数の値があるため、カード テーブルに非常に大きな列構造を持たせる代わりに、ユニオン テーブル アプローチを使用してデータを格納することにしました。

プロパティ テーブルは、基本的なキーワード/値型テーブルです。したがって、キーワード ATK とそれに割り当てられた値があります。「Sycnro」や「DARK」など、カードが複数の値を持つことができる SpecialType と呼ばれる別のプロパティがあります。

私がやりたいのは、カード ID、カード名、および指定されたカードの ResultSet 内の列としてカードに割り当てられたすべてのプロパティ キーワードとその値を提供するビューまたはストアド プロシージャを作成することです。したがって、理想的には、次のような結果セットが必要です。

そのようにして結果を集計することができました。

キーワードに基づいてプロパティを単純に連結することで、より洗練されたものになると思います。そのため、次のような ResultSet を生成できます。

..しかし、それが実現可能かどうかはわかりません。

stackoverflow ケノービを助けて! あなたは私の唯一の希望です。

私は、メトリック データを記録するプロジェクトを率いています。データを何年も保持したい。ただし、プライマリ テーブルがデータで肥大化しないようにしたいと考えています。これらのデータは、長期的な傾向には必要ですが、短期的なレポートには必要ありません。

この状況を処理するための最善の戦略は何ですか? 古いデータを別のテーブルにアーカイブするだけですか? それとも、データ自体を統合して「ロールアップ」しますか (そして、別のテーブルに保存しますか)? それともまったく別のものですか？

追加情報: SQL Server 2005 を使用しています。

複数のエンティティのデータを管理する Web サイトを開発しています。エンティティ間でデータは共有されませんが、同じ顧客が所有している可能性があります。顧客は、単一の「ダッシュボード」からすべてのエンティティを管理したい場合があります。では、すべてに対して 1 つのデータベースを使用する必要がありますか?それとも、データを個別のデータベースに分離しておく必要がありますか? ベストプラクティスはありますか? 持っていることのプラス/マイナスは何ですか:

• サイト全体のデータベース (エンティティには「customerID」があり、データには「entityID」があります)
• 顧客ごとのデータベース（データには「entityID」があります）
• 各エンティティのデータベース (データベースと顧客の関係はデータベースの外にあります)

複数のデータベースを使用すると、パフォーマンスが向上する (行と結合が少なくなる) ように見えますが、最終的にはメンテナンスの悪夢になる可能性があります。

タグ付けを実装する方法をいくつか聞いたことがあります。TagID と ItemID の間のマッピング テーブルを使用する (私には理にかなっていますが、スケーリングしますか?)、固定数の可能な TagID 列を ItemID に追加する (悪い考えのように思えます)、コンマで区切られたテキスト列にタグを保持する (サウンドクレイジーですが、うまくいく可能性があります）。誰かがスパース行列を推奨しているとさえ聞いたことがありますが、タグ名はどのように適切に成長するのでしょうか?

タグのベスト プラクティスを見逃していませんか?