Am văzut următoarea interogare MySQL care utilizează atât DISTINCT, cât și GROUP BY împreună: 

SELECT DISTINCT user_id, post_id, post_content FROM some_table GROUP BY post_id, user_id HAVING post_content LIKE "%abc%";

Iată un scenariu pentru a merge împreună cu interogarea: Fiecare utilizator are un id unic, user_id și poate crea mai multe postări care sunt identificate printr-un id unic, post_id. Fiecare postare ar conține un text.

Am găsit acest lucru confuz (după ce am venit din Oracle DBs) și am avut mai jos întrebări:

  1. Care este semnificația utilizării GROUP BY fără a face nicio agregare?
  2. Care este semnificația schimbării ordinii coloanelor în SELECT vs în GROUP BY ?
  3. Care este semnificația omiterii celei de-a treia coloane din GROUP BY?
  4. De ce este DISTINCT folosit împreună cu GROUP BY? Execută o operație distinctă după ce toate grupările sunt efectuate pe rezultatul final sau înainte?

Comentarii

  • Elementul 2: Nu există semnificaţie. GROUP BY nu contează deloc (cu excepția faptului că în versiunile vechi implică același ORDER BY. SELECT ordinea contează doar în aranjarea coloanelor din ieșire.

Răspuns

ad 1) Bazele de date mysql vechi și când dezactivați ONLY_FULL_GROUP_BY , puteți efectua această interogare și dacă post_content sunt toate egale pe care le-ați observa, că mysql oferă o valoare aleatorie nu deterministică înapoi .

ad 2) none what ever ever

ad 3) programare leneșă și apare o eroare când activați ONLY_FULL_GROUP_BY

anunț 4) Nu, ar afișa toate post_content care sunt conectate la user_id, post_id similar cu addind post_content la grup de

Așa cum a spus deja Strawberry această interogare nu este face orice sens

Răspuns

Abilitatea nebună de a permite gruparea parțială în versiunile mai vechi ale MyS QL, trebuie să fie unul dintre principalii concurenți pentru cea mai cauzată confuzie din industria IT.

Dat fiind tabelul: 

CREATE TABLE t ( x int not null primary key , y int not null ); INSERT INTO t (x,y) VALUES (1,1),(1,2);

Declarația 

SELECT x, y FROM t GROUP BY x

ar putea însemna (1,1) sau (1,2) și MySQL ar returna în mod aleatoriu unul dintre acestea. DISTINCT nu contează în acest caz, rezultatul este încă in-determinist.

SQL92 a cerut ca toate coloanele din clauza select (cu excepția coloanelor agregate și a constantelor) să facă parte din clauza GROUP BY.

SQL99 a slăbit puțin această restricție și ne-a permis să lăsăm în afara coloanelor din GROUP BY care sunt funcțional dependente de coloanele rămase. Adică 

CREATE TABLE t ( x int not null primary key , y int not null ); SELECT x, y FROM t GROUP by x

ar fi valid deoarece y este f.d. of x

Surprinzător (pentru mine) versiunea ulterioară a MySQL este cea mai bună din clasă atunci când vine vorba de implementarea versiunii SQL99. Nu l-am verificat în ultima vreme, dar când am făcut-o, MySQL a gestionat bine scenarii destul de complicate, în care PostgreSQL a gestionat doar cele banale.

Pentru a răspunde la întrebări

1) 

SELECT x, y FROM t GROUP BY x, y

înseamnă că combinația dintre x, y este un grup. În toate situațiile posibile, mă pot gândi la acest lucru la fel ca: 

SELECT DISTINCT x, y FROM t

Deoarece sunt evaluați logic în momente diferite, ar putea exista unele cazuri de colț în care acestea ar diferi de fapt (nu mă pot gândi la unul)

2) Nici unul , în acest sens, acestea sunt un set de coloane, deci nu există nicio ordine

3) A se vedea mai sus.

4) Ordinea logică de evaluare a unei interogări SQL este: 

FROM, JOIN WHERE GROUP BY HAVING SELECT DISTINCT ORDER BY FETCH FIRST

așa că GROUP BY ar trebui să fie evaluat înainte de DISTINCT. Nu mă pot gândi la o situație în care acest lucru ar conta.

În interogarea dvs. Bănuiesc că cineva a obținut rezultate confuze și a încercat să obțină un alt rezultat folosind DISTINCT. Probabil că au avut noroc (sau ghinion) să obțină rezultatul. așteptat, așa că DISTINCTUL a rămas. Bug-ul este încă acolo, deși

Lasă un răspuns

Adresa ta de email nu va fi publicată. Câmpurile obligatorii sunt marcate cu *