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

単純な投票システムでは CREATE TABLE elections ( election_id int(11) NOT NULL AUTO_INCREMENT, title varchar(255), CREATE TABLE votes ( election_id int(11), user_id int(11), FOREIGN KEYs ユーザーが投票した選挙のリストを取得するには、次のJOINが使用されます SELECT * FROM elections JOIN votes USING(election_id) WHERE votes.user_id='x' しかし、ユーザーが投票していない選挙のリストを取得する方法は？

21 join  select 

列の命名に関しては、ベストプラクティスに関する専門家の意見をいくつかお願いします。 背景は、ウィキペディアによると、次の構文、 SELECT ... FROM Employees JOIN Timesheets USING (EmployeeID); より効率的です SELECT ... FROM Employees JOIN Timesheets ON (Employees.EmployeeID = Timesheets.EmployeeID); ただし、JOIN ... USING構文はグローバルに一意の名前を持つすべての主キー列でのみ機能します。したがって、これは正しいことと考えられているのだろうか。 個人的に、私はいつもPK column id、および外部キーcolumnを持つテーブルを作成するために使用していましたothertable_id。しかし、その方法ではUSINGまたはを使用することはできませんNATURAL JOIN。 デザインスタイルへのリンクまたはテーブルデザインのベストプラクティスガイドも歓迎します。

19 database-design  join  naming-convention 

SQL Server 2008 R2で毎晩レポートを作成する必要があります。レポートの計算には数時間かかります。時間を短縮するために、テーブルを事前計算します。このテーブルは、12の非常に大きな（数百万行）テーブルを結合して作成されます。 この集計テーブルの計算には、数日前までに約4時間かかりました。DBAは、この大きな結合を3つの小さな結合（それぞれ4つのテーブルに結合）に分割しました。一時的な結果は毎回一時テーブルに保存され、次の結合で使用されます。 DBA拡張の結果、集計テーブルは15分で計算されます。私はそれがどのように可能か疑問に思いました。DBAは、サーバーが処理しなければならないデータの数が少ないためだと言いました。言い換えれば、大きな元の結合では、サーバーは合計された小さな結合よりも多くのデータを処理する必要があります。ただし、元の大きな結合でオプティマイザが効率的に処理し、結合をそれ自体で分割し、次の結合に必要な数の列のみを送信すると仮定します。 彼が行ったもう1つのことは、一時テーブルの1つにインデックスを作成したことです。ただし、オプティマイザーは必要に応じて適切なハッシュテーブルを作成し、計算を全体的に最適化すると思います。 私はこれについてDBAと話しましたが、彼は処理時間の改善がどのように行われたのかについては不確かでした。彼は、そのようなビッグデータを計算するのは圧倒される可能性があり、最適化プログラムが最適な実行計画を予測するのに苦労する可能性があるため、サーバーを非難しないと述べました。これは理解していますが、正確な理由についてより明確な答えが欲しいです。 したがって、質問は次のとおりです。 大きな改善をもたらす可能性があるものは何ですか？ 大きな結合を小さな結合に分割する標準的な手順ですか？ 複数の小さな結合の場合、サーバーが処理する必要があるデータの量は本当に少ないですか？ 元のクエリは次のとおりです。 Insert Into FinalResult_Base SELECT TC.TestCampaignContainerId, TC.CategoryId As TestCampaignCategoryId, TC.Grade, TC.TestCampaignId, T.TestSetId ,TL.TestId ,TSK.CategoryId ,TT.[TestletId] ,TL.SectionNo ,TL.Difficulty ,TestletName = Char(65+TL.SectionNo) + CONVERT(varchar(4),6 - TL.Difficulty) ,TQ.[QuestionId] ,TS.StudentId ,TS.ClassId ,RA.SubjectId ,TQ.[QuestionPoints] ,GoodAnswer = Case When TQ.[QuestionPoints] Is null Then 0 …

18 sql-server  optimization  join 

Slow SQLクエリを読んだ後、最適化の方法がわからないので、クエリの一般的なパフォーマンスについて考えるようになりました。クエリをわずかに高速化するために、結合する前に（他のテーブルを結合する場合）最初のテーブルの結果をできるだけ小さくする必要があります（この質問の内部結合）。 例、これが必要です： SELECT * FROM ( SELECT * FROM table1 WHERE col = @val ) t INNER JOIN table2 ON col = col2 以下より良く/速くなる SELECT * FROM table1 INNER JOIN table2 ON col = col2 WHERE table1.col = @val 私の理論は次のとおりです（これは正しい実装ではないかもしれません。私が読んだSQL Server 2008の内部の本（MSFT Press）から思い出そうとしています）。 クエリプロセッサは最初に左側のテーブル（table1）を取得します 2番目のテーブル（table2）を結合し、必要な行をフィルタリングする前にデカルト積を形成します（該当する場合） 次に、SEELCTステートメントを使用してWHERE、ORDER BY、GROUP BY、HAVING句を最後に実行します。 したがって、上記のステートメント＃1でテーブルが小さい場合、SQLエンジンはデカルト積を形成するときに行う作業が少なくなります。その後、whereステートメントに到達すると、メモリ内でフィルタリングする結果セットが減少します。 …

18 sql-server  performance  join 

1つのテーブルに250MMの行があり、ほとんどのクエリで結合する別のテーブルに15MM未満の行があるWebサイトを実行します。 サンプル構造： MasterTable (Id, UserId, Created, Updated...) -- 15MM Rows DetailsTable (Id, MasterId, SomeColumn...) -- 250MM Rows UserTable (Id, Role, Created, UserName...) -- 12K Rows これらすべてのテーブルに対していくつかのクエリを定期的に行う必要があります。1つは、無料ユーザー（最大1万人の無料ユーザー）の統計を取得することです。 Select Count(1) from DetailsTable dt join MasterTable mt on mt.Id = dt.MasterId join UserTable ut on ut.Id = mt.UserId where ut.Role is null and …

17 join  best-practices 

現在のPostgres 9.4でのこのセットアップを考えると（この関連する質問から）： CREATE TABLE foo (ts, foo) AS VALUES (1, 'A') -- int, text , (7, 'B'); CREATE TABLE bar (ts, bar) AS VALUES (3, 'C') , (5, 'D') , (9, 'E'); 前の質問からのSQL Fiddleもあります。 私が書いたSELECTとをFULL JOIN参照し、質問の目的を達成するために。簡略化： SELECT ts, f.foo, b.bar FROM foo f FULL JOIN bar b USING (ts); 仕様に従って、列をアドレス指定する正しい方法tsは、テーブル修飾なしです。入力値（f.tsまたはb.ts）のいずれかをNULLにすることができます。このUSING句は、奇妙なケースを少し作成します。実際には入力に存在しない「入力」列を導入します。これまでのところとてもエレガント。 …

16 postgresql  join  plpgsql  parameter  naming-convention 

サブクエリを使用するこのクエリを実行するときに、SQL Serverが並列処理を使用するのはなぜですか？結合バージョンはシリアルで実行され、完了するまでに約30倍時間がかかります。 参加バージョン：〜30秒 副照会バージョン：<1秒 編集： クエリプランのXmlバージョン： JOINバージョン サブクエリバージョン

16 sql-server  join  subquery 

次の表とインデックスの定義があります。 CREATE TABLE munkalap ( munkalap_id serial PRIMARY KEY, ... ); CREATE TABLE munkalap_lepes ( munkalap_lepes_id serial PRIMARY KEY, munkalap_id integer REFERENCES munkalap (munkalap_id), ... ); CREATE INDEX idx_munkalap_lepes_munkalap_id ON munkalap_lepes (munkalap_id); munkalap_idのインデックスが次のクエリで使用されないのはなぜですか？ EXPLAIN ANALYZE SELECT ml.* FROM munkalap m JOIN munkalap_lepes ml USING (munkalap_id); QUERY PLAN Hash Join (cost=119.17..2050.88 …

16 postgresql  performance  index  join  primary-key 

Oracleの外部結合構文からSQL標準の外部結合構文に移植されることになっているクエリで、次のことがわかりました。 SELECT ... FROM A, B, C, D, E WHERE A.A_ID = B.A_ID AND B.B_ID = C.A_ID(+) AND B.B_KEY = C.B_KEY(+) AND C.C_ID = D.C_ID(+) AND B.A_ID = E.A_ID(+) AND B.B_KEY = E.B_KEY(+) AND 'CONSTANT' = C.X_ID(+) 現在、外部結合構文の翻訳は通常非常に機械的なプロセスですが、その最後の行は私を困惑させました。どういう意味ですか？どのような効果がありますか？

16 oracle  join  syntax 

私はこのSQLを持っています： CREATE TABLE test(id SERIAL PRIMARY KEY, data JSONB); INSERT INTO test(data) VALUES ('{"parent":null,"children":[2,3]}'), ('{"parent":1, "children":[4,5]}'), ('{"parent":1, "children":[]}'), ('{"parent":2, "children":[]}'), ('{"parent":2, "children":[]}'); それは与えるだろう： id | data ----+-------------------------------------- 1 | {"parent": null, "children": [2, 3]} 2 | {"parent": 1, "children": [4, 5]} 3 | {"parent": 1, "children": []} 4 | {"parent": …

16 postgresql  join  json  postgresql-9.4 

私はcommentsこれを単純化できるテーブルを持っています： comments ======= id user_id text parent_id where parent_idはnull入力可能ですが、親コメントのキーになる場合があります。 さて、select特定のコメントのすべての子孫はどうすればいいですか？ コメントはいくつかのレベル下にあるかもしれません...

15 mysql  join  select  foreign-key 

PostgreSQL 9.3データベースに2つのテーブルがあります。テーブルにlink_replyは、which_groupテーブルを指すという名前の外部キーがありますlink_group。 link_group関連する行がlink_reply存在しない場所からすべての行を削除したい。基本的には十分に聞こえますが、私はそれに苦労しています。 これはこのように単純なものになりますか（機能しません）？ DELETE FROM link_group WHERE link_reply = NULL;

15 postgresql  join  postgresql-9.3  delete 

このようなクエリを作成すると... select * from table1 t1 join table2 t2 on t1.id = t2.id SQLオプティマイザーは、それが正しい用語であるかどうかはわかりませんが、それを... select * from table1 t1, table2 t2 where t1.id = t2.id 基本的に、SQL ServerのJoinステートメントはsqlを書くための簡単な方法ですか？それとも、実際に実行時に使用されますか？ 編集：私はほとんど常に、そしてほとんど常にJoin構文を使用します。私は何が起こるのか興味があります。

14 sql-server  t-sql  join  optimization 

質問への回答を保存するために使用するテーブルがあります。特定の質問に対する特定の回答を持っているユーザーを見つけることができる必要があります。したがって、テーブルが次のデータで構成されている場合： 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 

デフォルトを使用したPostgreSQL、および default_statistics_target=1000 random_page_cost=1.5 バージョン PostgreSQL 10.4 on x86_64-pc-linux-musl, compiled by gcc (Alpine 6.4.0) 6.4.0, 64-bit 掃除機をかけて分析しました。クエリは非常に簡単です。 SELECT r.price FROM account_payer ap JOIN account_contract ac ON ap.id = ac.account_payer_id JOIN account_schedule "as" ON ac.id = "as".account_contract_id JOIN schedule s ON "as".id = s.account_schedule_id JOIN rate r ON s.id = r.schedule_id WHERE …

13 postgresql  join  execution-plan  postgresql-10