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

ユーザーの性別をできるだけ少ない（サイズ/パフォーマンス）コストでデータベースに保存したい。 これまでに3つのシナリオが思い浮かびます INT - （1 =男性、2 =雌、3 = ...）コードで列挙と整列 CHAR（1） - ストアM、Fまたは別の単一の文字識別子 ビット （ブール） - このオプションに適切なフィールド名はありますか？ 私が尋ねる理由は、charsがboolean よりも小さいというこの回答のためです。 私はMS SQL 2008を使用していることを明確にする必要があります。MSSQL 2008 は実際にはビットデータ型です。

130 sql  database-design 

私たちのソフトウェアは現在MySQLで実行されています。すべてのテナントのデータは同じスキーマに格納されます。Ruby on Railsを使用しているため、どのデータがどのテナントに属しているかを簡単に判別できます。ただし、データが危険にさらされるのではないかと恐れている企業もあるので、他のソリューションを評価しています。 これまでのところ、3つのオプションを見てきました。 マルチデータベース（各テナントは独自に取得します-顧客ごとに1つのサーバーとほぼ同じです） マルチスキーマ（MySQLでは使用不可、各テナントは共有データベースで独自のスキーマを取得します） 共有スキーマ（現在のアプローチ。各列に追加の識別レコードがある場合があります） Multi-Schemaは私のお気に入りです（コストを考えると）。ただし、新しいアカウントを作成して移行を行うのは、すべてのスキーマを繰り返し処理し、それらのテーブル/列/定義を変更する必要があるため、非常に困難なようです。 Q：マルチスキーマは、テナントごとにわずかに異なるテーブルを持つように設計されているようです-これは必要ありません。テーブル構造がすべてのテナント間で共有されているマルチスキーマ、マルチテナントソリューションを使用できるRDBMSはありますか？ PSマルチとは、ウルトラマルチ（10000以上のテナント）のようなものを意味します。

129 sql  mysql  database-design  multi-tenant 

休業。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善してみませんか？この投稿を編集して、事実と引用で回答できるように質問を更新してください。 2年前休業。 この質問を改善する 回答をデータベースに保存する調査を作成する必要があります。これをデータベースに実装するための最良の方法は何ですか、特に必要なテーブルだけだと思います。調査にはさまざまな種類の質問が含まれています。例：コメントのテキストフィールド、複数選択の質問、および複数の回答を含む可能性のある質問（つまり、該当するものすべてをチェックしてください）。 私は2つの可能な解決策を考え出しました： 各調査の提出に対する回答を含む巨大なテーブルを作成します。各列は、調査の回答に対応します。つまり、SurveyID、Answer1、Answer2、Answer3 この調査には多くの質問があり、調査を変更する場合はあまり柔軟ではないため、これが最良の方法だとは思いません。 もう1つ考えたのは、質問テーブルと回答テーブルの作成です。質問表には、調査のすべての質問が含まれます。回答テーブルには、調査からの個々の回答が含まれ、各行が質問にリンクされます。 簡単な例： tblSurvey：SurveyID tblQuestion：QuestionID、SurveyID、QuestionType、Question tblAnswer：AnswerID、UserID、QuestionID、Answer tblUser：UserID、UserName これに関する私の問題は、Answerテーブルをかなり巨大にする大量の回答が存在する可能性があることです。パフォーマンスに関しては、それがそれほど素晴らしいことかどうかはわかりません。 任意のアイデアや提案をいただければ幸いです。

129 sql  database-design 

ここにMoney記載されているように、タイプは推奨されないようです アプリケーションは通貨を格納する必要があります。どのデータ型を使用する必要がありますか？数値、お金、またはFLOAT？

128 sql  postgresql  database-design 

職場では、主キーの代わりに一意のインデックスを持つ大きなデータベースがあり、すべて正常に動作しています。 新しいプロジェクト用に新しいデータベースを設計していますが、ジレンマがあります。 DB理論では、主キーは基本的な要素ですが、それは問題ありませんが、REALプロジェクトでは、両方の長所と短所は何ですか。 プロジェクトで何を使用していますか？ 編集： ...そしてMS SQLサーバー上の主キーとレプリケーションはどうですか？

127 sql  database  database-design 

閉まっている。この質問はスタックオーバーフローのガイドラインを満たしていません。現在、回答を受け付けていません。 この質問を改善してみませんか？Stack Overflowのトピックとなるように質問を更新します。 5年前休業。 この質問を改善する SQLソリューションの設計方法を学ぶための優れた情報源を知っていますか？ 基本的な言語構文のほかに、理解に役立つ何かを探しています。 作成するテーブルとそれらをリンクする方法 さまざまな規模に合わせて設計する方法（小さなクライアントアプリから巨大な分散Webサイトへ） 効果的/効率的/エレガントなSQLクエリを作成する方法

127 sql  database  database-design  scalability 

私は会社のRoRプロジェクトの設計に取り組んでおり、私たちの開発チームは、設計、具体的にはデータベースについて、少々議論を交わしています。 Message永続化する必要のあるというモデルがあります。これは、id以外にdb列が3つしかない非常に小さなモデルですが、本番環境に移行すると、これらのモデルが大量に存在する可能性があります。1日に最大100万件の挿入が見られます。モデルは、インデックスを作成できるモデル上の2つの外部キーによってのみ検索されます。また、モデルを削除する必要はありませんが、約3か月経過したモデルを保持する必要はありません。 では、このテーブルをPostgresに実装するとパフォーマンスに重大な問題が発生するのではないかと思います。これが問題になるかどうかを教えてくれる非常に大規模なSQLデータベースの経験がある人はいますか？もしそうなら、私たちはどの代替案を使うべきですか？

127 sql  ruby-on-rails  performance  postgresql  database-design 

プロジェクトでは、エンティティのすべてのリビジョン（変更履歴）をデータベースに保存する必要があります。現在、このために設計された2つの提案があります。 例：「従業員」エンティティ デザイン1： -- Holds Employee Entity "Employees (EmployeeId, FirstName, LastName, DepartmentId, .., ..)" -- Holds the Employee Revisions in Xml. The RevisionXML will contain -- all data of that particular EmployeeId "EmployeeHistories (EmployeeId, DateModified, RevisionXML)" デザイン2： -- Holds Employee Entity "Employees (EmployeeId, FirstName, LastName, DepartmentId, .., ..)" -- In …

125 sql  database  database-design  versioning 

製品コードを格納するフィールドがあります。コードは一意ですが、一部の製品にはコードがありません。これらはプロバイダーコードであるため、コードを作成できません。 MySQLでこの種の制約は可能ですか？ 私はストアドプロシージャとトリガーの初心者なので、ソリューションにこれらのいずれかが含まれる場合は、しばらくお待ちください。 更新：列はNULLではありません。それが私がこれを行うことができなかった理由です。

125 mysql  database-design  constraints 

したがって、これは設計上の問題です。 私には1つの主キー（たとえば、ユーザーのID）があり、そのユーザーに関連付けられた大量の情報があります。 情報に従って複数のテーブルをカテゴリに分類する必要がありますか、それとも多くの列を持つ1つのテーブルだけにする必要がありますか？ 以前は、アプリケーションの使用状況データ用の1つのテーブル、プロファイル情報用の1つのテーブル、バックエンドトークン用の1つのテーブルなど、複数のテーブルを用意して、構成を整理していました。 最近、そのようにしない方がいいとのコラムがたくさんあり、たくさんの列を持つテーブルを用意するのが良いと私に言いました。問題は、これらの列はすべて同じ主キーを持っているということです。 私はデータベース設計にかなり慣れていないので、どちらのアプローチがより優れており、長所と短所は何ですか？ それを行う従来の方法は何ですか？

124 mysql  database-design 

私はプログラマーであり、正直に言うと、世界の住所の構造がわからないのですが、私の国ではどのように構造化されているのでしょうか。1つのIDでちょうど識別され、世界のすべての住所格納するのに使用する、高速なクエリと動的に簡単なので、それはする必要がありますおかげで多くのことを

122 sql  database-design  street-address  postal-code 

これについて不思議に思っているのは私だけではないと思います。通常、データベースの動作について何を実践していますか？データベースからレコードを物理的に削除しますか？または、「削除済み」フラグまたはブール列でレコードにフラグを立てて、レコードがアクティブまたは非アクティブであることを示す方が良いでしょうか？

117 database  database-design 

顧客IDへの外部キーを持つOrdersテーブルがあるとします。ここで、顧客IDなしで注文を追加するとします（それが可能かどうかは別の質問です）、外部キーをNULLにする必要があります...これは悪い習慣ですか、それとも、注文と顧客？関係は1対nですが、リンクテーブルはn対nになります。一方、リンクテーブルでは、これらのNULLはもうありません... NULLへの外部キーを持つレコードは、注文の顧客が追加されるまでの一時的なものであるため、実際にはデータベースに多くのNULLはありません。 （私の場合、それは注文でも顧客でもありません）。 編集：リンクする割り当てられていない顧客はどうですか？

114 database-design 

休業。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善してみませんか？この投稿を編集して、事実と引用で回答できるように質問を更新してください。 2年前休業。 この質問を改善する さまざまな変更ログ/監査（何かが追加、削除、変更されたときなど）を格納するデータベーステーブルを作成する必要があります。特に詳細な情報を保存する必要がないので、次のように考えていました。 id（イベント用） トリガーしたユーザー イベント名 イベントの説明 イベントのタイムスタンプ ここで何か不足していますか？明らかに、設計を改善し続けることはできますが、複雑にするつもりはありません（イベントタイプなどのテーブルを他に作成することは、私にとって複雑なため、問題外です）。

114 database  database-design  audit 

だから、あたりに関連する質問への答えMehrdad、私はそれを得る「適切な」データベース表の列がリストを格納していないこと。むしろ、上記のリストの要素を効果的に保持する別のテーブルを作成してから、直接または結合テーブルを介してそれにリンクする必要があります。ただし、作成するリストのタイプは、一意のアイテムで構成されます（リンクされた質問のフルーツとは異なります）例）。さらに、リスト内の項目は明示的に並べ替えられています。つまり、要素を別のテーブルに保存した場合、アクセスするたびに並べ替える必要があります。最後に、リストは基本的にアトミックです。リストにアクセスしたいときはいつでも、リストの一部ではなくリスト全体にアクセスしたいので、データベースクエリを発行して複数のリストを集めるのはばかげているようです。リスト。 AKXのソリューション（上記にリンク）は、リストをシリアル化してバイナリ列に格納することです。しかし、シリアル化と逆シリアル化について心配する必要があることを意味するため、これも不便に思われます。 より良い解決策はありますか？より良い解決策がない場合、なぜですか？この問題は時々発生するようです。 ...私がどこから来たのかを知らせるためのもう少しの情報。SQLとデータベースの一般的な理解を始めた直後に、LINQ to SQLに切り替えられました。オブジェクトがどのように動作するかを考えずにプログラミングオブジェクトモデルを扱うことを期待しているので、今は少し甘やかされています。照会またはデータベースに格納されます。 皆さんありがとう！ ジョン 更新：それで、私が得ている最初の一連の答えで、「CSV / XMLルートに行くことはできますが、しないでください！」と表示されます。だから今私はその理由の説明を探しています。いくつかの良い参考文献を教えてください。 また、私が今何をしているのかをよりよく理解するために：私のデータベースには、（x、y）ペアのリストを持つFunctionテーブルがあります。（この表には、説明に影響しない他の情報も含まれます。）（x、y）ペアのリストの一部を見る必要はありません。むしろ、私はそれらすべてを取り、画面上にプロットします。ユーザーがノードをドラッグして値を変更したり、プロットに値を追加したりできるようにします。

114 sql  linq  linq-to-sql  database-design  linq-to-entities