SQL: Brauchen wir ANY/SOME und ALL keywords?

Ich benutze SQL (SQL Server, PostgreSQL) über 10 Jahre und immer noch bin ich nie verwendet ANY/SOME und ALL Schlüsselwörter in meinem Produktionscode. Alle Situation, die ich angetroffen habe, konnte ich mit IN, MAX, MIN, EXISTS, und ich denke, es ist lesbarer.SQL: Brauchen wir ANY/SOME und ALL keywords?

Zum Beispiel:

-- = ANY 
select * from Users as U where U.ID = ANY(select P.User_ID from Payments as P); 

-- IN 
select * from Users as U where U.ID IN (select P.User_ID from Payments as P);

Oder

-- < ANY 
select * from Users as U where U.Salary < ANY(select P.Amount from Payments as P); 

-- EXISTS 
select * from Users as U where EXISTS (select * from Payments as P where P.Amount > U.Salary);

Mit ANY/SOME und ALL:

Die Frage ist also: bin ich etwas fehlt? Gibt es eine Situation, in der ANY/SOME und ALL über andere Lösungen glänzen?

Quelle

2013-07-11 Roman Pekar

Ich habe sie auch nicht in den letzten 13 Jahren verwendet. –

Ich habe auch 'EXCEPT' nie benutzt. Ich bleibe bei 'NOT EXISTS' – joop

Ich konnte dem nicht zustimmen, ich denke' EXCEPT' ist nützlich, um Unterschiede zwischen zwei Tabellen mit demselben Schema zu finden –

Ich finde ALLE und sehr nützlich sein, wenn Sie nicht nur Gleichheit oder Ungleichheit testen. Betrachten Sie

'blah' LIKE ANY (ARRAY['%lah', '%fah', '%dah']);

as used my answer to this question.

ANY, ALL und deren Negationen können Code erheblich vereinfachen, der ansonsten nicht-triviale Unterabfragen oder CTEs erfordern würde, und sie sind meiner Ansicht nach zu wenig genutzt.

Bedenken Sie, dass ANY mit jedem Operator funktioniert. Es ist sehr praktisch mit LIKE und ~, aber wird mit tsquery, Array-Mitgliedschaft Tests, Hstore Schlüsseltests und mehr arbeiten.

'a => 1, e => 2'::hstore ? ANY (ARRAY['a', 'b', 'c', 'd'])

oder:

'a => 1, b => 2'::hstore ? ALL (ARRAY['a', 'b'])

Ohne ANY oder ALL Sie würden wahrscheinlich diejenigen als Subquery oder CTE über eine VALUES Liste mit einem Aggregat ausdrücken müssen ein einzelnes Ergebnis zu produzieren. Sicher, du kannst das tun, wenn du willst, aber ich bleibe bei ANY.

Es gibt eine echte Einschränkung hier: Auf älteren Pg-Versionen, wenn Sie ANY(SELECT ...) schreiben, werden Sie fast sicher in Leistungsperspektiven mit EXISTS (SELECT 1 FROM ... WHERE ...) besser dran sein. Wenn Sie eine Version verwenden, in der der Optimierer ANY (...) in eine Verknüpfung umwandelt, müssen Sie sich keine Sorgen machen. Wenn Sie Zweifel haben, überprüfen Sie die EXPLAIN Ausgabe.

Quelle

2013-07-11 09:03:35

+1, aber welche RDBMS verwenden Sie? Ich habe versucht, Ihre Abfrage in PostgreSQL arbeiten und am besten bekomme ich 'wie alle (Werte ('% lah'), ('% fah'), ('% dah'));' [SQL FIDDLE ] (http://sqlfiddle.com/#!12/ac24b/9) –

Es muss 'ANY (ARRAY [...])' sein. Aber ja, das ist im Allgemeinen ziemlich nützlich. –

@PeterEisentraut Whoops, guter Punkt. Ich denke immer, es braucht die gleiche einfache Literal-Syntax wie IN (...) ' –

Nein, ich habe die ANY, ALL oder SOME Schlüsselwörter entweder nie verwendet, und ich habe sie nie in Code anderer Leute verwendet. Ich gehe davon aus, dass dies eine Restsyntax ist, wie die verschiedenen optionalen Schlüsselwörter, die an einigen Stellen in SQL erscheinen (z. B. AS).

Denken Sie daran, dass SQL von einem Ausschuss definiert wurde.

Quelle

2013-07-11 08:22:47

+1 aber was ist falsch mit 'AS'? Ich mag es :) –

Ich hatte alles versucht aber nichts fehlt, nur andere Art von Gewohnheit nur, wenn ich einen Not Zustand verwende. Das Existieren und In wird nicht hinzugefügt werden müssen, während irgendein/nur den Operator zu <> ändern. Ich benutze nur sql Server und ich bin mir nicht sicher über die andere Software möglicherweise etwas fehlt

Quelle

2013-07-11 08:27:11

SQL: Brauchen wir ANY/SOME und ALL keywords?

Antwort

Verwandte Themen