タグ付けされた質問 「relational-theory」

nosql DBMSの大きな利点の1つは、より簡単にクラスタリングできることです。NoSQLを使用すると、さまざまなデータを格納する数百台の安価なマシンを作成して、一度にクエリを実行できます。 私の質問はこれです、なぜリレーショナルDBMSはmysqlやsqlサーバーのようにこれを行うことができないのですか？ベンダーが既存の製品でこれを行うための技術的な方法を理解していないだけなのか、それとも実現できないようにするリレーショナルモデルの問題がありますか？データ（キー/値、ドキュメントなど）を保存およびアクセスするNoSQLの方法で、これが本当に正しい場合、クラスタリングを容易にするのは何が素晴らしいですか？

88 clustering  nosql  scalability  relational-theory 

のA友人であればB、値ABとの両方を保存する必要BAがありますか、それとも1つで十分ですか？両方の方法の長所と短所は何ですか。 私の観察は次のとおりです。 両方を保持する場合、友人からリクエストを受け取ったときに両方を更新する必要があります。 両方を保持しないJOINと、このテーブルで複数の作業を行う必要があるときに困難を感じました。 現在、私は関係を一方向に維持しています。 この場合、どうすればよいですか？何かアドバイス？

33 mysql  relational-theory 

ANSI SQL標準定義（章6.5、セット機能仕様）空の結果セット上の集約関数の次の動作： COUNT(...) = 0 AVG(...) = NULL MIN(...) = NULL MAX(...) = NULL SUM(...) = NULL 空のセットの平均、最小、最大は定義されていないため、AVG、MIN、MAXにNULLを返すことは完全に理にかなっています。 ただし、最後の1つは気になります。数学的には、空のセットのSUMは明確に定義されています0。基本ケースがすべての一貫性を保つため、加算の中立要素である0を使用します。 SUM({}) = 0 = 0 SUM({5}) = 5 = 0 + 5 SUM({5, 3}) = 8 = 0 + 5 + 3 SUM({5, NULL}) = NULL = 0 + 5 + …

28 null  aggregate  relational-theory  sql-standard 

データベースを使用する際の一般的なニーズは、レコードに順番にアクセスすることです。たとえば、ブログがある場合、ブログの投稿を任意の順序に並べ替えることができます。これらのエントリには多くの場合、多くの関係があります。そのため、リレーショナルデータベースは理にかなっているようです。 私が見た一般的な解決策は、整数列を追加することですorder： CREATE TABLE AS your_table (id, title, sort_order) AS VALUES (0, 'Lorem ipsum', 3), (1, 'Dolor sit', 2), (2, 'Amet, consect', 0), (3, 'Elit fusce', 1); 次に、行を並べ替えorderて適切な順序で並べます。 しかし、これは不器用なようです： レコード0を先頭に移動する場合は、すべてのレコードを並べ替える必要があります 真ん中に新しいレコードを挿入したい場合は、その後のすべてのレコードを並べ替える必要があります レコードを削除する場合は、それ以降のすべてのレコードを並べ替える必要があります 次のような状況は簡単に想像できます。 2つのレコードは同じです order orderレコード間にギャップがあります これらは、いくつかの理由でかなり簡単に発生する可能性があります。 これは、Joomlaなどのアプリケーションがとるアプローチです。 ここでのインターフェイスは悪いと主張し、人間が直接数字を編集する代わりに、矢印またはドラッグアンドドロップを使用する必要があります。おそらく正しいでしょう。しかし、舞台裏では、同じことが起こっています。 一部の人々は、「2.5」を使用して順序2と3のレコードの間にレコードを挿入できるように、10進数を使用して順序を格納することを提案しています。そして、それは少し助けにはなりますが、奇妙な小数（どこで止まりますか？2.75？2.875？2.8125？） 注文をテーブルに保存するより良い方法はありますか？

28 database-design  relational-theory  order-by  database-agnostic 

英語では、たとえばボブとティムの関係について話すかもしれません。おそらく彼らはいとこです。この文脈での用語「関係」は私にとって理にかなっています。 リレーショナルデータベースの文脈では、この用語が何を指しているのかは理解していますが、なぜ使用されているのかはわかりません。なぜ使われるのかを理解することは、フィールドをよりよく理解するのに役立つと思うので、なぜ使われるのかを理解したいと思います。 たとえば、なぜ人は「関係」と見なされますか？英語では、関係は2つのエンティティがどのように関連付けられているかを表す名詞です。エンティティ自体を指すものではありません。リレーショナルデータベースのコンテキストでは、「関係」はエンティティ自体を指します。どうして？ リレーショナルモデルは、階層モデルとネットワークモデル（例：親、隣接）の後に来たことを理解しています。しかし、これらのモデルでは、エンティティは相互にも関係しています。では、なぜこのモデルをリレーショナルモデルと呼ぶのでしょうか？より具体的なフレーズ/用語はありますか？または、3つすべてのモデルがリレーショナルモデルであるが、階層モデルとネットワークモデルは特定のタイプのリレーショナルモデルであると言う必要がありますか？ 互いに関係のないスタンドアロンエンティティがある場合はどうなりますか。言う、人、ドア、そして木。「関係（al）」という用語はまだ適用可能ですか？ （おそらく、これは複数の質問である必要があります。答えは非常に関連性が高いと考えました-たぶん答えは1つだけかもしれません。代わりに個別の質問を作成します。） 編集：この図は、関係が異なるドメインを相互に関連付けていることを視覚化するのに役立ちます。

26 relational-theory  terminology 

データベースでルックアップテーブルを使用するタイミングと場所に適切な境界を設定する方法を正確に把握するのに苦労しています。私が見たほとんどの情報源は、あまり多くのデータを保持することはできないと言っていますが、ある時点で、データベースは非常に多くの部分に分割されるように見えるため、効率的ではあるが、管理できなくなります。ここに私が取り組んでいるもののスローされた例があります： Employeesというテーブルがあるとします。 ID LName FName Gender Position 1 Doe John Male Manager 2 Doe Jane Female Sales 3 Smith John Male Sales データがより複雑で、数百の行が含まれていると仮定します。ルックアップテーブルに移動できる最も明らかなものは、Positionです。Positionsというテーブルを作成し、Positionsテーブルの外部キーをPositions列のEmployeesテーブルに貼り付けることができます。 ID Position 1 Manager 2 Sales しかし、情報が管理不能になる前に、どの程度まで情報を小さなルックアップテーブルに分解し続けることができますか？別のルックアップテーブルで、性別テーブルを作成し、1を男性に、2を女性に対応させることができます。LNameとFNameをテーブルに入れることさえできました。すべての「John」エントリは、ID 1がJohnに対応することを示すFNameテーブルを指す外部キー1に置き換えられます。ただし、このウサギの穴をあまりにも下に移動すると、Employeesテーブルは大量の外部キーになります。 ID LName FName Gender Position 1 1 1 1 1 2 1 2 2 2 3 2 1 1 …

25 relational-theory 

各親について、1人または0人の子供が「お気に入り」としてマークされる1対多の関係が必要です。ただし、すべての親が子供を持つわけではありません。（このサイトでは、両親を質問、子供を回答、お気に入りを受け入れられた回答と考えてください。）たとえば、 TableA Id INT PRIMARY KEY TableB Id INT PRIMARY KEY Parent INT NOT NULL FOREIGN KEY REFERENCES TableA.Id 私の見方では、TableAに次の列を追加できます。 FavoriteChild INT NULL FOREIGN KEY REFERENCES TableB.Id または、TableBの次の列： IsFavorite BIT NOT NULL 最初のアプローチの問題は、null許容の外部キーを導入することです。これは、正規化された形式ではないことを理解しています。2番目のアプローチの問題は、多くても1人の子供がお気に入りであることを確認するために、より多くの作業を行う必要があるということです。 どのアプローチを使用するかを決定するには、どのような基準を使用する必要がありますか？または、私が検討していない他のアプローチはありますか？ SQL Server 2012を使用しています。

22 sql-server  database-design  foreign-key  normalization  relational-theory 

テーブルとビューに名前を付けるとき、どの標準に従う必要がありますか？たとえば、テーブル名の先頭にtbl_のようなものを置くのは良い考えですか？ct_、lut_、codes_のような方法でコード/ルックアップテーブルを指定する必要がありますか？他にすべきこと/禁止事項はありますか？ 私はMS SQL Serverを使用しており、多くのテーブルを持つ多くのデータベースを持っているので、いくつかの合理的なサポートを備えた標準として使用できるものがあると便利です。

20 relational-theory  naming-convention 

Delphi UIアプリケーションのバックエンドとなるMS SQL Serverデータベースのユーザー認証モジュールをモデル化しようとしています。基本的に、ユーザーが1つのグループにのみ所属するユーザーアカウントが必要です。グループは、「n」個の権利を持つことができます。 また、ユーザーがアプリケーション設定（たとえば、90日ごと）に基づいてパスワードを変更する必要があるため、パスワード履歴をデータベースに追加します。 また、ユーザーがログインおよびログアウトするたびにイベントを記録したいと思います。私はこれを将来の追加イベントに拡張するかもしれません。 以下に、私の最初のクラックを見つけます。これを行うのはこれが初めてなので、改善するための提案があれば教えてください。 役割ベースのセキュリティの追加属性とパスワードルール/有効期限の制約が必要ですか？

15 database-design  datatypes  relational-theory  database-tuning 

短縮版 既存の多対多結合の各ペアに、一定数の追加プロパティを追加する必要があります。基本ケースを拡張してこれを達成するために、利点と欠点の観点から、オプション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 

SQL質問を使用したリレーショナルデータベース内のツリー状データのトラバースに基づいて、物理的意味を考慮してリレーショナルデータベース上でツリー状データを記述するために定期的に使用される方法を知りたいですか？ RDBMSには、通常のSQL ANSIまたは一般的な利用可能な機能以外の特別な機能はないものと想定しています。 疑いの余地なく、私は常にMySQLとPostgreSQL、そして最終的にSQLiteに興味があります。

13 tree  relational-theory  database-design  erd 

2番目の正規形（2NF）に問題があり、Googleを使用して解決することができませんでした。私は教師であり、生徒に間違ったものを教えたくないので、それは私を夢中にさせています。 5つのフィールドを持つテーブルを作成しましょう。 成績= {StudentName、SubjectCode、SubjectName、#Exam、Grade} 依存関係は次のとおりです。 StudentName、SubjectCode、＃Exam-> Grade SubjectCode-> SubjectName SubjectName-> SubjectCode したがって、候補キー1は{StudentName、SubjectCode、#Exam}であり、候補キー2は{StudentName、SubjectName、#Exam}です。 プライム属性は{StudentName、SubjectCode、SubjectName、#Exam}であり、非プライム属性はGradeです 2番目の標準形式の定義によれば、非プライム属性は候補キーの一部に依存できません。唯一の非プライム属性（グレード）は候補キーの一部に依存しないため、この表は2NFにあるように見えます。 問題は、何かがおかしいと思うことです（そして、私は間違っているかもしれません）。被験者は自分のテーブルを持つべきだと思います。 成績= {生徒名、件名コード、＃試験、成績} サブジェクト= {Subject Code、SubjectName} しかし、2NFはこれを生成しません。3NFは非プライム属性間の依存関係に関するものであるため、これも生成しません。しかし、冗長性がないため、これは正しい結果であるように思えます。 非プライム属性が「候補キーではない属性」として定義されている場合、2NFが望ましい結果を生成すると思います。しかし、私はこれを何度もチェックしており、非プライム属性は「候補キーに一致しない属性」として定義されています。 私は何を間違えていますか？

13 database-design  normalization  relational-theory 

私は3つのテーブルを持っています students table ------------------------------------ id(PK, A_I) | student_name | nationality teachers table ------------------------------------ id(PK, A_I) | teacher_name | email classroom table ---------------------- id(PK, A_I) | date | teacher_id(FK to teachers.id) | student_id(FK to students.id) 教師の名前（davidたとえば）とstudent_id（たとえば）が与えられ、テーブルに基づいてテーブル7に挿入するように要求された場合、次のようにします。teacher_idclassroomidteachers insert into classroom (date, teacher_id, student_id) select '2014-07-08', id, 7 from teachers where teacher_name = …

12 mysql  relational-theory 

レコードの統計データの大規模なセットがあると考えてください。例：20〜30 INTカラム。セット全体が1つのレコードに属しているため、セット全体を1つのテーブルに保持するか、1対1の関係で接続された別のテーブルを作成する方が良いでしょうか。 前者の利点はJOIN、対応するレコードのすべての統計データを回避して迅速にアクセスできることです。 後者の利点は、カラムを整頓することです。最初の列は読み取り中心で、2番目の列は書き込み中心です。もちろん、行レベルのブロッキングでInnoDBを使用しているので、パフォーマンスに大きな影響はないと思います。 一般に、1つのレコードに対して異なるデータセットを分離することが実用的かどうか知りたいですか？

12 mysql  database-design  innodb  normalization  relational-theory 

大規模なクエリを高速化し、より良い結果を得るには、リレーショナルデータベースで（FOREIGN KEY制約定義を介して）関係の強制を取り除く方が良いと言うので、私は私が働いている会社の開発者と恒久的に話し合っています。パフォーマンス。 検討中のプラットフォームはMySQL 5.xであり、FOREIGN KEYがセットアップされておらず、関連するテーブルの一部のPRIMARY KEY制約が欠けていても、少なくとも私にとっては妥当ではありません。多分彼らは正しいのですが、私は間違っていますが、私はこの状況について議論するのに十分な議論がありません。 これは3年間、推奨されるアプローチでした。私はこの会社の新人です（わずか1か月）が、製品が「機能する」ため、データベースを拡張するのにためらいがあります。それにもかかわらず、最初に気付いたのは、1ページの読み込みに1分（はい、60秒！）かかっていることです。 現在の状況の背後にある主張の1つは、「非正規化された」データベースは正規化されたデータベースよりも速いということですが、私はそれが本当だとは思いません。 関連するクエリのほとんどにJOIN操作が含まれているため、大量のデータがあると非常に遅くなります（データベースには数百万の行が含まれます）。 通常、「CRUD」操作の処理は、アプリケーションプログラムコードレベルで実装されます。たとえば、FROMからデータを削除するには、次のようにしましょうTableA： との行の間に何らかの関係があるかどうかをその場で最初に確認する必要がTableAありますTableB。 上記の関係が「検出」された場合、アプリプログラムコードは関連する行の削除を許可しませんが、 何らかの理由でアプリのプログラムコードが失敗した場合、関連する行とテーブルに関係があるかどうかに関係なく、DELETE操作は「成功」します。 質問 議論を深めるために、私が良い、正確で確固とした答えを詳しく説明するのを手伝っていただけませんか？ 注：たぶん、このようなものは以前に尋ねられた（そして答えられた）かもしれませんが、Googleを使用して何も見つけることができませんでした。

10 mysql  database-design  normalization  relational-theory  denormalization