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

リレーショナルデータベースは、データのリレーショナルモデルに基づくデジタルデータベースです。このモデルは、列と行の1つ以上のテーブル（または「リレーション」）にデータを編成します

9
リレーショナルデータベースでリストを使用しても大丈夫ですか？
私はプロジェクトのコンセプトに合わせてデータベースを設計しようとしており、熱く議論されている問題のように思われました。私はいくつかの記事を読んで、フィールドにIDなどのリストを保存することは決して（またはほとんど決して）大丈夫ではないことを示すいくつかのStack Overflowの回答を読んでいます-すべてのデータはリレーショナルでなければなりません しかし、私が直面している問題は、タスクアサイナーを作成しようとしていることです。ユーザーはタスクを作成し、複数のユーザーに割り当てて、データベースに保存します。 もちろん、これらのタスクを「Person」に個別に保存する場合、1人に0〜100個のタスクを割り当てることができるため、ダミーの「TaskID」列を数十個用意し、それらをマイクロ管理する必要があります。 繰り返しますが、タスクを「タスク」テーブルに保存する場合、ダミーの「PersonID」列を数十個用意し、それらをマイクロ管理する必要があります。これは以前と同じ問題です。 このような問題の場合、何らかの形でIDのリストを保存しても大丈夫ですか、それとも原則を破らずに達成できる別の方法を考えていないだけですか？
7
データベースのリレーショナルモデルが重要なのはなぜですか？
上司と一緒にデータベースを実装する必要があるプロジェクトに近づいています。私たちは非常に小さな新興企業なので、職場環境は非常に個人的なものです。 彼は以前に私に会社のデータベースの1つを与えてくれましたが、RDBMSの学校で教えられた（そして読んだ）ものに完全に反しました。たとえば、ここには1つのテーブルで構成されるデータベース全体があります（独立したデータベースごとに）。これらのテーブルの1つは20列以上の長さであり、コンテキストのために、1つのテーブルの列名の一部を次に示します。 lngStoreID | vrStoreName | lngCompanyID | vrCompanyName | lngProductID | vrProductName ポイントは、エンティティデータ（名前、サイズ、購入日など）を保持する個々のテーブルが必要な場所であり、データベースごとにすべてを1つの大きなテーブルに押し込みます。 この設計を改善したいのですが、適切に正規化されセグメント化されたデータモデルが実際にこの製品を改善する理由がわかりません。私は大学のデータベース設計に精通しており、その方法を理解していますが、これが実際にデータベースを改善する理由はわかりません。 優れたリレーショナルスキーマがデータベースを改善するのはなぜですか？
11
データベース内のテーブル間のリレーションを定義する必要がありますか、それともコードで定義する必要がありますか？
私の経験では、過去に読んだプロジェクトの多くは、データベースにリレーションシップ定義を持たず、代わりにソースコードでのみ定義していました。だから私は、データベースとソースコード内のテーブル間の関係を定義することの利点/欠点は何なのかと思っていますか？より広範な質問は、カスケード、トリガー、手順などの現代のデータベースの他の高度な機能に関するものです...私の考えにはいくつかのポイントがあります。 データベース内： 設計からの正しいデータ。無効なデータを引き起こす可能性のあるアプリケーションエラーを防ぎます。 アプリケーションがデータの整合性をチェックするためにより多くのクエリを作成する必要があるため、データを挿入/更新する際のアプリケーションへのネットワークラウンドトリップを削減します。 ソースコード内： より柔軟。 複数のデータベースにスケーリングする場合は、リレーションがクロスデータベースになることがあるため、より良いです。 データの整合性をさらに制御します。データベースは、アプリケーションがデータを変更するたびに確認する必要はありません（複雑さはO（n）またはO（n log n）（？）です）。代わりに、アプリケーションに委任されます。また、アプリケーションでデータの整合性を処理すると、データベースを使用するよりも詳細なエラーメッセージが表示されると思います。たとえば、APIサーバーを作成するときに、データベースでリレーションを定義すると、何かが（参照されているエンティティが存在しないなど）うまくいかない場合、メッセージとともにSQL例外を受け取ります。簡単な方法は、「内部サーバーエラー」が発生したことをクライアントに500で返すことであり、クライアントは何が問題なのかわかりません。または、サーバーはメッセージを解析して何が間違っているのかを判断できます。これはmyい、エラーが発生しやすい方法です。アプリケーションにこれを処理させると、 他に何かありますか？ 編集：Kilianが指摘しているように、パフォーマンスとデータの整合性についての私の論点は非常に間違っています。そこで、自分のポイントを修正するために編集しました。データベースで処理できるようにすることは、より効率的で堅牢なアプローチになることを完全に理解しています。更新された質問を確認して、それについて考えてください。 編集：みんなありがとう。私が受け取った答えはすべて、制約/関係をデータベースで定義する必要があることを指摘しています。:)。もう1つ質問がありますが、この質問の範囲外であるため、別の質問として投稿しました：APIサーバーのデータベースエラーを処理します。いくつかの洞察を残してください。
4
辞書WebサイトにMySQLを使用するのはなぜ悪い考えですか？
辞書のエントリ（通常は単一の単語）とその意味を別の言語で保存するデータベースを設計および設定する予定です。したがって、たとえば、テーブル用語集にはエントリと定義が必要であり、各テーブルレコードには、格納されているレコードのIDへの参照がありますTag（各エントリにはタグまたはカテゴリが必要です）。 私のデータは構造を持っているので、SQLデータベース（MySQLなど）を使用することは悪い考えではありません。しかし、人々はMongoDBの方がパフォーマンスがはるかに優れていると言います。 クライアント側では、アプリケーションは、バックエンドが提供するREST APIを使用するオートコンプリートを備えた検索ボックスを提供できる必要があります。このようなシナリオでMySQLを使用するのは安全ですか？または、これに他のソリューションのMongoDBまたはElasticSearchを使用する必要がありますか？このようにして、数十万件のレコードが保存およびアクセスされることになっています。
8
コンテンツで検索する必要がある大規模なデータセットでは、NoSQLデータベースの使用は非実用的ですか？
1週間、NoSQLデータベースについて学んでいます。 NoSQLデータベースの利点と、それらが優れている多くのユースケースを本当に理解しています。 しかし、多くの場合、NoSQLがリレーショナルデータベースを置き換えることができるかのように記事を書きます。そして、頭を動かせない点があります。 NoSQLデータベースは（多くの場合）キーと値のストアです。 もちろん、（JSON、XMLなどでデータをエンコードすることで）すべてをキーと値のストアに保存することは可能ですが、多くの場合、特定の基準に一致するデータを取得する必要があるという問題がありますユースケース。NoSQLデータベースでは、効果的に検索できるキーは1つだけです。リレーショナルデータベースは、データ行の任意の値を効果的に検索するように最適化されています。 そのため、NoSQLデータベースは、コンテンツで検索する必要がある永続的なデータには実際には選択できません。または、私は何かを誤解しましたか？ 例： Webショップのユーザーデータを保存する必要があります。 リレーショナルデータベースでは、すべてのユーザーをusersテーブルの行として、ID、名前、国などとともに保存します。 NoSQLデータベースでは、各ユーザーを自分のIDをキーとして、すべてのデータ（JSONなどでエンコードされた）を値として保存します。 したがって、特定の国からすべてのユーザーを取得する必要がある場合（何らかの理由でマーケティング担当者が彼らについて何かを知る必要があります）、リレーショナルデータベースでは簡単に行えますが、NoSQLデータベースではあまり効果的ではありません。すべてのユーザーを取得し、すべてのデータを解析してフィルターします。 私はそれが不可能だとは言いませんが、それははるかにトリッキーになり、NoSQLエントリのデータを検索したい場合はそれほど効果的ではないと思います。 この国に住んでいるすべてのユーザーのキーを格納する国ごとにキーを作成し、この国のキーに保管されているすべてのキーを取得することで特定の国のユーザーを取得できます。しかし、この手法により、複雑なデータセットはさらに複雑になります。SQLデータベースへのクエリほど実装が難しく、効果的ではありません。ですから、本番環境で使用する方法ではないと思います。またはそれは？ そのようなユースケースを処理するために、何かを誤解したり、いくつかの概念やベストプラクティスを見落としたりしたかどうかは、本当にわかりません。たぶん、あなたは私の声明を修正し、私の質問に答えることができます。
7
データベースの制約はどうなりましたか？
RDBMSのデータベースモデルを確認すると、通常、PK / FK以外の制約がほとんどまたはまったくないことに驚かされます。たとえば、パーセンテージは多くの場合型の列に格納されますがint（tinyintより適切です）CHECK、値を0..100の範囲に制限する制約はありません。同様にSE.SEでも、チェック制約を示唆する回答は、データベースが制約の間違った場所であることを示唆するコメントをしばしば受け取ります。 制約を実装しないという決定について尋ねると、チームメンバーは次のように応答します。 そのような機能がお気に入りのデータベースに存在することすら知らないということです。ORMのみを使用するプログラマからは理解できますが、特定のRDBMSで5年以上の経験があると主張するDBAからはほとんど理解できません。 または、アプリケーションレベルでそのような制約を強制し、データベースでそれらのルールを複製することは、SSOTに違反して、良いアイデアではありません。 最近では、外部キーさえ使用されないプロジェクトが増えています。同様に、ユーザーが参照整合性をあまり気にせず、アプリケーションにそれを処理させることを示す、SE.SEに関するいくつかのコメントを見ました。 FKを使用しない選択についてチームに尋ねると、次のように伝えます。 たとえば、他のテーブルで参照されている要素を削除する必要がある場合は、PITAです。 NoSQLは揺れ動き、外部キーはありません。したがって、RDBMSではそれらは必要ありません。 パフォーマンスの点では大したことではありません（コンテキストは通常​​、小さなデータセットで動作する小さなイントラネットWebアプリケーションですので、実際にはインデックスでも大したことはありません。特定のクエリのパフォーマンスが1.5 。〜20ミリ秒） アプリケーション自体を見ると、次の2つのパターンに体系的に気付きます。 アプリケーションは、データベースに送信する前にデータを適切にサニタイズしてチェックします。たとえば102、アプリケーションを介して値をパーセンテージとして保存する方法はありません。 アプリケーションは、データベースからのすべてのデータが完全に有効であると想定しています。つまり102、パーセンテージで表示された場合、どこかでクラッシュするか、単にユーザーにそのまま表示され、奇妙な状況になります。 クエリの99％以上が1つのアプリケーションによって実行されますが、時間が経つにつれて、スクリプトが表示され始めます。必要に応じてスクリプトを手動で実行するか、cronジョブを実行します。一部のデータ操作も、データベース自体で手動で実行されます。スクリプトと手動SQLクエリの両方に、無効な値が導入されるリスクが高くなります。 そしてここに私の質問が来ます： チェック制約なしで、最終的には外部キーなしでもリレーショナルデータベースをモデル化する理由は何ですか？ 価値のあることについては、この質問と私が受け取った回答（特にThomas Kilianとの興味深い議論）により、データベースの制約についての結論を書いた記事を書くことになりました。
9
リレーショナルデータベースは、各列に定義済みのデータ型を設定することで何が得られますか？
私は今、SQLデータベースを使用していますが、これは常に興味をそそりますが、Google検索はあまり現れません。なぜ厳密なデータ型なのでしょうか？ たとえば、バイナリデータとプレーンテキストデータの区別が重要であるなど、いくつかの異なるデータ型がある理由を理解しています。バイナリデータの1と0をプレーンテキストとして保存するのではなく、バイナリデータを独自の形式で保存する方が効率的であることを理解しています。 しかし、私が理解していないのは、非常に多くの異なるデータ型を持つことの利点です： なぜmediumtext、longtextとtext？ なぜdecimal、floatとint？ 等 「この列のエントリにはプレーンテキストデータが256バイトしかありません」とデータベースに伝えることの利点は何ですか。または「この列には最大16,777,215バイトのテキストエントリを含めることができますか？」 パフォーマンス上のメリットはありますか？もしそうなら、手作業の前にエントリーのサイズを知ることがパフォーマンスに役立つのはなぜですか？それとも、まったく別のものですか？
1
文書データベースとリレーショナルデータベースとグラフデータベースのどちらを使用すべきですか？[閉まっている]
議論のために、FourSquareのシナリオを考えてみましょう。 シナリオ エンティティ： ユーザー 場所 関係： チェックイン：ユーザー<->場所、多対多 友人：ユーザー<->ユーザー、多対多 データベース設計 これらにはエラーが発生する可能性が高いため、指摘してください。 RDBMS テーブル： ユーザー 場所 チェックイン（ジャンクション） 友達（ジャンクション） 長所： CAP：一貫性、可用性 短所： CAP：パーティション許容値、別名シャーディング スキーム=柔軟性のない構造 貧弱な複製？ グラフ オブジェクト： ユーザー 場所 エッジ： 友達：ユーザー<->ユーザー チェックイン：ユーザー->場所 タイムスタンプを含む 長所： CAP：一貫性、可用性？ スキーマレスで簡単に変更可能なオブジェクトとエッジ グラフトラバーサルクエリ、たとえば： クラスタリング 友達のグループを見つける 似たような人が好きなレストランを見つける 他の一般的な/有用なクエリはありますか？ 短所： CAP：パーティションの許容範囲？ ドキュメント/オブジェクト 3つの個別のデータベース？ ユーザー 友達リスト チェックイン タイムスタンプ ユーザー 場所 場所 長所： …
4
多くのデザインがRDBMSの正規化を無視するのはなぜですか？
この投稿を改善したいですか？引用や回答が正しい理由の説明など、この質問に対する詳細な回答を提供します。十分な詳細のない回答は、編集または削除できます。 意思決定段階では、正規化が最初の考慮事項ではないという多くの設計を見ました。 多くの場合、これらの設計には30を超える列が含まれており、主なアプローチは「すべてを同じ場所に置く」ことでした 私が覚えていることによると、正規化は最初の最も重要なことの1つです。 編集： 優秀なアーキテクトや専門家が非正規化されたデザインを選択し、未経験の開発者が反対を選択するというのは本当ですか？正規化を念頭に置いて設計を開始することに対する議論は何ですか？
3
順序付けされた情報をリレーショナルデータベースに保存する方法
注文した情報をリレーショナルデータベースに適切に保存する方法を理解しようとしています。 例： 曲で構成されるプレイリストがあるとします。リレーショナルデータベース内には、Playlistsいくつかのメタデータ（名前、作成者など）を含むの。また、私はと呼ばれるテーブルを持っSongs含む、playlist_id曲固有の情報（名前、アーティスト、期間など）だけでなく、。 デフォルトでは、新しい曲がプレイリストに追加されると、最後に追加されます。Song-ID（昇順）で注文する場合、注文は追加の順序になります。しかし、ユーザーがプレイリストの曲を並べ替えることができるとしたらどうでしょうか？ いくつかのアイデアを思いつきました。それぞれに長所と短所があります。 と呼ばれる列orderは、。整数です。曲を移動すると、その変更を反映するために、古い位置と新しい位置の間のすべての曲の順序が変更されます。これの欠点は、曲を移動するたびに多くのクエリを実行する必要があり、移動アルゴリズムが他のオプションほど簡単ではないことです。 orderという10進数の列（NUMERIC）。曲を移動すると、隣接する2つの数字の間に浮動小数点値が割り当てられます。欠点：10進数フィールドはより多くのスペースを必要とし、数回変更するたびに範囲を再分散するように注意しない限り、精度が不足する可能性があります。 別の方法はprevious、next他の曲を参照するフィールドとフィールドを持つことです。（または、現在、プレイリストの最初の曲、最後の曲の場合はNULLです。基本的には、リンクリストを作成します）。欠点：「リストでX番目の曲を見つける」などのクエリは、一定時間ではなく、線形時間になります。 これらの手順のうち、実際に最もよく使用されるのはどれですか？これらの手順のうち、中規模から大規模のデータベースで最も速いのはどれですか？これを実現する他の方法はありますか？ 編集：簡単にするため、この例では、ソングは1つのプレイリストにのみ属します（多対1の関係）。もちろん、ジャンクションテーブルを使用して、song⟷playlistを多対多の関係にすることもできます（そして、そのテーブルに上記の戦略の1つを適用します）。
3
リレーショナルデータベースと反復開発
アジャイル手法、ドメイン駆動設計、オブジェクト指向分析および設計など、ソフトウェア開発への多くのアプローチでは、開発への1つの反復アプローチを採用することをお勧めします。 そのため、プロジェクトでの作業を初めて開始したときにドメインモデルを正しく実行することは想定されていません。代わりに、時間が経つにつれてモデルをリファクタリングします。なぜなら、時間とともに問題の領域をより深く理解できるからです。 それとは別に、完璧なモデルを事前に取得しようとしても、私はすでに非常に難しいと確信していますが、要件は変わる可能性があります。ソフトウェアがそのようにした後にしている生産に配備され、エンドユーザーは、一定の要件を完全に理解していなかったことに気づくかもしれない、あるいは悪化し、いくつかの要件が欠落していました。 ここでのポイントは、ソフトウェアの展開後にモデルの変更が必要になる場合があるということです。これが発生した場合、問題が発生します。本番データベースには重要なユーザーデータがあり、古いモデルの形式に既に適合しています。 コードが適切に設計されておらず、システムが大きい場合、コードの更新は困難な作業になる可能性があります。しかし、それは時間とともに実行できます。Gitのようなツールを使用すると、本番対応バージョンを損傷することなくそれを実行できます。 一方、モデルが変更された場合、クラスのプロパティが消失した場合など、データベースも変更される必要があります。しかし、問題があります。そこには、失われないデータが既にあり、古いモデル用にフォーマットされています。 ここのリレーショナルデータベースは、エンドユーザーの要求に応じて反復的な開発を行ったり、ソフトウェアを更新したりすることを妨げる障壁になっているようです。 私がすでに使用したアプローチの1つは、古いデータベーステーブルを新しいテーブルにマップする特別なクラスをコーディングすることでした。したがって、これらのクラスは古い形式のデータを選択し、新しいモデルで使用される形式に変換して、新しいテーブルに保存します。 このアプローチは最良の方法ではないようです。ここでの私の質問は次のとおりです。リレーショナルデータベースで反復開発を調整するためのよく知られた推奨アプローチはありますか。
5
LEFT JOINよりRIGHT JOINを好む理由
私が正しく理解していれば、すべて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か？
3
ドキュメントデータベースとリレーショナルデータベース：選択方法
私はSQLの男ですが、SQL データベースだけでなく、ドキュメントデータベースもほとんどあることを知っています。ほとんどのテクノロジーと同様に、各テクノロジーには長所と短所があります。 私はいくつかの記事を読みましたが、それらは理論的すぎました。私が望むのは、2つの実際のケースです： リレーショナルデータベースからドキュメントデータベースへの切り替えにより改善されたとき ドキュメントデータベースからリレーショナルデータベースへの切り替えにより改善されたとき 改善とは、より良いプログラムを作成するものであり、開発時間、スケーラビリティ、パフォーマンス、プログラミング関連のあらゆるものを減らします。2には注意点があります。「誰もがSQLを知っているのでリレーショナルデータベースにフォールバックする」などの話は良くありません。
4
自分のデータが本質的にリレーショナルまたはオブジェクト指向であることを知るにはどうすればよいですか？
これらの行を読むだけで データが本来オブジェクトである場合は、オブジェクトストア（「NoSQL」）を使用します。リレーショナルデータベースよりもはるかに高速です。 データがリレーショナルデータである場合、リレーショナルデータベースのオーバーヘッドはそれだけの価値があります。 から- http://seldo.com/weblog/2011/06/15/orm_is_an_antipattern それで、データが本質的にリレーショナルであるかオブジェクト指向であるかをどのようにして知ることができますか？
7
交差テーブルを作成する代わりにNULL入力可能な外部キーを使用することの欠点
次のERダイアグラムがあるとします。 ここSchoolでStudent、inの外部キーを使用して関係を表す場合、NULL値を持つことができます（a Student に属する必要はないためSchool）。たとえば、 したがって、正しい方法（読んだ内容に基づいて）は、リレーションシップを表す交差テーブルを作成することです。次に例を示します。 この方法でNULLは、表に値を含めることはできませんSchool_has_Student。 しかし、交差テーブルを作成する代わりにNULL入力可能外部キーを使用することの欠点は何ですか？ 編集： 誤って（school_id、student_id）をSchool_has_Studentテーブルのプライマリキーとして選択したため、多対多の関係になりました。正しい主キーは次のstudent_idとおりでした。
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.