タグ付けされた質問 「query」

ブログを構築していて、投稿やコメントが必要だとします。そこで、自動インクリメント整数「id」列を持つ「posts」テーブルと、外部キー「post_id」を持つ「comments」テーブルの2つのテーブルを作成します。 次に、おそらく最も一般的なクエリを実行します。クエリとは、投稿とそのコメントをすべて取得することです。リレーショナルデータベースはかなり新しいので、私にとって最も明白なアプローチは、次のようなクエリを作成することです。 SELECT id, content, (SELECT * FROM comments WHERE post_id = 7) AS comments FROM posts WHERE id = 7 これにより、必要な投稿のIDとコンテンツ、および配列（JSONで使用するようなネストされた表現）にきちんとパッケージ化されたすべての関連するコメント行が得られます。もちろん、SQLおよびリレーショナルデータベースはこのようには機能せず、最も近い方法は、「投稿」と「コメント」の間の結合を行うことです。これにより、多くの不必要なデータの重複が返されます（同じ投稿情報が繰り返されます）すべての行で）、つまり、データベースをまとめて処理するためと、ORMですべてを解析して元に戻すための両方の処理時間が費やされます。 ORMに投稿のコメントを熱心に読み込むように指示した場合でも、最善の方法は、投稿に対する1つのクエリをディスパッチし、次にすべてのコメントを取得する2番目のクエリをディスパッチしてからクライアント側にまとめることです。また非効率的です。 リレーショナルデータベースは実証済みのテクノロジーである（地獄、私よりも古い）こと、そして何十年にもわたって膨大な量の研究が行われていることを理解しています。そして、それらには本当に正当な理由があると確信しています（そしてSQL標準）は、そのように機能するように設計されていますが、上記で説明したアプローチが不可能な理由はわかりません。私は、レコード間の最も基本的な関係の1つを実装する最も単純で明白な方法であるように思えます。リレーショナルデータベースがこのようなものを提供しないのはなぜですか？ （免責事項：私は主にRailsとNoSQLデータストアを使用してwebappを書いていますが、最近Postgresを試しました。実際にそれが大好きです。リレーショナルデータベースを攻撃するつもりはありません。ただ困惑しています。） Railsアプリを最適化する方法や、特定のデータベースでこの問題を回避する方法を尋ねるのではありません。私は直感に反し、無駄に思えるのに、なぜSQL標準がこのように機能するのかを尋ねています。SQLの元の設計者が結果をこのようにしたかったという歴史的な理由がいくつかあるに違いありません。

46 database  sql  rdbms  query 

私は、多くの（少なくとも3-4）テーブルにわたる結合といくつかのネストされた条件を含む複雑なSQLクエリを書くことは非常に難しいと思っています。書くように求められているクエリは、いくつかの文で簡単に説明できますが、完了するためには、途方もない量のコードが必要になる場合があります。私はこれらのクエリを書くために一時的なビューを頻繁に使用していることに気付いています。これらの複雑なクエリを簡単にするために使用できるヒントを教えてください。より具体的には、これらのクエリを、実際にSQLコードを記述するために使用する必要があるステップに分割するにはどうすればよいですか？ 私が書くように頼まれているSQLはデータベースコースの宿題の一部であることに注意してください。したがって、私のために仕事をするソフトウェアは欲しくありません。私が書いているコードを実際に理解したい。 技術的な詳細： データベースは、ローカルマシンで実行されているPostgreSQLサーバーでホストされます。 データベースは非常に小さく、7つ以下のテーブルがあり、最大のテーブルは約50行未満です。 SQLクエリは、LibreOffice Baseを介して、変更されずにサーバーに渡されます。

42 sql  tips  query 

クエリの作成とデータベース設計の専門家でもある非常に多くのプログラマーがいます。 これは、専門のプログラマーまたはソフトウェアエンジニアになるための必須要件でしょうか？ 類似の多くは、クエリとコードが開発されている方法でありますが、私の個人的な意見は、あるクエリが異なる持っているように見える構造よりもコードを、異なるアプローチによる同時に両方をマスターするのは難しいことができます。

35 database  query 

ElasticSearchとグラフデータベースの比較について、Webで詳細な説明を見つけることはできません。 どちらもデータを横断するように最適化されています。 ElasticSearchは分析用に最適化されているようです。 ただし、Neo4jは、インデックスと一部のフルテキスト機能を管理するLuceneにも基づいています。 すでにグラフデータベースを使用しているのにElasticSearchを使用するのはなぜですか？ 私の場合、Neo4jを使用してソーシャルネットワークを構築しています。 ElasticSearchがもたらす本当のメリットは何ですか？ 更新---------- 私はこの段落を見つけました： elasticsearchが役立つ無数のケースがあります。いくつかのユースケースは、他のユースケースよりも明確にそれを要求します。次に、elasticsearchが特に適しているタスクをいくつか示します。 特定のフレーズ（「シェフのナイフ」など）に最も一致する製品説明を多数検索して、最良の結果を返す 前の例では、「シェフのナイフ」が表示されるさまざまな部門を分類します（この本の後半のファセットを参照） 「季節」のように聞こえる単語をテキストで検索する スペルミスを考慮しながら、以前に発行された検索に基づいて部分的に入力された単語に基づいて検索ボックスを自動補完する 大量の半構造化（JSON）データを分散方式で保管し、マシンのクラスター全体に指定されたレベルの冗長性を持たせる ただし、elasticsearchは前述の問題を解決するのに優れていますが、他の人には最適な選択ではないことに注意してください。リレーショナルデータベースが最適化されている問題の解決は特に苦手です。以下にリストされているような問題。 在庫に残っているアイテムの数を計算する 特定の月に送信されたすべての請求書のすべての明細の合計を計算する ロールバックサポートを使用してトランザクションで2つの操作を実行する 電話番号や内線番号など、指定された複数の用語にわたって一意であることが保証されているレコードを作成する Elasticsearchは一般に、品質による結果のスコアリングなど、データからおおよその回答を提供するのに優れています。elasticsearchは正確なマッチングと統計計算を実行できますが、検索の主なタスクは本質的におおよそのタスクです。 おおよその回答を見つけることは、elasticsearchと従来のデータベースを分離するプロパティです。そうは言っても、従来のリレーショナルデータベースは精度とデータの整合性に優れているため、elasticsearchとLuceneにはほとんど規定がありません。 おおよその回答が必要ない場合、ElasticSearchは既に使用されているグラフデータベースと比較して役に立たないと断言できますか？

15 database  query  graph-databases  elasticsearch