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

（A）テーブルプレフィックスを使用して1つのMySQLデータベースにアプリケーションのインスタンスをデプロイするか、（B）アプリケーションの各インスタンスに異なるMySQLデータベースを使用できる状況があります。たとえば、 セットアップ「A」： central_database app1_table1 app1_table2 app1_tablen ... appn_table1 appn_table2 appn_tablen 最終結果は、多くのテーブルを持つ大きなデータベースになります。 セットアップ「B」： app1_db table1 table2 tablen ... appn_db table1 table2 tablen 最終結果は、いくつかのテーブルを持つ多くのデータベースになります。 すべてが等しい（データの量、アプリインスタンスの数など）、どちらのアプローチを採用する場合の長所と短所は何ですか？データベースのパフォーマンスとメンテナンスに有害なものは何ですか？アプリケーションはPHP 5ベースで、Apache 2.xで実行され、MySQL 5.xを実行しています。 あなたの時間と考えに感謝します！

14 mysql  database-design 

質問への回答を保存するために使用するテーブルがあります。特定の質問に対する特定の回答を持っているユーザーを見つけることができる必要があります。したがって、テーブルが次のデータで構成されている場合： user_id question_id answer_value Sally 1 Pooch Sally 2 Peach John 1 Pooch John 2 Duke そして、質問1で「Pooch」、質問2で「Peach」に答えるユーザーを見つけたいと思っています。次のSQLは（明らかに）動作しません。 select user_id from answers where question_id=1 and answer_value = 'Pooch' and question_id=2 and answer_value='Peach' 私が最初に考えたのは、探している答えごとにテーブルに参加することでした。 select a.user_id from answers a, answers b where a.user_id = b.user_id and a.question_id=1 and a.answer_value = 'Pooch' and …

14 mysql  database-design  join 

すべてのテーブルで単一のシーケンスを主キーとして使用することは受け入れられる慣行ですか？その場合、テーブル全体で単一の主キーシーケンスを使用するよりも客観的に優れていますか。 私はDBAではなく、ジュニアソフトウェア開発者なので、優れたデータベース設計の基本の多くをまだ学んでいます。 編集：誰かが疑問に思っている場合、私は最近、私たちのデータベース管理者の1人によるデータベース設計の批判を読みました。私はこれまでに学びました。 編集2：コメントの質問に答えるために、これはOracle 11g用ですが、データベース固有ではないレベルで疑問に思っていました。この質問がデータベースに依存する場合、その理由を知りたいと思いますが、そのような場合、Oracleに固有の回答を探しています。

14 database-design  primary-key 

テーブル間の外部キーを自然キーまたはサロゲートキーにリンクするかどうかのベストプラクティスはありますか？私が本当に見つけた唯一の議論は（私のgoogle-fuが欠けていない限り）この質問でのJack Douglasの答えです。私はルールが変わるということを超えた議論を知っていますが、これはどんな状況でも考慮する必要があるものです。 尋ねる主な理由は、自然キーを持つFKを使用するレガシーアプリケーションがあることですが、開発者からOR / M（この場合はNHibernate）に移行する強いプッシュがあり、フォークは既にいくつかを生成していることです変更を壊すので、自然キーを使用して変更を元に戻すか、FKのサロゲートキーを使用するようにレガシーアプリを移動します。私の腸は元のFKを復元すると言っていますが、これが本当に正しい道かどうかは正直わかりません。 テーブルの大部分には、既に一意キーとPKが定義された代理キーと自然キーの両方が既に定義されているため、このインスタンスでは余分な列を追加する必要はありません。SQL Server 2008を使用していますが、これがすべてのDBに十分な汎用性を持っていることを願っています。

14 database-design  foreign-key  surrogate-key  natural-key 

データを保存するテーブルがいくつかあり、仕事をした人のタイプ（労働者、市民）に応じてeventテーブルに保存しますが、今ではこれらの人が動物を救いanimalます（テーブルがあります）。 最後に、男（労働者、市民）が動物を救ったというイベントを保存するテーブルが必要ですが、お辞儀をする必要がありidますか、または仕事をした市民または労働者の価値を知る方法はありますか？ さて、このデザインでは、どの人が仕事をしたかをどのように関連付けるかわかりません、私はこの最後の表の列にcivil_idベールを保存するだけの人（別名市民）しかいpersonません...しかし、どのように市民か労働者かを知っている場合、他の「中間」テーブルが必要ですか？ 次の図の設計をMySQLに反映する方法は？ 追加の詳細 次の方法でモデル化しました。 DROP TABLE IF EXISTS `tbl_animal`; CREATE TABLE `tbl_animal` ( id_animal INTEGER NOT NULL PRIMARY KEY AUTO_INCREMENT, name VARCHAR(25) NOT NULL DEFAULT "no name", specie VARCHAR(10) NOT NULL DEFAULT "Other", sex CHAR(1) NOT NULL DEFAULT "M", size VARCHAR(10) NOT NULL DEFAULT "Mini", edad VARCHAR(10) NOT …

14 mysql  database-design  subtypes 

私はPostgreSQLを使用していますが、ほとんどのトップエンドデータベースには同様の機能が必要であり、さらにそれらのソリューションがソリューションを刺激する可能性があると考えているため、このPostgreSQL固有のものを考慮しないでください。 私はこの問題を解決しようとする最初の人ではないことを知っているので、ここで質問する価値があると思いますが、すべてのトランザクションが基本的にバランスが取れるように会計データをモデル化するコストを評価しようとしています。アカウンティングデータは追加専用です。ここでの全体的な制約（擬似コードで記述）は、おおよそ次のようになります。 CREATE TABLE journal_entry ( id bigserial not null unique, --artificial candidate key journal_type_id int references journal_type(id), reference text, -- source document identifier, unique per journal date_posted date not null, PRIMARY KEY (journal_type_id, reference) ); CREATE TABLE journal_line ( entry_id bigint references journal_entry(id), account_id int not null references account(id), …

14 database-design  postgresql  data-integrity 

私は、7つのデータベースを使用する必要がある新しいプロジェクトに取り組んでおり、パフォーマンス、安定性、最適化をより簡単に実装できると主張していました。 私は同意しませんが、単一のデータベースを使用する（テーブルを論理ドメインに分割する）ための適切な引数を収集するのに問題があります。 これまでの議論の1つは、データの整合性です（データベース間で外部キーを使用することはできません）。 単一または複数のデータベースを使用する場合の長所と短所は何ですか？ [これまでの概要] 複数のデータベースに対する引数： データの整合性が失われます（データベースで外部キーを使用できません） 復元の整合性を失う 複雑化（dbユーザー/ロール） 小さなオッズのサーバー/データベースがダウンします ソリューション： スキーマを使用してドメインを分離します。 POC：ダミーデータを使用して7/1 dbの実行計画のポイントを証明する

14 sql-server  sql-server-2008  database-design  architecture 

Webサイトに基本的なパーソナライズされたユーザー機能を実装する必要があります。このタイプのデータベースの標準構造はありますか？すべてのユーザー情報とデータを単一のテーブルに入れて、各ユーザーが独自の行を持っているのが一般的な慣行であるか、この情報を異なるテーブルに分割して一緒にリンクする必要があります（おそらく効率のためですか？）この時点で、しかし、私は明らかにあまりにも早くパスワードの暗号化をしたいと思うでしょう。 私はグーグルで探していたものを見つけようとしましたが、役に立ちませんでした。質問にさらなる説明などが必要かどうかをお知らせください。

14 database-design 

私はhttp://en.wikipedia.org/wiki/Database_engineの定義を数回繰り返しました。 データベースエンジン（または「ストレージエンジン」）は、データベースからデータを作成、読み取り、更新、削除（CRUD）するためにデータベース管理システム（DBMS）が使用する基礎となるソフトウェアコンポーネントです。 私が理解していないのは、やらなければならないことです。データベースが行うすべてのことをCRUDではありませんか？ データベースエンジンがこれらの機能を実行する場合、データベースの残りの部分は何をしますか？

14 architecture  database-engine  database-design 

休業。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善してみませんか？この投稿を編集して、事実と引用で回答できるように質問を更新してください。 2年前休業。 複合主キーが悪い習慣であるかどうかを知り、そうでない場合は、どのシナリオを使用することが推奨されますか。 私の質問はこの記事に基づいています 複合主キーに関する部分： 悪い実践No. 6：複合主キー 現在、多くのデータベース設計者は、2つ以上のフィールドの組み合わせで定義された複合フィールドではなく、整数IDの自動生成フィールドを主キーとして使用することについて話しているため、これは論争の種です。これは現在「ベストプラクティス」として定義されており、個人的には同意する傾向があります。 ただし、これは単なる慣例であり、もちろん、DBEでは複合主キーを定義できます。これは、多くの設計者が避けられないと考えています。したがって、冗長性と同様に、複合主キーは設計上の決定事項です。 ただし、複合主キーを持つテーブルに数百万の行が含まれることが予想される場合、複合キーを制御するインデックスが、CRUD操作のパフォーマンスが非常に低下するところまで大きくなる可能性があることに注意してください。その場合、インデックスが十分にコンパクトで、一意性を維持するために必要なDBE制約を確立する単純な整数ID主キーを使用する方がはるかに優れています。

14 database-design 

私は小売業向けのデータベースシステムを構築しています。私はいくつかのテーブルを設定しました： 製品 購入 売上高 残高 すべてが相互に接続され、在庫レベルを表示できます。 私が抱えている問題は、個々の価格とは異なる価格を持つ製品のバンドルも販売していることです。 例：オレンジを1ドルで、リンゴを1.2ドルで販売しています。フルーツパッケージ1（オレンジ2個とリンゴ2個）を3.8ドルで、パッケージ2（オレンジ4個とリンゴ4個）を7ドルで販売しています。 これらの製品バンドルの関係を作成する正しい方法はありますか？ PS：私はこれを作成するFileMaker Proを使用しています。

13 database-design  relations  filemaker 

短縮版 既存の多対多結合の各ペアに、一定数の追加プロパティを追加する必要があります。基本ケースを拡張してこれを達成するために、利点と欠点の観点から、オプション1〜4のどれが最良の方法であるかを下の図にスキップしますか？または、ここで検討していないより良い代替手段がありますか？ 長いバージョン 現在、中間結合テーブルを介して、多対多の関係にある2つのテーブルがあります。既存のオブジェクトのペアに属するプロパティにリンクを追加する必要があります。プロパティテーブルの1つのエントリが複数のペアに適用される場合があります（または1つのペアに対して複数回使用される場合もあります）が、各ペアにはこれらのプロパティが固定されています。私はこれを行うための最良の方法を決定しようとしていますが、状況をどう考えるかを整理するのに苦労しています。意味的には、次のいずれかと同等にうまく説明できるようです。 固定数の追加プロパティの1つのセットにリンクされた1つのペア 多くの追加プロパティにリンクされた1つのペア 1つのプロパティセットにリンクされた多くの（2つの）オブジェクト 多くのプロパティにリンクされた多くのオブジェクト 例 XとYの2つのオブジェクトタイプがあり、それぞれに一意のIDがあり、リンクテーブルのobjx_objy列x_idとがありy_id、これらが一緒にリンクの主キーを形成します。各Xは多くのYに関連付けることができ、その逆も可能です。これは、既存の多対多の関係のセットアップです。 規範事例 さらに、別のテーブルで定義された一連のプロパティと、特定の（X、Y）ペアがプロパティPを持つ必要がある一連の条件があります。条件の数は固定され、すべてのペアで同じです。基本的に、「状況C1では、ペア（X1、Y1）にプロパティP1があります」、「状況C2では、ペア（X1、Y1）にプロパティP2があります」など、結合の各ペアの3つのシチュエーション/条件についてテーブル。 オプション1 私の現在の状況であり、正確にこのような3つの条件があり、一つの可能性は、列を追加することですので、私は、それが増加することを期待する理由がないc1_p_id、c2_p_idとc3_p_idにfeatx_featy、与えられたために指定するx_idとy_id、どのプロパティp_id3例ごとに使用します。 これは、SQLが機能に適用されるすべてのプロパティを選択するのを複雑にし、より多くの条件に容易にスケーリングできないため、私にとって素晴らしいアイデアのようには見えません。ただし、（X、Y）ペアごとに一定数の条件の要件を強制します。実際、それはここで唯一のオプションです。 オプション2 条件テーブルを作成し、条件テーブルcondの主キーに条件IDを追加します。 これの1つの欠点は、各ペアの条件の数を指定しないことです。もう1つは、最初の関係だけを考えているとき、たとえば SELECT objx.*, objy.* FROM objx INNER JOIN objx_objy ON objx_objy.x_id = objx.id INNER JOIN objy ON objy.id = objx_objy.y_id 次に、DISTINCTエントリの重複を避けるために句を追加する必要があります。これは、各ペアが一度しか存在しないという事実を失ったようです。 オプション3 結合テーブルに新しい「ペアID」を作成し、最初のテーブルとプロパティと条件の間に2番目のリンクテーブルを作成します。 これには、各ペアに一定数の条件を強制しないこと以外に、最も不利な点があるようです。ただし、既存のIDのみを識別する新しいIDを作成することは理にかなっていますか？ オプション4（3b） 基本的にオプション3と同じですが、追加のIDフィールドは作成されません。これは、新しい結合テーブルに両方の元のIDを配置することで実現されるため、の代わりにx_idとy_idフィールドが含まれますxy_id。 この形式のもう1つの利点は、既存のテーブルを変更しないことです（まだ運用されていません）。ただし、基本的にテーブル全体を複数回複製する（または、とにかくそのように感じる）ので、理想的とも思えません。 概要 私の感じでは、オプション3と4は十分に似ており、どちらでも使用できます。プロパティへの少数の固定数のリンクの要件がなければ、オプション1が他の場合よりも合理的に見えるようになるでしょう。いくつかの非常に限られたテストに基づいDISTINCTて、クエリに句を追加してもこの状況でのパフォーマンスに影響はないようですが、オプション2が他の状況と同様に状況を表すかどうかはわかりません。リンクテーブルの複数の行の同じ（X、Y）ペア。 これらのオプションの1つが私の最善の方法ですか、または考慮すべき別の構造がありますか？

13 relational-theory  database-design 

初めてのeコマーススキーマを設計しています。私はしばらくの間このテーマについて読んでいますが、との関係について少し混乱order_line_itemしていますproduct A productを購入できます。さまざまな詳細がありますが、最も重要なのはunit_priceです。 Anがorder_line_itemへの外部キーがあるproduct_id、購入quantity購入しunit_priceた時点で、顧客が製品を購入します。 私が読んだもののほとんどは、を明示的に追加unit_priceするorder_line_item必要がある（つまり、を介して参照しないproduct_id）と述べています。店舗は将来的に価格を変更する可能性があり、注文レポート、追跡、整合性などを台無しにする可能性があるため、理にかなっています。 私が理解していないことは、なぜunit_price値を直接保存するのorder_line_itemですか？ のunit_price変更を記録する監査/履歴テーブルを作成する方が良いproductでしょうか？ ときにorder_line_item作成され、の外部キーproduct_auditテーブルが追加され、価格はそこから（参照によって）取得することができます。 このアプローチを使用することには多くの利点があるように思えます（データの重複、価格変更履歴など）。このアプローチを使用するeコマーススキーマの例に出くわしていませんが、何か不足していますか？ UDPATE：私の質問はSlowly Changing Dimensionに関連しているようです。ただし、緩やかに変化するディメンションはデータウェアハウスとOLAPに関連しているため、私はまだ混乱しています。それで、Slowy Changing Dimensionタイプをメインのビジネストランザクションプロセスデータベース（OLTP）に適用できますか？私は多くの概念を混ぜているのだろうか、いくつかのガイダンスを大いに感謝します。

13 mysql  database-design  schema  audit  data-integrity 

特定のテーブルが多数の異なる親テーブルの1つにFKできるデータベースの状況に頻繁に出くわします。この問題に対する2つの解決策を見てきましたが、どちらも個人的に満足できるものではありません。私はあなたがそこに見た他のどのようなパターンに興味がありますか？それを行うためのより良い方法はありますか？ 不自然な例 システムが持っているとしましょうAlerts。アラートは、顧客、ニュース、製品などのさまざまなオブジェクトに対して受信できます。特定のアラートは、1つだけのアイテムに対応できます。何らかの理由で、顧客、記事、製品は動きが速い（ローカライズされている）ため、アラートの作成時に必要なテキスト/データをアラートに取り込むことはできません。このセットアップを考えると、2つのソリューションを見てきました。 注：以下のDDLはSQL Server用ですが、私の質問はどのDBMSにも当てはまります。 解決策1-複数のNullable FKey このソリューションでは、1対多のテーブルにリンクするテーブルに複数のFK列があります（簡潔にするため、以下のDDLにはFKの作成は示されていません）。 良い -このソリューションでは、外部キーを持っていると便利です。FKのヌル最適性により、この便利で正確なデータを比較的簡単に追加できます。BADクエリは、関連付けられたデータを取得するためにN LEFT JOINSまたはN UNIONステートメントを必要とするため、優れていません。SQL Serverでは、特にLEFT JOINSにより、インデックス付きビューの作成ができなくなります。 CREATE TABLE Product ( ProductID int identity(1,1) not null, CreateUTC datetime2(7) not null, Name varchar(100) not null CONSTRAINT PK_Product Primary Key CLUSTERED (ProductID) ) CREATE TABLE Customer ( CustomerID int identity(1,1) not null, CreateUTC datetime2(7) …

13 database-design 

SQL Serverのデータベース構造には、注文に関するさまざまな情報を必要とする3種類の製品があります。だから、私は1つ作成しCustomers、テーブルと三つの異なる受注テーブルを：OrdersForProductAs、OrdersForProductBs、OrdersForProductCs。すべての注文表には、1対多の関係がありCustomersます。 Payments支払いの詳細を内部に保持する別のテーブルもあります。しかし、ここでそれをどのように構成するかについて疑問があります。 複数の製品タイプがあり、顧客が複数の製品を同時に注文する可能性があるため、これら3つの注文テーブルをPaymentsテーブルに関連付ける必要があります。 もう1つの問題は、顧客が1種類の製品のみを注文する可能性があることです。したがって、PaymentsテーブルのFK列はである必要がありますnullable。 私の質問は、これらのnullableFKカラムが長期的には頭痛の種になるかどうかです。一般的に、テーブルにNULL入力可能FK列を設定することは悪い習慣と見なされますか？

13 sql-server  sql-server-2008  database-design  sql-server-2008-r2