タグ付けされた質問 「normalization」

私のデータベースでは、id特定の行を一意に検索できるように、作成するすべてのテーブルの名前に整数の主キーを自動的にインクリメントするという習慣になりがちです。 これは悪い考えと考えられますか？この方法で行うことには欠点がありますか？場合によっては、一意の識別子id, profile_id, subscriptionsがどこにあるか、テーブルの外部へのリンクなどの複数のインデックスがあります。idprofile_ididProfile または、そのようなフィールドを追加したくないシナリオはありますか？

191 design  database  sql  normalization 

私が提供する4種類のサービスがあると仮定します（それらは頻繁に変わることはほとんどありません）： テスト中 設計 プログラミング その他 上記のカテゴリのいずれかに該当する実際のサービスが60〜80個あるとします。たとえば、「サービス」は「テクニックAを使用したプログラムのテスト」で、タイプは「テスト」です。 それらをデータベースにエンコードしたいです。私はいくつかのオプションを思いつきました： オプション0： VARCHAR直接使用して、サービスタイプを文字列として直接エンコードします オプション1： データベースを使用しますenum。しかし、enumは悪です オプション2： 2つのテーブルを使用します。 service_line_item (id, service_type_id INT, description VARCHAR); service_type (id, service_type VARCHAR); 参照整合性も楽しむことができます： ALTER service_line_item ADD FOREIGN KEY (service_type_id) REFERENCES service_type (id); いいですね。 しかし、私はまだ物事をエンコードし、整数を処理する必要があります。つまり、テーブルにデータを入力するときです。または、テーブルにデータを入力または処理するときに、手の込んだプログラミングまたはDB構造を作成する必要があります。つまり、データベースを直接扱うとき、またはプログラミング側で新しいオブジェクト指向エンティティを作成するときにJOINし、それらを正しく操作することを確認します。 オプション3： 使用しないでくださいenum。2つのテーブルを使用せず、整数列を使用してください。 service_line_item ( id, service_type INT, -- use 0, 1, 2, 3 (for service …

38 database-design  efficiency  enum  normalization 

適切な正規化を行った後でも、テーブルのインデックスを作成する必要がありますか？これはパフォーマンスにどのように影響しますか？適切に正規化した後、何らかの形でパフォーマンスに影響を与えますか？ 主キーと外部キーが既にある場合、通常どの列にインデックスが付けられますか？ データベースを正規化することはすでに効果的であるようです。しかし、索引付けがデータベースに与える影響をスキップしたかもしれません。これは、クエリを使用する場合にのみ有効ですか？これはどのように機能/実行し、データベースを改善しますか？

14 database  sql  indexing  normalization 

テーブルBと1対1の関係を持つテーブルAがある場合、それらを離しておくことは意味がありますか？または、それらを単一のテーブルに結合しても害はありませんか？これらのシナリオ（2つのテーブルと1つの結合されたテーブル）のいずれかが、通常の形式（1NF、2NF、3NFなど）に関して何か影響を与えますか？

12 database  relational-database  normalization 

3〜4つの相互依存プログラムを開発しています。それらをfoo bar bazとauthと呼びます。お互いに独立してほしいです。各プログラムを他社にライセンス供与する場合を想像してみてください。fooとbarが必要な企業もあれば、bazだけが必要な企業もあります。authを独立しておくことも良い方法のようです。 コンテキスト：authはすべてのシステムの認証を処理します。authのメインのusersテーブルには、user_id、email、password、first、lastがあります fooには、アプリケーションの特定のフィールド（user_id、role_idなど）を持つusersテーブルもあります。 各システムには独自のデータベースがあります。過去に、各アプリケーションから認証データベースへの外部キーを作成しました。他のデータベースから更新権限を削除しましたが、特定の関連フィールドへの選択アクセスを許可しました。これは緊密な依存関係を作成するため、悪い解決策のように見えますが、ユーザー名と電子メールをfoo、bar、またはbazデータベースに格納する必要がないように、dbを正規化することができました。 すべてのデータベースに情報を保存する方が良いでしょうか？または、認証IDをfoo barとbazに保存し、apiを使用してauthIdを使用してユーザー情報を取得する方が良いでしょうか？ 同様に、3つのシステムすべてに顧客がいる可能性があります。確かに、auth dbに依存関係を作成するのは悪いようですが、3つすべての顧客のdbについてはどうですか？ または、1つの中央データベースを作成するのに最適なソリューションです。1つのユーザーテーブル。 他の提案？

8 architecture  web-development  dependencies  normalization