タグ付けされた質問 「database-design」

読み取りが多いことがわかっているシステムを設計しています（1分あたり数万回の読み取り）。 names一種の中央レジストリとして機能するテーブルがあります。各行には、textフィールドrepresentationとkeyそのMD5ハッシュである一意のフィールドがありますrepresentation。1現在、このテーブルには数千万のレコードがあり、アプリケーションの存続期間中に数十億に達すると予想されています。 テーブルを参照する他の（スキーマとレコード数が非常に異なる）テーブルは多数ありnamesます。これらのテーブルのいずれかのレコードにname_keyは、機能的にはnamesテーブルへの外部キーであるが含まれることが保証されています。 1：ちなみに、ご想像のとおり、このテーブルのレコードは一度書き込まれると不変です。 テーブル以外の特定のnamesテーブルでは、最も一般的なクエリは次のパターンに従います。 SELECT list, of, fields FROM table WHERE name_key IN (md5a, md5b, md5c...); 読み取りパフォーマンスを最適化したいと思います。私が最初にやるべきことは、インデックスのサイズを最小化することだと思います（ただし、間違っていると証明されてもかまいません）。 質問： /に最適なデータ型は何ですかれるkeyとname_key、列？以上 を使用する理由はありますか？または？hex(32)bit(128)BTREEGIN

35 postgresql  database-design  index  datatypes  uniqueidentifier 

テーブルを定義するとき、論理グループ内の列とグループ自体を目的別に並べると便利です。テーブル内の列の論理的な順序は、開発者に意味を伝え、良いスタイルの要素です。 それは明らかです。 ただし、テーブル内の列の論理的な順序がストレージレイヤーでの物理的な順序に影響を与えるかどうか、または気になるその他の影響があるかどうかは明らかではありません。 スタイルへの影響とは別に、列の順序は重要ですか？ これについてStack Overflowに質問がありますが、信頼できる答えがありません。

35 sql-server  sql-server-2008  database-design  database-internals 

代理キー/人工キーの一般的な利点の1つを理解しています。変更されないため、非常に便利です。これは、「人工」である限り、単一フィールドでも複数フィールドでも同じです。 ただし、各テーブルの主キーとして自動インクリメント整数フィールドを持つことはポリシーの問題のように思われる場合があります。これは常にそのような単一フィールドのキーを持っているのが最良のアイデアですか？なぜですか？ 明確にするために、この質問は人工対自然に関するものではなく、すべての人工キーを単一フィールドにする必要があるかどうかに関するものです

33 database-design  primary-key  surrogate-key 

テーブルにどのインデックスを作成するのかを知る最良の方法を見つけ出す方法はありますか？

33 postgresql  database-design  index-tuning 

GoogleやYahooが非常に大量のデータに対してキーワードを検索する方法を知っている人はいますか？このためにどのような種類のデータベースまたはテクノロジーを採用していますか？ 数ミリ秒かかりますが、10億ページ以上のインデックスが作成されています。

32 database-design  full-text-search 

私たちは、基本的にカードとその残高、支払いなどに関するデータを保持するプリペイドカードのプラットフォームを開発しています。 これまでは、アカウントエンティティのコレクションを持つカードエンティティがあり、各アカウントには、すべての預金/引き出しで更新される金額があります。 現在、チーム内で議論が行われています。誰かがこれがCoddの12の規則を破り、支払いごとに値を更新するのは面倒だと言っています。 これは本当に問題ですか？ もしそうなら、どうすれば修正できますか？

31 database-design  rdbms 

2つのテーブルがあります：DealとDealCategories。1つの取引に多くの取引カテゴリを含めることができます。 したがって、適切な方法はDealCategories、次の構造で呼び出されるテーブルを作成することです。 DealCategoryId (PK) DealId (FK) DealCategoryId (FK) ただし、アウトソースチームはDeal次の方法でテーブルに複数のカテゴリを保存しました。 DealId (PK) DealCategory -- In here they store multiple deal ids separated by commas like this: 18,25,32. 彼らがしたことは間違っているように感じますが、なぜこれが正しくないのかを明確に説明する方法がわかりません。 これが間違っていることをどのように説明すればよいですか？それとも私が間違っているのかもしれませんが、これは受け入れられますか？

31 database-design  foreign-key 

私たちは、それぞれが基礎となるデータを持つ複数のサービスを組み込んだWebプラットフォームを構築しています。これらのサービスは、Service-Oriented Architectureの原則に従って独立して構築されていますが、潜在的に関連するデータに対して処理します。これらのサービスが1つの大きなデータベースを共有するか、それぞれが独自のデータベースを持つかを検討しています。（Windows 2008クラスターでSQL Server 2008 Enterpriseを使用する予定です。） すでに検討した各アプローチの利点には次のものがあります。 単一のデータベース 異なるサービスからのデータを関連付けることは、外部キーの制約によって結び付けることができます 分析抽出は、作成が簡単で実行が高速です 災害が発生した場合、プラットフォームを一貫した状態に復元する方が簡単です 複数のサービスによって参照されるデータの場合、あるサービスによってキャッシュされたデータは、すぐに別のサービスによって使用される可能性が高い 管理と監視は前もって簡単で安価です 複数のデータベース メンテナンス作業、ハードウェアの問題、セキュリティ侵害などは、必ずしもプラットフォーム全体に影響を与えるとは限りません 各データベースが個別のハードウェア上にあると仮定すると、複数のマシンをスケールアップすると、1つの大きなマシンをスケールアップするよりもパフォーマンス上のメリットが大きくなります 運用の観点から、このプラットフォームの各サービスが独自のデータベースを取得すること、またはそれらがすべて同じデータベースに配置されることは、より有利ですか？この質問の答えを伝える重要な要因は何ですか？

31 database-design  deployment 

私たちのシステムの1つでは、クライアントの機密データがあり、各クライアントのデータを個別のデータベースに保存します。そのシステムには約10〜15のクライアントがあります。 ただし、50〜100のクライアント、またはそれ以上のクライアントを持つ新しいシステムを開発しています。この例では、クライアントごとに1つのデータベースを持つことは（機密レコードと監査履歴を格納するために）実行不可能だと考えています。ただし、これが完全に正常かどうか、またはセキュリティを維持する別の方法があるかどうかはわかりません。 これについて何か考えはありますか？

31 database-design  sql-server-2012 

SQL（コンピューティング/データベース）について： テーブルに2つ以上のフィールドがあり、それらが一緒になってレコードを一意に識別する場合、それらを呼び出す適切な方法は何ですか？複合キーまたは複合キー？ 私は両方の使用をウェブで見たので、私は本当に確信がありません。

31 database-design  terminology 

私はインデックス、プライマリキー、外部キーに苦労しています...そしてそれらすべてを持つ必要があります。 2つのテーブルがある場合、両方ともプライマリキーとして整数を持ちます。 最初のテーブルは、FKを介して2番目のテーブルの主キーを参照します。 両方のテーブルで、ID列に主キーインデックスがあります table1.ref_field2番目のテーブルのPKを参照するFK制約を作成しました（table2.id） にインデックスを追加しました table1.ref_field これは、これらのインデックス、プライマリキー、外部キーを整理する最良の方法ですか？

30 postgresql  database-design  index  foreign-key  primary-key 

タイトルはあまり意味がありませんが、この問題に対してより良いタイトルを考えることはできませんでした。 私は次の表を持っています プロジェクト id 名 お客さま id id_project 名 お支払い id id_customer 日付 和 ユーザーがシステムに入ると、特定のプロジェクトにアクセスできます。今、私はそのプロジェクトのすべての支払いをリストしたいと思います、そしてそれはかなり簡単なはずです： SELECT FROM payments where id_customer in (SELECT id from customers where id_project = 5) 私の質問は次のとおりです。この方法でid_project列を支払いテーブルに追加する方が良くない場合、クエリは簡単で高速になります。

30 database-design  normalization 

データベースの列に次のようにラベルを付けていました。 user_id user_name user_password_hash 2つのテーブルを結合する際の競合を避けるために、テーブルをエイリアスする方法についてさらに学んだので、これをやめました。 データベースの列にラベルを付ける効果的な方法は何ですか？どうして？

30 database-design  erd 

R-tree / spatialインデックスに適しているので、特にPostgresに対してこの質問をすること。 次の表に、単語とその頻度のツリー構造（ネストされたセットモデル）を示します。 lexikon ------- _id integer PRIMARY KEY word text frequency integer lset integer UNIQUE KEY rset integer UNIQUE KEY そしてクエリ： SELECT word FROM lexikon WHERE lset BETWEEN @Low AND @High ORDER BY frequency DESC LIMIT @N カバリングインデックス(lset, frequency, word)が有効であると思いlsetますが、(@High, @Low)範囲内の値が多すぎるとうまく機能しない可能性があります。 (frequency DESC)そのインデックスを使用した検索@Nが範囲条件に一致する行を早期に生成する場合、単純なインデックスで十分な場合もあります。 しかし、パフォーマンスはパラメーター値に大きく依存するようです。 範囲(@Low, @High)が広いか狭いかに関係なく、また、頻度の高い単語が幸運にも選択された範囲内にあるかどうかにかかわらず、高速に実行する方法はありますか？ Rツリー/空間インデックスは役立ちますか？ インデックスの追加、クエリの書き換え、テーブルの再設計、制限はありません。

29 postgresql  database-design  index  query-performance 

外部キーフィールドの2つのテーブル間で循環参照を使用することはできますか？ そうでない場合、これらの状況をどのように回避できますか？ もしそうなら、どのようにデータを挿入できますか？ 以下は、（私の意見では）循環参照が受け入れられる場所の例です。 CREATE TABLE Account ( ID INT PRIMARY KEY IDENTITY, Name VARCHAR(50) ) CREATE TABLE Contact ( ID INT PRIMARY KEY IDENTITY, Name VARCHAR(50), AccountID INT FOREIGN KEY REFERENCES Account(ID) ) ALTER TABLE Account ADD PrimaryContactID INT FOREIGN KEY REFERENCES Contact(ID)

29 database-design  foreign-key  rdbms