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

現在のところ、この質問はQ＆A形式には適していません。回答は、事実、参考文献、または専門知識によってサポートされると予想されますが、この質問は、議論、議論、世論調査、または広範な議論を求める可能性があります。この質問を改善し、おそらく再開できると思われる場合は、ヘルプセンターをご覧ください。 6年前に閉鎖されました。 インデックスを使用してデータベースのパフォーマンスを向上させるためのDOとDONTは何ですか？ DOは、インデックスを作成する必要がある場合、またはパフォーマンスを改善する別のインデックス関連のヒントです。 DONTは、インデックスを作成する必要がない場合、またはパフォーマンスを損なう可能性のある別のインデックス関連のアクションです。

17 database  performance  mysql  database-design 

一般的に言えば、webappのデータベースにユーザーが作成したフィールドを許可することは悪い習慣と見なされますか？ たとえば、妻用のホームインベントリwebappを作成していますが、妻はさまざまなアイテム用に独自のフィールドを定義したいと考えています。私は彼女がアイテムのカテゴリを作成し、それらのカテゴリに「機能」を追加できるようにすることを計画していました。機能は、文字列として保存されたキー/値になります。たとえば、「オーディオCD」というカテゴリがある場合、「アーティスト」、「トラック」などの機能を追加できますが、「家具」などの別のカテゴリでは、「素材」などの機能を追加できます「（木材、プラスチックなど）。次に、任意のアイテムを1つ（または多数）のカテゴリに属し、それらの機能をアイテムに追加します。 これらの機能による検索には文字列の比較が必要であり、データの検証が必要ないなどの問題を見ることができます。アジャイル方法論に従って、新しいカテゴリと属性を考え出すことをお勧めします。私たちが行くように。私の例では、それは小さなユーザーベース（2人）であり、作成されるレコードの量は少ないので、それほど悪くはありません。 しかし一般的に言えば、人々は「現実の生活」でこのようなことをどのように処理しますか？

17 web-applications  database-design  patterns-and-practices 

閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 5年前に閉鎖されました。 現在、一般的な顧客情報（ユーザーID、パスワード、姓、名、電子メール、住所、telfnrなど）のデータベースを作成する新しいプロジェクトの可能性を評価しています。この時点で、要件は大まかにのみ定義されています。 顧客DBは、何百万ものレコードに含まれていると予想されます。DBサイジングのためのいくつかの裏側の数値を計算し、潜在的なDBオプションとアーキテクチャを評価するために、これらの種類のレコードの事実上の標準を探しています。特に、すべてのフィールド（名、姓、住所など）の標準サイズ、または単純な顧客レコードの一般的な平均は素晴らしい情報です。 非常に多くのeコマースWebサイトがあるため、再利用でき、車輪の再発明を避けることができる、ある種の典型的な構成が必要です。 何か案は？ ----編集---- 答えは、標準の顧客レコードを採用するのではなく、独自のレコードを設計することに向かっているようです。この質問の焦点は、顧客オブジェクトのフィールドサイズの参照を見つけることであり、それを自分で理解することを避けることであることを強調したいと思います（元のテキストの部分を強調しました- 今は太字にしています）。

17 database  database-design  enterprise-architecture 

多くのアプリケーションでは、テーブルのレコードに「完了」、「ドラフト」、「キャンセル」などのステータスを設定する必要があります。これらのステータスを保存する最良の方法は何ですか？私がここで得ているものを説明するのは、*非常に短い）例です。 簡単なブログアプリケーションがあり、各投稿のステータスは、公開済み、下書き、保留中のいずれかです。 私がそれを見る方法は、データベースでこれをモデル化する2つの方法があります。 Postテーブルには、ステータステキストを含むテキストフィールドがあります。 Postテーブルには、PostStatusテーブル内のレコードのIDを含むステータスフィールドがあります ここのブログの例は、非常に単純な例です。列挙型（サポートされている場合）で十分な場合があります。ただし、ステータスのリストはいつでも変更される可能性があることを考慮に入れて、質問への回答が欲しいので、追加または削除できます。 誰もがそれぞれの長所/短所を説明できますか？ 乾杯！ これに関する私の最初の選択は、別のテーブルを使用し、正規化に適しているとステータスを調べる方が良いことです。正規化はデータベースに適しているといつも教えられてきました

17 database-design 

ユーザーが編集可能なコンテンツを含むWebプロジェクトに取り組んでおり、データベースにある実際のコンテンツのバージョントラッキングを実行できるようにしたいと考えています。基本的に、wikiスタイルの変更履歴を実装したいと思います。 いくつかのバックグラウンド調査を行うと、データベーススキーマをバージョン管理する方法に関するドキュメントがたくさんあります（私のものは実際には既に制御されています）が、データベースコンテンツの変更を追跡する方法に関する既存の戦略は、少なくともスキーマバージョン管理の雪崩では失われます私の検索で。 私は自分の変更追跡を実装するいくつかの方法を考えることができますが、それらはすべてかなり粗雑に見えます： 変更ごとに行全体を保存し、主キーを使用して行をソースIDに関連付けます（現在私が傾倒しているのは、最も単純な方法です）。ただし、多くの小さな変更により、大量のテーブルが膨張する可能性があります。 各変更の前/後/ユーザー/タイムスタンプを保存し、変更を関連する列に関連付ける列名を付けます。 before / after / user / timestampを各列のテーブルに保存します（結果としてテーブルが多すぎます）。 列ごとに変更ごとにdiff / user / timestampを保存します（つまり、特定の日付に戻るには、変更履歴全体をたどる必要があります）。 ここで最善のアプローチは何ですか？自分自身を転がすことは、おそらく他の誰かの（より良い）コードベースを再発明しているように思えます。 PostgreSQLのボーナスポイント。

16 version-control  database-design 

私は過去6年間プログラマーでした。私のキャリアを通じて、私は多くのWebアプリケーションに取り組んできました。 ほとんどの場合、データベースが必要になったとき、それは私たち（プログラマー）に与えられたか、作業するレガシーデータベースがありました。そうでない場合は、データベースを独自に作成および設計する必要がありましたが、それほど難しくはありませんでした。 しかし、プログラマーとして、データが非常に重要で複雑なデータモデルを使用して厄介な要件を持つ新しいアプリケーションを構築する必要がある場合、データベース全体をゼロから作成することになっていますか？ 専門家がそれを成し遂げることは、アプリと会社の最大の利益ではありませんか？ 私はデータベースの設計から逃げようとはしていませんが、それを正しく行うことはとても重要なことです。

16 database  web-applications  database-design 

外部キー、制約、デフォルト値などの項目は、データベース管理システム（この場合はMS SQL 2005）またはアプリケーションによって処理される必要がありますか？両側から意見を聞いたことがありますが、どちらに行くべきかは正直わかりません。 複数のサーバー/データベースにまたがる可能性があり、リンクサーバー間で外部キーを使用できるとは思いません。それに加えて、データベース設計にはいくつかの循環参照があり、ON UPDATE CASCADEすべてを使用できません。 データベースはMS SQL 2005（おそらく2008）であり、データベースとのすべてのやり取りはアプリケーションを介して行われる必要があります。

16 database-design  database-development 

次のERダイアグラムがあるとします。 ここSchoolでStudent、inの外部キーを使用して関係を表す場合、NULL値を持つことができます（a Student に属する必要はないためSchool）。たとえば、 したがって、正しい方法（読んだ内容に基づいて）は、リレーションシップを表す交差テーブルを作成することです。次に例を示します。 この方法でNULLは、表に値を含めることはできませんSchool_has_Student。 しかし、交差テーブルを作成する代わりにNULL入力可能外部キーを使用することの欠点は何ですか？ 編集： 誤って（school_id、student_id）をSchool_has_Studentテーブルのプライマリキーとして選択したため、多対多の関係になりました。正しい主キーは次のstudent_idとおりでした。

15 database  database-design  relational-database 

PHP、MySQL、Jqueryテンプレート、JSONを使用して、非常に簡単なToDoリストアプリケーションを作成しようとしています。しかし、私のスキーマはJSONで物事を複雑にしているようです。 それを行う最良の方法は何ですか？ アイテムを含む各リストの新しいテーブル。 または リスト用のテーブル、および何らかの形で結合されたアイテム用のテーブル？私はこれを試してみましたが、それを行う正しい方法のように思われないからですか 例http://jsfiddle.net/Lto3xuhe/

15 database  database-design 

この質問が広すぎないことを願っています。将来的には、いくつかのアプリケーション（主にWebベースのアプリケーションですが、私の質問はデスクトップアプリケーションにも関係します）にいくつかの会計および財務追跡システムを追加する必要があります。 現在、金融取引の簡単な記録を作成することは理論的には簡単です。いくつかの列を持つ1つのデータベーステーブルで作業を行うことができます。MS Access、Excel、または単なるASCIIテキストファイルでさえ、取引日、アカウントID、および金額を保存するために使用できます。ただし、トランザクションの整合性を備えた頻繁にバックアップされるSQLテーブルでさえ、深刻な財務追跡には十分な堅牢性がない場合があります。 「ダブルエントリアカウンティング」などの用語を耳にしますが、ほとんどの財務追跡アプリ（たとえば、Mint.com、GnuCash）には、すべてを確実に二重にするために、はるかに複雑なデータ構造またはプロセスが用意されているように感じます必要に応じて完全に加算され、データが失われたり破損したりすることはありません。 私の質問は次のとおりです。金融取引を追跡するアプリを設計するとき、特別な設計上の考慮事項を作成する必要がありますか？非常に多くの潜在的な問題があるようです...丸め精度、パリティチェック、ある種の監査プロセス、特別なバックアップ、セキュリティ/暗号化、データ入力中にクラッシュした場合のデータを保護する追加の方法に関する問題。 ...私が具体的に何を尋ねるべきかは本当にわかりませんが、プログラミング業界には私が何も知らない一連のベストプラクティスがあると感じています。彼らは何ですか？ 編集： 予想以上に大きなワームの缶を開けたようです。明確にするために、私は特に2種類のアプリについて考えています。 GnuCashやQuickenなどの「レジストリの確認」タイプのアプリは、個人が使用するトランザクションを記録します。 企業と取引するベンダーと顧客の請求書/クレジット/または「ポイント」を追跡するアプリ。 私は恐らく、ダイレクトバンキングや（関連する）多くの金融関連の政府規制が添付されているものは何もしないでしょう。

15 security  database-design  financial  system-reliability 

私の現在のデータベース設計では、各列に任意のキーを割り当てる追加の列を作成する代わりに、複数列の主キーを使用して既存のデータ（とにかく一意）を使用しています。私はこれが許可されていることを知っていますが、これが私が慎重に使用し、おそらく回避する可能性のある慣習であるかどうか疑問に思っていました（Cのgotoのように）。 それでは、このアプローチで見られるかもしれない欠点や、単一の列キーが必要な理由は何ですか？

15 database-design 

役割ベースのアクセス制御モデルに従って、システムでユーザーができることまたはできないことを制限しようとしています。 これまでのところ、次のエンティティがあります。 users-システムを使用する人。ここにユーザー名とパスワードがあります。 roles-ユーザーが持つことができる役割のコレクション。マネージャー、管理者などのリソースのような もの-ユーザーが操作できるもの。契約、ユーザー、契約草案などの 操作のように -ユーザーがリソースでできること。作成、読み取り、更新、削除など。 さて、このような関係があるダイアグラムでは、ここで疑問が浮上します。 操作（0 .. *）は リソース（0 .. *）に対して実行され、permissionsという名前のテーブルを生成し、操作とリソースを保存します。 許可テーブルは次のようになります（1行）： ID： 1、操作： create、リソース： contract。 どの意味許可する作成の契約を。 一部のリソースにはすべての種類の操作が含まれていない可能性があると感じているため、このようにしました。たとえば、契約を登録する場合、ユーザーはファイルをアップロードできますが、この操作はプロバイダーの登録には使用できません。 そのため、管理者がロールにアクセス許可を付与するときに、システムに登録されたすべての単一操作のリソースのリストはありません。 各リソースには、自分で実行できる独自の操作のコレクションがあると思います。 何かが理解できない場合は明確にすることができます。 これは、rbacを実装する正しい方法ですか？ 編集 つまり、操作とリソースを持つアクセス許可テーブルを使用することで、リソースを操作に関連付けるために2つの余分なテーブルがあります。また、私はちょうど行っている可能性のリソースが持っている権限の許可テーブルが権限を格納します。 しかし、その場合、管理者がリソースを割り当てたときに、一部のリソースには存在しないアクセス許可が表示されていた可能性があります。 だから私は、データベース設計の観点から、1つの列操作と別のリソースを持つこのテーブル権限が正しいかどうか知りたいですか？この状態が続くと問題が発生しますか？

15 database-design  authorization  permissions  access-control  roles 

閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 2年前に閉店。 早い段階でクライアントからデータA、B、Cを収集するアプリケーションを設計していますが、後でデータA、B、Dを収集します。 A、B、C、およびDは非常に関連性が高く、現在は単一のデータベースPostgreSQLテーブルTの列として存在しています。 Cが不要になったら、アプリケーションからその参照を削除します（Django ORMを使用します）が、既に入力されたデータを保持します。そうするための最良の方法は何ですか？ ABD用の新しいテーブルを作成することを考えましたが、それはテーブルTを参照する行で問題が発生する可能性があることを意味します。 列Cをそのまま残し、コード内の列Cへの参照を削除して、既存のデータが生き残るようにすることができます。 表示されていないより良いオプションはありますか？ いくつかの追加の詳細： 行の数は多くなく、おそらくユーザーごとに1〜2です。これは大衆市場のアプリケーションですが、CからDに切り替えるまでに、ユーザーベースはまだそれほど大きくありません。CとDは同時に収集されない可能性がありますが、可能性はあります。CとDは、それぞれ1つだけでなく、複数の列を表している可能性があります。

14 database  database-design  legacy  postgres 

多くの場合、自然キーを持たないテーブルでは、ユーザーが一意に生成された識別子を保持できると便利です。テーブルに代理主キーがある場合（そして、そのような場合は必ず期待します）、そのキーをユーザーに公開する必要がありますか、その目的で別のフィールドを使用する必要がありますか？ サロゲートキーを公開しない理由の1つは、レコード間の関係を保持する操作を実行できないが、特定の種類の削除/再挿入、1つのデータベースからデータをコピーする多くの方法など、キー値を変更することです他など 代理キーを公開する主な利点は、とにかく持っているフィールドを簡単に使用できることです。 どのような状況で、代理キーをユーザーに直接公開する方がよいでしょうか？

14 design  database-design  relational-database  rdbms  surrogate-keys 

閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 4年前に閉鎖されました。 「フォトアルバムアプリケーションの設計方法を説明する」、「この特定のWebサイトのこの特定の機能を設計する方法を説明する」などのインタビューの質問を収集しましたブラックジャックの）。次に、このものが何百万ある場合はどうなりますか？何を変えますか？ これは、データベーススキーマまたはクラス定義の束（またはその両方）を想定しているようです。私は学校でデータベースについて学んだことがありますが、実際にアプリケーションを設計したことがなく、どこから始めればよいか、思いついた設計が「良い」かどうか、スケーラブルにするために何を変更できるかがわかりません。 これらのシステムを設計するとき、一般的なアプローチまたは思考プロセスはありますか？そして、私が回避しようとする必要がある設計で多くのように思われる一般的な問題/問題？誰かが私にこれらの1つ（または好ましくはすべて、それぞれのニーズを比較しながら）を見て、説明することができますか？ 1）どのエンティティが必要かをどのように思い付きますか？2）すべての関係をどのように決定しますか？3）パフォーマンスの最適化を設計にどのように組み込みますか？4）クラスまたはデータベースを使用してこれを行いますか？違いがありますか（つまり、実際にデータベーステーブルに変換できないクラスがあるでしょうか？） 私が質問している主な理由は、「コーディングインタビューをクラックする」ことを行っていたためであり、私の答えは著者のものとは完全に異なっていたためです。 私の試み： 写真共有アプリを使えば、クラスとテーブルが必ずあります：写真とユーザー。 次に、スキーマを作成しようとしている場合、写真の各人が写真にリンクされていると仮定すると、写真とユーザーをリンクするテーブルがあると思います（このテーブルは必要ですか？そうでない場合でも、それはまだ一般的な習慣ですか？多対多のリレーションシップ用に別のテーブルを作成するかどうか）。 しかし、オブジェクト指向のアプローチをとろうとしている場合は、代わりに、すべての作業を実行し、他の2つのテーブル/クラスからのすべての情報を保持するalbumというクラスを用意します。これは私が本で気づいた1つのことです-クラスの束があり、基本的にすべての情報を持ち、他のクラスを接続する1つのクラス-これは一般的ですか？たとえば、上記の私の例では、これは適用されるように見えますか？ 現時点では、大規模システムの優れたアーキテクチャがどのように見えるかを知る方法がわからないため、いくつかの一般的なルール/ガイドラインに従うことを望んでいます。

14 object-oriented  interview  database  web-applications  database-design