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

次の場合の基本的なスキーマ設計を思い付かなければならないトレーニング演習として、単純なデータベース設計タスクを実行しています。 製品の親子階層があります（例：原材料>作業中>最終製品）。 注文は各レベルで行われます。 注文数は、次の6か月間、毎週のバケットで確認できます。 製品レベルごとに需要予測を行うことができます。 次の6か月以内の任意の週の需要予測を今日行うことができます。 需要予測は、次の6か月間の毎週のバケットに対して行われます。 需要予測は通常、階層の上位レベル（原材料または仕掛品レベル）で行われます。下位レベル（最終製品）に分解する必要があります。 需要予測を上位レベルから下位レベルに分解する方法は2つあります。 ユーザーは最終製品の割合分布を指定します。たとえば、作業中の予測は1000だとします。ユーザーは、バケット10の最終製品1に40％、最終製品2に60％が欲しいと言っています。次に、今から10週目（日曜日から土曜日）の予測値最終製品1の場合は400、最終製品2の場合は600になります。 ユーザーは、バケット5の最終製品に対する注文に従って分解するだけで、バケット5の最終製品1と2の注文はそれぞれ200と800であり、EP1の予測値は（（200/1000）* 100）％になります。 EP2の場合、「（作業中）」の予測の（（800/1000）* 100）％になります。 予測は次の6か月間、毎週バケットで表示可能であり、理想的な形式は次のとおりです。 product name | bucket number | week start date | week end date | forecast value | created_on PRODUCT_HIERARCHYテーブルは次のようになります。 id | name | parent_id __________________________________________ 1 | raw material | (null) 2 | work in …

9 oracle  database-design  schema  oracle-11g 

15の試験マークを保存する必要がある学生追跡プログラムを開発しています。 マークを文字列として保存し、算術演算の実行などの目的で、必要に応じて分割できます。しかし、私はできるだけ多くのパフォーマンスが必要です。 どちらが良いですか？単一の文字列フィールド、または15の個々のintフィールド？

9 database-design  query-performance  datatypes 

の表Producersとの表がありProducts、どちらも次の形式です。 Id -int、主キー Name -nvarchar プロデューサーは複数の製品を運ぶことができるため、次のようなテーブルを作成しましたProducerDetails。 ProducerId -int、外部キー Producers.Id ProductId -int、外部キー Products.Id それから自分に問いかけ始めたので、専門家に聞いてみようと思いました。テーブルに追加のId（int、主キー）列がある方がデータベース設計が優れてProducerDetailsいるでしょうか？それとも不要ですか？ SQL-Server 2008 R2を使用しています。 編集 -これらのテーブル間の関係は多対多だと思います。申し訳ありませんが、明確にしていません。生産者は複数のタイプの製品を運ぶことができ、同じ製品が複数の異なる生産者によって生産される可能性があります。 この質問が非常に単純である場合はお詫び申し上げます。参照整合性/データベース設計は私の強みではありません（私はそれを改善しようとしていますが）。

9 sql-server  database-design  referential-integrity 

これは、フィードバックが必要な質問の詳細です。複数の支払いゲートウェイを処理するデータベースを設計しています。支払いゲートウェイは、ほとんどの場合、支払いを行う前に注文詳細のテーブル（これはすべてのPGに共通）と、支払いを行った後の応答を保存するためのトランザクション詳細のテーブルを必要とします。 ここで、複数の支払いゲートウェイを処理するために、単一のトランザクションテーブルを保持し、すべての支払いゲートウェイから利用可能なすべてのフィールドと、その行のPGを示すフィールドを詰め込むことができます。 それとも、私のような接頭辞でPGごとに別のトランザクションテーブルを作成することができpaypal_たりbank_、それぞれがそれらのそれぞれが必要なフィールドを持つ、など。 どちらがより最適な方法であるかはわかりません。また、将来遭遇する可能性のある同様のシナリオについても学習する必要があります。

9 database-design 

日付と時刻を別々の列に保持するというソフトウェアベンダーの決定を理解しようとしています。たとえば、行が作成または更新されたとき。時間と日付はどちらもDateTime列です。SQL Server 2005を使用しています。 データベースにはERPシステムのデータが保持されており、最大のテーブルには約300万行が含まれていると思います。ほとんどのテーブルは、おおよそ100 000〜1 000 000行です。 私は個人的にはデフォルトで、単一のタイムスタンプに対して単一のDateTimeを選択します。これにより、時間差の計算が容易になり、日付と時刻の部分をタイムスタンプから簡単に抽出できます。また、使用するスペースも少なくなります。 日付と時刻を分離することは悪い習慣なのでしょうか、それともこのデザインに理解できない非常に素晴らしいものがあるのでしょうか？

9 sql-server-2005  database-design 

私はウェブサイトの基本的なセキュリティシステムに最適な方法を見つけようとしています。ユーザーとグループが必要なことはわかっています。 私が持っていると思いました： user_table user_id user_name ... group_type group_id group_name parent_id ... group_table id user_id group_id 1つ目はユーザー、2つ目はグループ、3つ目は2つを接続する中間テーブルです。1人のユーザーに多数のグループがあります。 この音は大丈夫ですか？

9 database-design 

SQL Server 2008を使用して新しいリソースセットのスキーマを定義しています...この場合、各レコード（行など）はXMLフラグメントを格納する必要があります。時々; 頻繁ではありませんが; 要素と属性の値を見つけるには、XMLをクエリする必要があります。自分の考案に任せれば、xmlデータ型を使用する傾向がありますが、これは問題があると考えられています。それが私の質問につながります。 このシナリオを前提として、XML列にxmlを格納するか、varchar（MAX）列にXMLを格納するかを決定する際に考慮すべき要素は何ですか。 それが役立つ場合...ここにいくつかの追加の詳細があります： これらのフラグメントのスキーマ（XSDなど）の使用に関して決定は行われていません フラグメントのサイズは、小さいものから非常に大きいものまでさまざまです。 すべてのXMLは整形式です 1日の間に、最大3か月間必要なオンラインクエリサポートで最大10,000個のフラグメントが収集されます XMLに対するクエリは1日を通して発生しますが、このタイプの同時クエリがほとんどないため、軽いままです。

9 sql-server-2008  database-design  schema  datatypes  xml 

閉まっている。この質問はトピックから外れています。現在、回答を受け付けていません。 この質問を改善してみませんか？ 質問を更新して、データベース管理者のスタック交換のトピックになるようにします。 5年前休業。 移行のためのデータベース要素のマッピングを含むプロジェクトに取り組んでいますが、これを行うために他の人が使用しているツールを知りたいですか？ Excelは単純なマッピングを文書化する非常に柔軟な方法ですが、誰かが特定の方法論や推奨する他のツールを使用している人がいるかどうか疑問に思っていましたか？

9 database-design  migration  documentation 

最近、データベース分野で行われている研究で世界で最も有名な学校はどれですか。

9 database-design 

何百万もの行を含むテーブルで、列をNOT NULLからNULLに変更する必要があります。私は簡単に試しました alter table Table1 ALTER COLUMN Column1 XML NULL しかし、それは永遠にかかります。だからここに私の質問があります： 変更を適用するのになぜこれほど時間がかかるのですか？ それを行うより良い方法はありますか？

9 sql-server-2008  database-design 

Webプロジェクトに友情関係を格納するテーブルを設計したい 少なくとも次の4つの条件を満たす必要があります。 友達追加リクエストを送信したユーザー（例：A TO Bの場合、この列はAになります） 友達追加リクエストを受け取ったユーザー（例：A TO Bの場合、この列はBになります） 現在のステータスeg（0は拒否を示しますが、1は受け入れ済み、2は未処理を示します 私たちの友人関係は二国間です あなたがこれを経験したことがあれば、どんな提案も歓迎します 私の現在の設計は、（私は今、悪い右を考えて）このようなもので 、これらは列です frienshipId fromUserId toUserId status requestTime

9 database-design 

以前は、クラスター化インデックスを（常に）エンゲージする/回避するかどうかについての議論/ディスカッションは決定的ではありませんでした。 まあ、私はそれらが時々適切な特定の目的とコンテキストで使用されることを理解しました。 SQL Azureデータベースのクラスター化インデックスの要件： 「SQL Azureはクラスター化インデックスのないテーブルをサポートしていません。テーブルにはクラスター化インデックスが必要です。クラスター化制約なしでテーブルを作成する場合、テーブルで挿入操作を許可する前にクラスター化インデックスを作成する必要があります。」 以前の結論、根拠、および説明には適合しません。 例外なくクラスタ化インデックスのユビキタス性を厳密に課すという、これまでの説明から逃した理論的根拠は何ですか？

9 sql-server  database-design  azure-sql-database  index 

私はテーブル持っているcontainersいくつかのテーブルに多対多の関係を持つことができる、のは、それらがあるとしましょうplants、animalsとbacteria。各容器は、任意の数の植物、動物、または細菌を含むことができ、各植物、動物、または細菌は、任意の数の容器に入れることができる。 これまでのところ、これは非常に簡単ですが、私が問題を抱えているのは、各コンテナには同じタイプの要素のみを含める必要があるということです。たとえば、植物と動物の両方を含む混合コンテナは、データベースの制約違反になります。 これの私の元のスキーマは次のとおりでした： containers ---------- id ... ... containers_plants ----------------- container_id plant_id containers_animals ------------------ container_id animal_id containers_bacteria ------------------- container_id bacterium_id しかし、このスキーマでは、コンテナーを均一にする必要があるという制約を実装する方法を思いつきません。 これを参照整合性で実装し、データベースレベルでコンテナが同種であることを保証する方法はありますか？ これにはPostgres 9.6を使用しています。

9 postgresql  database-design  constraint  many-to-many 

複数のカスケードパスについて多くの質問が出されていることがわかります。例えば： /programming/851625/foreign-key-constraint-may-cause-cycles-or-multiple-cascade-paths /programming/6065501/multiple-cascade-delete-path-in-many-many-relationship-ef-4-1 /programming/27613117/introducing-foreign-key-constraint-may-cause-cycles-or-multiple-cascade-paths-s ただし、私が見て理解していることから、関連するマスターレコードの削除の1つの条件だけでなく、多くの子レコードを削除することはまったく問題ありません。 質問では、SQL Serverがこれを防止して安全を確保しようとしていると言われていますが、複数のカスケードパスがある場合に何が問題になるのか、安全にするためにどのような問題が発生しないのかはわかりません。 誰かが私に分かりやすく簡単な言葉で、できれば複数のカスケードパスの場合に問題が発生する可能性のある例を使用して説明できることを願っています。

9 sql-server  database-design  cascade 

（PostgreSql 9.4に裏打ちされた）大規模なSAASアプリケーションの場合、300,000を超えるアカウントがあり（そして成長中）、アカウントごとにスキーマを使用してデータをパーティション分割することと、すべてのデータを1つのスキーマに入れ、外部キーを使用することの長所と短所は何ですか。クエリで分割しますか？ 以前、多くのスキーマを操作するときにpg_dumpが非常に遅くなっていましたが、それが今日のケースかどうかはわかりません。また、データベース構造の変更はすべてのスキーマで行う必要があることも認識しています。そしてプラス面では、スキーマをある物理サーバーから別の物理サーバーに移動するのは簡単です。また、スキーマをバックアップから復元することはもちろんです。データをそのようにパーティション分割することは理にかなっています。 それで、私が見逃している長所と短所は何ですか？

9 postgresql  database-design  schema  multi-tenant