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

複数のアプリケーションで作業しているこのデータパターンを定義するのに問題があります。 それはで構成されています： 多くのオブジェクト自体で構成されるオブジェクトタイプ 2番目のオブジェクトタイプ。各インスタンスは最初のオブジェクトの「多く」を持っています また、最初のオブジェクトの各サブオブジェクトは、2番目のオブジェクトタイプへの関連付けごとに変更できます。 簡単な例は次のとおりです。 一連のレッスンで構成されるプログラミングコース レッスンはセットの割り当てで構成されています。 コースを学生に割り当てることができます。 ただし、コースが生徒に割り当てられると、各レッスンや課題は、削除や追加を行って、元のコースが認識できなくなる可能性があるまで、その生徒に合わせてカスタマイズできます。 私の解決策では、これにより次のような結果になります。 コースを生徒に割り当てると、コースはメモリにロードされます。次に、各サブオブジェクトについて、適切なメタデータを使用して生徒/サブオブジェクト関係オブジェクトが生成されます。基本的に、元のオブジェクトをテンプレートとして使用して、必要なカスタマイズ可能なオブジェクトを生成しています。 これにより、サブオブジェクトがより複雑になり、番号が付けられるため、大量のデータが生成されます。このデータパターンを操作するために必要なロジック/複雑さの量を減らすための最適化またはパターンがあるかどうかと思います。

10 design-patterns  object-oriented-design  database-design  data-structures 

私は、stackoverflowに関する開発者のQ＆Aによって発生した最も一般的なデータベース設計の間違いを読んでいました。最初の答えは、排他的な弧についての句がありました： 排他的アークは、テーブルが2つ以上の外部キーで作成され、そのうちの1つだけがnull以外になる可能性がある一般的な間違いです。大ミス。1つには、データの整合性を維持することがはるかに困難になります。結局のところ、参照整合性があっても、これらの外部キーの2つ以上の設定を妨げるものはありません（複雑なチェック制約にもかかわらず）。 なぜ独占アークが邪悪なのかよくわかりません。基本的には理解できなかったのでしょう。独占アークについての良い説明はありますか？

10 database-design 

新しいコード要件が古いコードベースに浮上しました。これにより、以前は直接関連していなかった2つのユーザークラス（完全に異なるスキーマの異なるテーブルに格納されている）間の直接（内部）通信が可能になり、残念ながら、コードはほとんどオブジェクト指向に対応していません。あまり設計されていないため、親クラスはありません）。この機能を考慮しなかったこの古い設定にバッグを掛けるつもりなので、PKの衝突がないという保証はありません。 したがって、解決策は明白なようです。火で殺し、混乱したマッピングテーブル全体を書き換えます。マップを実装するための可能な方法については2つの方向性がありますが、私はDBAではないので、見逃した長所と短所があるかどうかはわかりません。 抽象化を明確にするために、異なるユーザーデータの3つのグループを検討してください：教授、管理、学生（いいえ、これは宿題ではありません。約束！） マッピング1 （professor_id、admin_id、student_idは、それぞれのテーブルへの外部キーです） | mailing_id (KEY) | professor_id | admin_id | student_id | ------------------------------------------------------- | 1001 | NULL | 87 | NULL | | 1002 | 123 | NULL | NULL | | 1003 | NULL | NULL | 123 | このアプローチの+/-は、短所に対してかなり重いようです： 行ごとに2つの「無駄な」フィールド 2NFに違反 異常を挿入/更新する脆弱性（0-1フィールドのみがNULLに設定されている行など） ただし、プロにはメリットがないわけではありません。 マッピングは単一のルックアップで実行できます mailing_idから特定のユーザーの「ソース」データを簡単に特定 …

10 database-design  mysql 

メニュー/レシピ管理という趣味のプロジェクトに取り組んでいます。 これは私の実体とそれらの関係がどのように見えるかです。 AにNutrientはプロパティがCodeあり、Value のIngredientコレクションを持っていますNutrients A RecipeにはコレクションがIngredientsあり、時々他のコレクションを持つことができますrecipes Aは、Mealのコレクションを持っているRecipesし、Ingredients A MenuのコレクションがありますMeals 関係は次のように表すことができます いずれかのページで、選択したメニューについて、その構成要素（食事、レシピ、成分、および対応する栄養素）に基づいて計算された有効栄養素情報を表示する必要があります。 現在、SQL Serverを使用してデータを格納しています。メニューの各食事から始めて栄養素の値を集計して、C＃コードからチェーンを移動しています。 この計算はページがリクエストされ、構成要素が時々変更されるたびに行われるため、これは効率的な方法ではないと思います。 MenuNutrients（{MenuId, NutrientId, Value}）と呼ばれるテーブルを維持し、コンポーネント（食事、レシピ、成分）のいずれかが変更されたときに、このテーブルに有効な栄養素を追加/更新するバックグラウンドサービスがあることを考えていました。 GraphDBはこの要件に適していると思いますが、NoSQLへの私の露出は限られています。 特定のメニューの栄養素を表示するというこの要件に対する代替の解決策/アプローチは何ですか？ シナリオの説明が明確であることを願っています。

10 c#  sql  database-design  nosql  graph-databases 

現在のところ、この質問はQ＆A形式には適していません。回答は事実、参考文献、専門知識によって裏付けられると期待していますが、この質問は、議論、議論、投票、または拡張ディスカッションを求める可能性があります。この質問を改善でき、再開できると思われる場合は、ヘルプセンターにアクセスしてください。 7年前休業。 NoSQLデータベースについてもう少し学びたいので、サッカーの結果を処理するために新しいプロジェクトをゼロから作成することにしました。私の従来のリレーショナルデータベースには、トーナメント、チーム、結果、クラステーブルがあります。すべてが明らかに関連しています。 代わりにNoSQLアプローチを使用して、このようなプロジェクトを設計するための良いアプローチは何でしょうか？

10 database-design  nosql 

私は次のことをするための最良の方法を考えています： データベースに保存されているタスクのリストがあります。タスクには優先度が割り当てられています。タスクの優先度を変更して、実行する順序を並べ替えることができます。 Pivotal Trackerに非常によく似たものを考えています。 次のように想像してください。 1 Task A 2 Task B 3 Task C 4 Task D 5 Task E Eが最も重要なタスクであると判断します 1 Task E 2 Task A 3 Task B 4 Task C 5 Task D 5つのタスクすべてを更新して、新しい優先順位を付ける必要があります。 タスクBがより重要になると、AIは 1 Task E 2 Task B 3 Task A 4 Task C …

10 database-design  data-structures  theory 

現在のところ、この質問はQ＆A形式には適していません。回答は事実、参考文献、専門知識によって裏付けられると期待していますが、この質問は、議論、議論、投票、または拡張ディスカッションを求める可能性があります。この質問を改善でき、再開できると思われる場合は、ヘルプセンターにアクセスしてください。 8年前休業。 銀行の最大規模はOracleを使用すると常に思っていました。ただし、MysqlやPostgreSQLの代わりにOracleを実際に使用している証拠はなく、誰もその秘密を知りません。 彼らが実際に何を使用しているのか？Mysqlを使用して何百万ものトランザクションが発生するATM /銀行システムを構築できますか？PostgreSQLを使用できますか？または、Oracleのみを使用する必要がありますか？

10 database  mysql  oracle  database-design  postgres 

ここに私の質問があります：異なるタイプのNoSQLデータベースの弱点は何ですか？具体的には、キー値ストア、グラフデータストア、ドキュメントストアの弱点は何ですか？ 私は長所を見つけるのは簡単な時間でしたが、弱点に関するドキュメントは不足しているようです。 編集：相互に比較したり、リレーショナルデータベースと比較したりします。

10 database  database-design  nosql 

私のプログラムの一部は、データベース内の多くのテーブルと列からデータをフェッチして処理します。一部の列はである可能性がありますがnull、現在の処理コンテキストではエラーです。 これは「理論的には」発生しないはずなので、発生する場合は、不良データまたはコード内のバグを示しています。エラーの重大度は、フィールドによって異なりnullます。つまり、一部のフィールドでは処理を停止して誰かに通知する必要があり、他のフィールドでは処理を続行して誰かに通知するだけにする必要があります。 まれですが可能なnullエントリを処理するための優れたアーキテクチャまたは設計原則はありますか？ ソリューションはJavaで実装できるはずですが、問題は言語にとらわれないため、タグを使用しませんでした。 私自身が持っていたいくつかの考え： NOT NULLの使用 最も簡単なのは、データベースでNOT NULL制約を使用することです。 しかし、データの元の挿入がこの後の処理ステップよりも重要である場合はどうなりますか？そのため、挿入がnull（バグまたは何らかの正当な理由のために）テーブルに挿入される場合、挿入が失敗しないようにします。プログラムのさらに多くの部分が挿入されたデータに依存しているが、この特定の列には依存していないとしましょう。そのため、挿入ステップではなく、現在の処理ステップでエラーが発生する危険を冒したいのです。それが、NOT NULL制約を使用したくない理由です。 単純にNullPointerExceptionに依存 常にそこにあると期待しているかのようにデータを使用し（実際にそうであるはずです）、結果のNPEを適切なレベルでキャッチします（たとえば、現在のエントリの処理は停止しますが、処理全体は進行しません） ）。これは「フェイルファースト」の原則であり、私はしばしばそれを好みます。少なくともバグの場合、ログに記録されたNPEを取得します。 しかしその後、さまざまな種類の欠落データを区別する能力が失われます。たとえば、一部の欠落しているデータについては除外することができますが、他の場合は処理を停止して管理者に通知する必要があります。 null各アクセスの前に確認し、カスタム例外をスローする カスタム例外を使用すると、例外に基づいて正しいアクションを決定できるため、これは進むべき道のようです。 しかし、どこかで確認するのを忘れた場合はどうなりますか？また、私はコードを、まったくまたはほとんど期待されない（そしてビジネスロジックフローの一部ではない）nullチェックで混乱させます。 この方法を選択した場合、どのパターンがアプローチに最適ですか？ 私のアプローチについての考えやコメントは大歓迎です。また、あらゆる種類の優れたソリューション（パターン、原則、私のコードまたはモデルの優れたアーキテクチャなど）。 編集： 別の制約があります。ORMを使用してDBから永続オブジェクトへのマッピングを行うため、そのレベルでnullチェックを実行しても機能しません（nullが害を及ぼさない部分で同じオブジェクトが使用されるため）。 。これまでに提供された回答の両方がこのオプションについて言及したため、これを追加しました。

9 design-patterns  object-oriented-design  database-design  patterns-and-practices  null 

ユーザーの個人的な病気に関する情報を含むデータベースを設計する必要があります。 DBのテーブルの列を実装するためのアプローチは何ですか？情報を暗号化する、2つの異なるDB内でデータを分離する、1つは機密データ用、もう1つは機密データ用ではない、または両方または別のアプローチですか？

9 security  database-design  mysql 

アプリケーションをゼロから構築する場合、オブジェクト指向（OO）モデルまたはエンティティリレーションシップ（ER）モデルから始める必要がありますか？

9 object-oriented  database-design 

DBaaS（サービスとしてのデータベース）（別名クラウドデータベース）は、ビジネスインテリジェンス（BI）、分析（OLAP）、またはアーカイブには適していないと言う人もいます。 これは本当ですか？より一般的には、DBaaSが最も効果的な技術選択になるのはいつですか？

9 database  database-design  cloud-computing 

さまざまなオープンソースCMSで、2つのリレーショナルテーブルをマッピングするための個別のテーブルがあることに気付きました。カテゴリや製品と同様に、別のproduct_category_mapping表があります。このテーブルには、主キーと、カテゴリおよび製品テーブルの2つの外部キーがあります。 私の質問は、どちらかのテーブルで外部キーを定義することによってテーブルを直接リンクするだけでなく、このデータベース設計の利点は何ですか？それは単に便宜の問題ですか？

9 database-design  database-development 

同じデータベースで同じデータを共有するアプリケーションがいくつかあります。コードの冗長性を最小限に抑えるために、データアクセス層は共有プロジェクトです。これにより、各プロジェクトが独自のデータアクセスを再コーディングする必要がなくなりますが、これも大きな問題になります。1つのチームがデータレイヤーを更新する必要がある場合、他のすべてのチームは変更をプルしてテストし、変更が何も壊れていないことを確認する必要があります。これは遅くて苦痛なプロセスです。 共有データレイヤーを削除し、各チームに独自のデータレイヤーを管理させるというアイデアについて考えましたが、問題は、すべてのチームが同じデータベースにアクセスするため、テーブルの変更がある場合でも、すべてのチームが関連するコードを更新します。 だから私の質問は、多くのプロジェクトが同じデータソースから追​​い出され、データベースまたはアクセスレイヤーへの変更の痛みを最小限に抑えるように、データとアクセスレイヤーをどのように設計できるでしょうか。

8 c#  database-design  application-design 

オーストリアの電子IDカードは、いわゆるセクタ識別子に依存しています。たとえば、病院では、大まかに次のように計算される、その人のセクターIDを取得することで、その人を識別できます。 sha1(personalId + "+" + prefix + sectorId); // prefix is constant and irrelevant それは良い考えですか？どんなに小さくても、衝突の可能性は危険だと思います。 ハッシュテーブルでは、衝突が発生した場合、同等性を確立する別の方法がありますが、主キーでは、同一の2つを使用することはできません。これは複合キーで回避できますが、一意のセクター識別子のポイントが失われます。 それをしても大丈夫ですか、それがいつか壊れることなくそのようにする方法はありますか？

8 design  programming-practices  database-design