A leghosszabb működő SQL query amit életem során írtam ... soros volt.

PostgreSQL

1-5
24% (94 szavazat)
6-10
13% (49 szavazat)
11-15
10% (37 szavazat)
16-25
7% (27 szavazat)
26-50
11% (43 szavazat)
51-100
7% (27 szavazat)
101-200
4% (17 szavazat)
>200
10% (37 szavazat)
Nem írtam még soha semmit semmilyen SQL-ben.
15% (57 szavazat)
Összes szavazat: 388

( carlcolt | 2014. 04. 02., sze – 23:04 )

SQL query, tehát SELECT|UPDATE|DELETE stb. szótól az első pontosvesszőig nézzük, nem egy teljes PL-SQL blokkra vagy egy PROCEDURE hosszára vonatkozik a kérdés (ha INSERT-ben 80 sortörés van egy egyszerű blogbejegyzésben, természetesen az sem ér, legalábbis nem számít attól a query 82 sorosnak, legyen az mondjuk 1-5-be eső ;) ).

Nálam a csúcs 47 sor (és nem, nem lehetett kevesebből megoldani többek szerint sem (ilyen query-t azért review-oltatok másokkal is, még ha meg is bízna bennem anélkül is az, aki megkért), subquery és azokon keresztül más és más alapján groupolás, rakás tábla hol INNER hol FULL OUTER joinolása, egy táblából több példány (pl. users u_in, u_out), CASE-es select oszlop, stb. kellettek bele, azzal "gyorsan megvan" (na jó, azért ezekkel együtt is ritka az ilyen hosszú)).

47 sor az nem sok. Nalunk az ugyviteli rendszerben kb. teljesen atlagosak.

Viszont van olyan querynk, ami ket reszre lett szedve (mindketto 150-200 sor kb.) es ez-az mar PHP-ben lett osszekapcsolva, mert nagyon elburjanzottak volna a casek es ezt-azt tobb helyre is be kellett volna tenni, ami miatt nem 2-3 perc alatt futott volna le a cucc, hanem 20-30. Az meg nekunk mar tul sok lett volna :)

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

( traktor | 2014. 04. 03., cs – 14:49 )

Tippre beirtam a 11-15-ot, de igazabol nem tudom. Meg mondjuk a hossza a tordelesen mulik... en eleg sokat tordelek, viszont messze nem vagyok egy SQL guru. Ja es mi van a PL/SQL, PL/pgSQL-lel...?

( asdPro | 2014. 04. 03., cs – 15:15 )

Na de amikor szinte ugyan azt unionolod 4x, az nem ér ám :)

( marci8 | 2014. 04. 03., cs – 16:14 )

>200:

260 sor körüli volt az enyém egy régebbi munkahelyemen, szerencsére már nem nagyon emlékszem rá, egy kolléga scriptjét kellett kiegészítenem, az lett ekkora.

Ellenben ugyanaz a kolléga vitte a prímet, az övé 600 fölött volt, de abban rengeteg hasonlót kapcsolt össze unionokkal.

( BandiG v | 2014. 04. 04., p – 01:11 )

Most hirtelen egy 45 sorosat talaltam, de hasznal TEMPORARY TABLE-oket is, ugyhogy igazabol osszesen 220 sor. (Itt is tartom az okolszabalyt: ami egy kepernyonel hosszabb, azt -ha lehet- bontom.)

( Gaab | 2014. 04. 03., cs – 16:29 )

Elsore ugy olvastam, hogy "legrosszabb" :)

( fajan | 2014. 04. 03., cs – 16:39 )

Hmm, asszem a leghosszabb query egy sport-kupa-helyezés kiértékelő query volt.
A probléma, hogy mysql (és amennyire tudom gyakorlatilag az összes dbms) minden order-ben levő részt kiértékel, még akkor is ha nincs rá szükség, és kb 15-18 rendezési szempont volt a végleges helyezés megállapításához.
Az elsők triviálisak, és nincs is velük gond (több összesített pontszám, több forduló-résztvétel), de egyre összetettebbek lettek, és a vége már olyasmi szempont volt hogy "a több összesített folyamatos mérközés-idő veszített pont nélkül", ami kb 4-6 join + 2 aggregation subquery csak magában... Persze soha nem is fordult elő, hogy a 2-4 szempont után még további szempontok szükségesek lettek volna. Szóval a nagy trükk az volt, hogy az order-t subquery-vel megoldani, ami egy if(count(),..,..)-tal eldöntötte, hogy egyáltalán szükséges-e tovább értékelni, vagy csak egy konstansot dobjon vissza... (és szerencsére a subquery-k fedték egymást annyira, hogy querycache-ben maradjanak az adatok)

Ok, persze nem a leghatékonyabb módszer mindent egy query-ben megoldani, de ez amolyan proof-of-concept volt: hogy lehet sql query-ben is complex-branching kiértékelést futtatni...
Monjuk, ma már itt járunk: szívesen megnéznék egy perceptron/NN query-t back-propagation-query-párral XD

( insight | 2014. 04. 03., cs – 17:57 )

Valaki mutasson már egy 200 felettit ha publikussá tehető

Semmi extra, csak kell hozzá egy 800 táblából álló adatbázis, ahol összesíteni a fogyásokat, beszerzéseket, és az egyéb kapcsolódó dolgokat, pl. hol milyen terhelés van, ami akár beszállítónként is változhat, stb. stb. stb. És ez mondjuk érint 10-20 táblát.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Teljesen indokolt az az adatbázis. Oké, 1-2 tervezési döntéssel én is tudnék ott vitatkozni, de alapvetően nagyjából értem, hogy miért úgy oldották meg ahogy. Ha meg soknak tűnik a 800? Nos, igen, sok. De maga az ERP rendszer is rengeteg funkcióval bír, szóval nem nagyon tudod megoldani kevesebből.

El kell fogadni, hogy nem csak hétvége alatt összerakható random php oldalak vannak, hanem sok éve fejlesztett komplex rendszerek is. Vagy ugyanúgy a 6 éve kezdett webshop rendszerünk: 

db=# select count(*) from information_schema.tables where table_schema not in ('information_schema', 'pg_catalog', '_webshopcore') and table_type = 'BASE TABLE';
 count
-------
   265
(1 row)

Ennyi, sok funkció => sok adattábla. Még ha a felhasználói oldalról nem is feltétlen látszik egyből.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

( dblaci | 2014. 04. 03., cs – 18:45 )

Szerintem egy 5 sor fölötti már gyakorlatilag tervezési hibásnak tekinthető. Természetesen nem a listából összeállított IN ... meg extended insertekre gondolok, hanem a 10+ join és union + subselectes lekérdezésekre...

Igazából az 5-öt csak úgy írtam, a lényeg, hogy egy végtelen hosszú queryt soha senki nem fog senki se debugolni, se optimalizálni. Ha működik, akkor az kétes dicsőség, inkább szerencse, vagy leginkább pont a mérete miatt nem könnyű olyan esetet mutatni, amikor NEM működik, pedig valójában jó eséllyel van ilyen. Pl. ha nem működőnek nevezzük a soha le nem futó lekérdezést, ami kevés adatnál egyébként hibátlan...

Nem feltetlen kell itt rendszeresen futo querykre gondolni, de egy nagyobb rendszer statisztikai, riportjai igenis lehetnek ekkorak. En is irtam mar 10 soros query-t, mert hat tablat kellett osszekapcsolnom, plusz meg subquery-vel le is kellett gyujtenem, hogy mit keresek egyaltalan. Persze, szet lehet az ilyet szedni ugy, hogy az adatok egy reszet a szoftver ertelmezi es a query-k kozt szallitja az adatokat - de ha egy alapvetoen ritkan (napi/heti egyszer) futo queryrol van szo, akkor felesleges. Az RDBM-esek tobbek kozt erre lettek kitalalva, hogy adatok kozt keressenek, akar bonyolult szempontok alapjan is. Ha csak a tablazatokra lenne szuksegunk, az mehetne CSV fajlokban is.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

( lajos22 | 2014. 04. 03., cs – 20:06 )

Ha jól emlékszem 18-20 körül volt, egy 6 táblás kapcsolás MsSQL-ben.
Hasonló 18-20 körüli volt MySQL-ben is, de ott 8 táblához kellett joinolni a dolgokat..

--
Fontos! Ha berágok, nem feltétlen személyed ellen szól...
openSUSE 13.1 x86_64

( Kronosz v | 2014. 04. 04., p – 09:32 )

Közel 300, nem emlékszem pontosan. Napi leltár, excelt generál a kis program, és kiküldi mailben megadott címekre.

________________________________________________
http://kronosz.krocomp.hu

( Misi | 2014. 04. 04., p – 14:58 )

Nem szavaztam vele, mert nem én írtam, de tudok >1000 soros selectről is. Oracle, xml generálás.

( bAndie9100 | 2014. 04. 05., szo – 19:29 )

1 soros - nem tettem bele newline-t :D
ezt gondolom már kitárgyaltátok a topikban, nem olvastam.
inkább karakterben vagy méginkább nyelvi elemek számában mérve lenne reprezentatív a kérdés.

~~~~~~~~
deb http://deb.metaltux.tk/ wheezy testing

( Mac | 2014. 04. 09., sze – 10:38 )

Az éri, ha kódból generáltam SQL-t, amit lefuttattam? (Interaktív lekérdezés, kb. 350 feltétel alapján.) Egy átlag összekattintgatott lekérdezéshez generált 3-400 soros SQL-t.

( PtY | 2014. 04. 09., sze – 13:46 )

Szerintem a karakterszám a lényeg (szóközök nélkül), nem az, hogy hány soros.

SELECT
  *
FROM
  akarmi

Ez most akkor 4 sor?
--
PtY - www.onlinedemo.hu