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

データベースに関する一般的な質問があります。通常、データベースとの照合という用語を使用します。文字セットとどう違うのか知りたいです。照合は文字セットのサブセットだと思います。その場合、文字セットの下での多重照合の目的は何ですか。

24 database  mysql  database-design 

多くのアプリケーションには「静的データ」が含まれています。アプリケーションの存続期間中に実際には変化しないデータです。たとえば、近い将来の固定リストになる可能性が高い販売エリアのリストがあるとします。 データベーステーブルでこの静的データを見つけることは珍しくありません（多くの場合、他のテーブルの外部キーで参照したいためです）。単純なサンプルテーブルには、主キーとして使用するIDと説明があります。たとえば、SalesAreaテーブルには（少なくとも）SalesAreaId列とSalesAreaDescription列があります。 現在、コードでは、テーブルの各行を同じように扱いたくない場合があります。たとえば、一部の画面でデフォルトの販売エリアを設定したり、一部のエリアに異なる数値を指定したり、ユーザーが他のエリアでできることを制限したりできます。 この静的データをコードで参照する最良の方法は何ですか？どうして？ コード内の説明をハードコードします。これを使用して、必要なときにデータベースからSalesAreaIdを検索します。 コードにIDをハードコーディングします。これを使用して、必要なときにSalesAreaDescriptionを検索します。 「IsDefaultOnProductLaunchScreen」列などのように、目的ごとにテーブルに列を追加します（これらが多数ある場合があります）。 他の何か。 静的なデータベースデータを扱う際に、他に考慮すべき特別な考慮事項はありますか？たとえば、これらのテーブルに特別な名前を付けますか？

24 database-design 

マルチテナントデータベースです： 顧客/テナントごとに異なる（同一の）データベース/スキーマを持つDBサーバー。または 顧客/テナントが同じテーブル内でレコードを共有するデータベース/スキーマを持つDBサーバー？ たとえば、上記のオプション＃1では、たとえばにMySQLサーバーmydb01.example.comがあり、customer1その中にデータベースがあります。このcustomer1データベースには、たとえば、特定の顧客（顧客＃1）のアプリケーションを駆動する10個のテーブルがあります。またcustomer2、まったく同じ10個のテーブルを持つデータベースがありますが、顧客＃2のデータのみが含まれている場合があります。customer3データベース、データベースなどがある場合がありますcustomer4。 上記のオプション＃2では、たとえば、myapp_db10個のテーブル（上記と同じもの）を持つ単一のデータベース/スキーマのみが存在します。しかし、ここでは、すべての顧客のデータがこれらの10個のテーブル内に存在するため、顧客はテーブルを「共有」します。また、アプリケーション層では、ロジックとセキュリティにより、どの顧客がこれらの10個のテーブルのどのレコードにアクセスできるかを制御し、顧客＃1がアプリにログインして顧客＃3のデータなどを表示しないように細心の注意を払っています。 これらのパラダイムのうち、従来の「マルチテナント」DBを構成するものはどれですか？どちらでもない場合、マルチテナントDBとは何かの例を（上記のシナリオを使用して）提供してくれますか？

24 database-design  multitenancy 

これはしばらくの間私を悩ませてきました。ほとんどの場合、ハッシュテーブル、プログラマ、書籍、記事などの構造にデータを保存する場合、文字列値による構造内の要素のインデックス付けは悪い習慣と見なされます。しかし、これまでのところ、それが悪い習慣であると考えられる理由を説明するための単一のそのような情報源を見つけていません。プログラミング言語に依存していますか？基礎となるフレームワーク上で？実装について 役立つ場合は、2つの簡単な例を挙げます。 行がString主キーによってインデックス付けされるSQLのようなテーブル。 キーが文字列である.NET辞書。

24 programming-practices  data-structures  database-design 

閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 4年前に閉鎖されました。 私は最近ソフトウェア設計のコースを受講しており、サービスのコンポーネントが可能な限り独立したマイクロサービスサブコンポーネントに分離される「マイクロサービス」モデルの使用について、最近の議論/推奨がありました。 言及された部分の1つは、すべてのマイクロサービスが通信する単一のデータベースを持つという非常によく見られるモデルに従うのではなく、マイクロサービスごとに個別のデータベースを実行することでした。 これについてのより適切な言葉で詳細な説明は、http：//martinfowler.com/articles/microservices.htmlの分散型データ管理セクションにあります 。 これを言っている最も顕著な部分： マイクロサービスは、各サービスが独自のデータベース、同じデータベーステクノロジーの異なるインスタンス、または完全に異なるデータベースシステムを管理できるようにすることを好みます-Polyglot Persistenceと呼ばれるアプローチ。モノリスでポリグロット永続化を使用できますが、マイクロサービスではより頻繁に表示されます。 図4 私はこの概念が好きで、他の多くのことの中でも、保守と複数の人が取り組んでいるプロジェクトの強力な改善と考えています。とはいえ、私は決して経験のあるソフトウェアアーキテクトではありません。誰もそれを実装しようとしましたか？どのようなメリットとハードルに遭遇しましたか？

23 design  database-design  microservices 

この投稿を改善したいですか？引用や回答が正しい理由の説明など、この質問に対する詳細な回答を提供します。十分な詳細のない回答は、編集または削除できます。 意思決定段階では、正規化が最初の考慮事項ではないという多くの設計を見ました。 多くの場合、これらの設計には30を超える列が含まれており、主なアプローチは「すべてを同じ場所に置く」ことでした 私が覚えていることによると、正規化は最初の最も重要なことの1つです。 編集： 優秀なアーキテクトや専門家が非正規化されたデザインを選択し、未経験の開発者が反対を選択するというのは本当ですか？正規化を念頭に置いて設計を開始することに対する議論は何ですか？

23 design  sql  database-design  relational-database  rdbms 

いくつかのテーブルに、「second_primary_key」を追加します。これは、uuidまたはランダムな長いキーになります。一部のテーブルでは整数をWebアプリケーションに公開したくないため、必要です。つまり、「/ invoices」ページには、請求書のリストと「/ invoices /：id」へのリンクがあります。ここで、：idは整数です。ユーザーにシステム内の請求書の数を知らせたくないので、「/ invoices / 123」の代わりに「second_primary_key」を使用して、URLが「/ invoices / N_8Zk241vNa」になるようにします。 同じことが、実際のIDを非表示にする他のテーブルにも当てはまります。 これは一般的な慣習ですか？これを実装する最良の方法は何ですか？ 結局のところ、この手法は何と呼ばれていますか？

22 database  database-design 

注文した情報をリレーショナルデータベースに適切に保存する方法を理解しようとしています。 例： 曲で構成されるプレイリストがあるとします。リレーショナルデータベース内には、Playlistsいくつかのメタデータ（名前、作成者など）を含むの。また、私はと呼ばれるテーブルを持っSongs含む、playlist_id曲固有の情報（名前、アーティスト、期間など）だけでなく、。 デフォルトでは、新しい曲がプレイリストに追加されると、最後に追加されます。Song-ID（昇順）で注文する場合、注文は追加の順序になります。しかし、ユーザーがプレイリストの曲を並べ替えることができるとしたらどうでしょうか？ いくつかのアイデアを思いつきました。それぞれに長所と短所があります。 と呼ばれる列orderは、。整数です。曲を移動すると、その変更を反映するために、古い位置と新しい位置の間のすべての曲の順序が変更されます。これの欠点は、曲を移動するたびに多くのクエリを実行する必要があり、移動アルゴリズムが他のオプションほど簡単ではないことです。 orderという10進数の列（NUMERIC）。曲を移動すると、隣接する2つの数字の間に浮動小数点値が割り当てられます。欠点：10進数フィールドはより多くのスペースを必要とし、数回変更するたびに範囲を再分散するように注意しない限り、精度が不足する可能性があります。 別の方法はprevious、next他の曲を参照するフィールドとフィールドを持つことです。（または、現在、プレイリストの最初の曲、最後の曲の場合はNULLです。基本的には、リンクリストを作成します）。欠点：「リストでX番目の曲を見つける」などのクエリは、一定時間ではなく、線形時間になります。 これらの手順のうち、実際に最もよく使用されるのはどれですか？これらの手順のうち、中規模から大規模のデータベースで最も速いのはどれですか？これを実現する他の方法はありますか？ 編集：簡単にするため、この例では、ソングは1つのプレイリストにのみ属します（多対1の関係）。もちろん、ジャンクションテーブルを使用して、song⟷playlistを多対多の関係にすることもできます（そして、そのテーブルに上記の戦略の1つを適用します）。

20 database  database-design  sorting  array  relational-database 

最近（SQLserver内の）テーブル間に制約を作成する理由はありますか？もしそうなら、いつ？私の分野のほとんどのアプリケーションはオブジェクトの原則に基づいて構築されており、テーブルは必要に応じて結合されます。需要は、アプリケーションのニーズに基づいています。単純なルックアップのために束縛されたテーブルをロードすることはありません。順番に（アクションの後）別の単純なルックアップが必要です。 EntityContext、Linq2Data、NHibernateなどのORMツールも、それ自体で制約を処理します。少なくとも、相互に必要なテーブルはわかっています。サーバー内で制約を行うことは、同じ変更を2回行う（強制する）だけのことですか？ これは通常、決定に疑問を投げかけるものではありませんが、このデータベースはまったく異なる設計になっています。設計は通常のように見えますが、ほとんどはアプリケーションで使用されるオブジェクトをミラーリングしています。私を悩ませているのは、SQLserver内で「カスケードなし」に設定されたすべての制約です。つまり、新しいデータベースクエリをコーディングするときは、「検索して検索」する必要があります。場合によっては、1回の削除を行うために最大10レベルの正確な順序が必要です。 これは私を驚かせます、そして、私はそれをどう扱うべきかわかりません。 私の単純な世界では、この設定により、制約のほとんどの目的が失われます。設計に関する知識がなくてもデータベースにホストからアクセスした場合はOKです。 このシナリオでどのように行動しますか？ dbからすべての制約を削除して、アプリケーションレベルで保持しないのはなぜですか。

20 .net  database  database-design 

私たちには多くのクライアントがあり、そのシステムはいくつかの機能を共有していますが、かなりの多様性も持っています。クライアントの数は増え続けています-常に健全なことです！-また、事業間の多様性も増大しています。 現在、単一のASP.Net（Webフォーム）Webサイト（Webプロジェクトとは対照的）があり、各テナントのサブフォルダーとそのテナントの非標準ページがあります。データベースアクセスとビジネスロジックを扱う別のモデルプロジェクトがあります。 （a）クライアントごとに1つのデータベースを持ち、そのクライアントに関連付けられた機能のみを持つ場合、どちらが望ましいか（最も重要なのはなぜか）。または（b）すべてのクライアントが共有する単一のデータベース。1つのクライアントがテーブルのサブセットのみを使用します。 ビジネス内の主な懸念は以上です。 複数の資産のメンテナンス-バックアップ、バージョン管理など 可能な限り再利用を促進する これらの懸念にどのように対処し、どの解決策が望ましいか、そしてその理由をどのように確認しますか？（同様の質問への回答も編集しています）

20 database-design  projects-and-solutions  multitenancy 

Userというテーブルにブールフィールドを持つアプリケーションがあるとしましょうInactive。 falseをnullとして保存するだけで本質的に問題はありますか？もしそうなら、あなたはマイナス面がどうあるべきかを説明できますか？これについては数か月前に誰かと議論しましたが、アプリ/データベース全体で一貫して行う限り、それは問題ではないことに同意しました。最近、私が知っている誰かが「真実」trueまたはfalse使用されるべきだと強調しましたが、彼らは本当に理由についての説明を本当にしませんでした。

20 database-design  null 

シナリオは、ユーザーの数が増えており、時間が経つにつれて、ユーザーが同じテーブルで現在「削除済み」（フラグ付き）としてマークしているアカウントをキャンセルすることです。 同じメールアドレス（つまり、ログイン方法）を持つユーザーが新しいアカウントを作成したい場合、再度サインアップできますが、新しいアカウントが作成されます。（すべてのアカウントに一意のIDがあるため、メールアドレスはライブおよび削除されたものの間で複製できます）。 私が気づいたのは、システム全体で、ユーザーのテーブルを常に照会する通常の過程で、ユーザーが削除されていないことを確認していますが、私が考えているのは、それを行う必要はまったくないということです... ！[明確化1：「常にクエリを実行する」ということは、「... FROM users WHERE isdeleted = "0" AND ...」のようなクエリがあることを意味します。たとえば、私たちはそのクエリで、特定の日にすべての会議のために登録されているすべてのユーザーを取得する必要があるかもしれません、我々はまた、 isdeleted =「0」のユーザーから持っている-これが私のポイントが明確にありません]？ (1) continue keeping deleted users in the 'main' users table (2) keep deleted users in a separate table (mostly required for historical book-keeping) どちらのアプローチの長所と短所は何ですか？

19 database  database-design 

私が正しく理解していれば、すべてRIGHT JOIN： SELECT Persons.*, Orders.* FROM Orders RIGHT JOIN Persons ON Orders.PersonID = Persons.ID 次のように表現できますLEFT JOIN。 SELECT Persons.*, Orders.* FROM Persons LEFT JOIN Orders ON Persons.ID = Orders.PersonID 私の個人的な意見は、声明の意図は次のとおりです。 最初に Persons 次にPersons、必要に応じてを展開/繰り返して、Orders はPersons LEFT JOIN Orders、逆の順序よりもの順序で表されOrders RIGHT JOIN Personsます（RIGHT JOIN結果として私は決して使用しません）。 RIGHT JOINが望ましい状況はありますか？または、できないRIGHT JOINことを実行できるユースケースはありますLEFT JOINか？

18 database-design  sql  relational-database 

この質問は、データベースをどのように設計する必要がありますか？それは、より良いソリューションになるものに応じて、リレーショナル/ nosqlデータベースにすることができます 「会社」と「ユーザー」を追跡するデータベースを含むシステムを作成する必要があるという要件があるとします。1人のユーザーは常に1つの会社にのみ属します ユーザーは1つの会社にのみ所属できます 会社は多くのユーザーを持つことができます 「会社」テーブルの設計は非常に簡単です。会社には次の属性/列があります：（簡単にしましょう） ID, COMPANY_NAME, CREATED_ON 最初のシナリオ シンプルでわかりやすい、ユーザーはすべて同じ属性を持っているため、これはリレーショナルスタイルのユーザーテーブルで簡単に実行できます。 ID, COMPANY_ID, FIRST_NAME, LAST_NAME, EMAIL, CREATED_ON 2番目のシナリオ さまざまな企業がユーザーのさまざまなプロファイル属性を保存する場合はどうなりますか。各会社には、その会社のすべてのユーザーに適用される定義済みの属性セットがあります。 例えば： 会社Aは、LIKE_MOVIE（ブール値）、LIKE_MUSIC（ブール値）を保管したいと考えています。 会社Bが保存したい：FAV_CUISINE（文字列） 会社Cは、OWN_DOG（ブール値）、DOG_COUNT（整数）を保存したい アプローチ1 ブルートフォースの方法は、ユーザーに単一のスキーマを持たせ、彼らが会社に属していない場合にnullを持たせることです： ID, COMPANY_ID, FIRST_NAME, LAST_NAME, EMAIL, LIKE_MOVIE, LIKE_MUSIC, FAV_CUISINE, OWN_DOG, DOG_COUNT, CREATED_ON 多くのNULLと、それらに関係のない列を持つユーザー行（つまり、会社Aに属するすべてのユーザーはFAV_CUISINE、OWN_DOG、DOG_COUNTのNULL値を持つ）になってしまうため、これはやや厄介です アプローチ2 2番目のアプローチは、「自由形式フィールド」を持つことです。 ID, COMPANY_ID, FIRST_NAME, LAST_NAME, EMAIL, CUSTOM_1, CUSTOM_2, CUSTOM_3, CREATED_ON カスタムフィールドとは何なのかわからないため、それ自体は厄介です。データ型は、格納されている値を反映しません（たとえば、int値をVARCHARとして格納します）。 アプローチ3 …

18 database  database-design  sql  nosql 

まず、この質問はデータベース交換に属していると思いましたが、データベースよりもプログラミングソリューション全体に関連していると思います。人々がそれを最高だと思うなら、データベース交換に移行します。 データベーステーブルに作成および更新されたタイムスタンプをいつ追加する必要があるのか​​疑問に思いましたか？ 最初の明らかな答えは、何かが更新されたとき（トランザクション完了日など）をビジネスロジックが知る必要がある場合、それを入力する必要があるということです。 しかし、非ビジネスロジックの場合はどうでしょうか。たとえば、いくつかのビジネスロジックが失敗し、関連するデータベースの行を確認して、1つの行が更新される前に識別することができるなど、障害の検出に役立つように行が変更された日時を知ることが本当に役立つシナリオを考えることができますエラーの原因となっている別の行。 このユースケースでは、すべてのテーブルに更新を与えてタイムスタンプを作成することは理にかなっています（アプリケーションのどの部分によっても更新されない最も単純な列挙テーブルを除く）。 すべてのテーブルにタイムスタンプを与えることは、間違いなくデータベースをすぐに停止させる素晴らしい方法です。 それでは、データベーステーブルはいつタイムスタンプの作成と更新を使用すべきですか？

18 database  database-design  mysql  debugging  logging