Wie man hochpräzise SQL-Abfragen mit AI Bot generiert: eine Fallstudie [SHOW]

Werbung:
Hallo Lasse,

zu OpenAI kann ich dir leider gar nichts sagen. Darum habe ich mir mal dein Datenbank angeschaut
und dort sind mir einige Kleinigkeiten aufgefallen.


  • In der Tabelle 'orders' fehlt ein Index auf die Spalte orderDate. Ohne diesen macht MySQL immer einen
    FULL TABLE SCAN, also alle Rows der Tabelle müssen gelesen werden

  • In deinem Query "find customers with at least 2 orders via orders.customerNumber in 2005 using orders.orderDate" benutzt du eine WHERE year (orderDate) = 2005 um das Jahr 2005 zu selektieren. Das ergibt
    auf einen FULL TABLE SCAN. Es ist kein besonders guter Ansatz eine Funktion hier YEAR() auf ein Feld einer Tabelle
    im WHERE einzusetzen. Dadurch muss MySQL jede Zeile lesen, das Feld durch die Funktion jagen und kann dann erst
    das Ergebnis mit 2005 vergleichen. Also Muss die ganze Tabelle gelesen werden.
    Besser ist:
    WHERE `orderDate` BETWEEN '2005-01-01' AND '2005-12-31'
    zu nehmen. dann kann er auch den Index verwenden.

  • Weiterhin ist mir aufgefallen das das Feld `quantityOrdered` in der Tabelle orderdetails als INT festgelegt ist und es dazu keine Einheit gibt Ich bin mir nicht sicher ob das in deinem Beispiel passt. Stell die mal einen Baumarkt vor, Daort kann man z.B. auch eine Kette der Seil als Meterware kaufen (1,5m) oder Teppich, dann hast du (4,75qm).

    Gruß

    Bernd
 
BerndB schrieb:
In deinem Query "find customers with at least 2 orders via orders.customerNumber in 2005 using orders.orderDate" benutzt du eine WHERE year (orderDate) = 2005 um das Jahr 2005 zu selektieren. Das ergibt
auf einen FULL TABLE SCAN. Es ist kein besonders guter Ansatz eine Funktion hier YEAR() auf ein Feld einer Tabelle
im WHERE einzusetzen. Dadurch muss MySQL jede Zeile lesen, das Feld durch die Funktion jagen und kann dann erst
das Ergebnis mit 2005 vergleichen. Also Muss die ganze Tabelle gelesen werden.
Zum Vergrößern anklicken....

Du siehst das zu negativ. Der AI-Bot ist schon für PostgreSQL optimiert...

Code: 
postgres=# create table lasse (d date);
CREATE TABLE
postgres=# create index idx_date on lasse (date_part('year',d));
CREATE INDEX
postgres=# set enable_seqscan to off;
SET
postgres=# explain select * from lasse where date_part('year',  d) = 2015;
                                                 QUERY PLAN                                                 
------------------------------------------------------------------------------------------------------------
 Bitmap Heap Scan on lasse  (cost=4.26..15.02 rows=13 width=4)
   Recheck Cond: (date_part('year'::text, (d)::timestamp without time zone) = '2015'::double precision)
   ->  Bitmap Index Scan on idx_date  (cost=0.00..4.25 rows=13 width=0)
         Index Cond: (date_part('year'::text, (d)::timestamp without time zone) = '2015'::double precision)
(4 rows)

postgres=#
 
akretschmer schrieb:
Du siehst das zu negativ. Der AI-Bot ist schon für PostgreSQL optimiert...

Code: 
postgres=# create table lasse (d date);
CREATE TABLE
postgres=# create index idx_date on lasse (date_part('year',d));
CREATE INDEX
postgres=# set enable_seqscan to off;
SET
postgres=# explain select * from lasse where date_part('year',  d) = 2015;
                                                 QUERY PLAN                                                
------------------------------------------------------------------------------------------------------------
 Bitmap Heap Scan on lasse  (cost=4.26..15.02 rows=13 width=4)
   Recheck Cond: (date_part('year'::text, (d)::timestamp without time zone) = '2015'::double precision)
   ->  Bitmap Index Scan on idx_date  (cost=0.00..4.25 rows=13 width=0)
         Index Cond: (date_part('year'::text, (d)::timestamp without time zone) = '2015'::double precision)
(4 rows)

postgres=#
Zum Vergrößern anklicken....
:) , was meinst du denn ??? Geht natürlich auch bei MySQL

Code: 
CREATE INDEX YearOrderDate ON orders ((YEAR(orderDate)));

Ich liebe kurze Indexe, hat aber bei einem Datefield schon Nachteile.

Mit BETWEEN [von] AND [BIS] hast du den Vorteil das du den vollen index nutzen kannst.
Und wenn du z.B. ein abweichendes Wirtschaftsjahr (1.4.2005 bis 31.3.2006) geht das mit
BETWEEN aber nicht mit dem INDEX nur auf Jahr.
 
lasse schrieb:
wie man mit OpenAI hochpräzise SQL-Abfragen erstellen kann
Zum Vergrößern anklicken....
Lieber " @lasse ", schön dass Du Dich ganz persönlich bemühst, hier auf Deinen Blogbeitrag hinzuweisen! Du musst aber vielleicht noch an Deinem Sprachmodell arbeiten.
Woher nimmst Du dieses Wort "hochpräzise" und was soll es bedeuten?
Hochpräzise formuliert? Tja, das ist irgendwie für Mensch und Maschine minimale Voraussetzung, damit die Abfrage läuft. Also irgendwie Standard- wenn auch nicht selbstverständlich, das ist also ganz gut trainiert.
Hochpräzises Ergebnis? Dafür ist die SQL Engine zuständig, kann also nicht gemeint sein bzw. ist kein Verdienst der AI.

Es gäbe dann noch Dinge, die wirklich spannend für einen performanten & Resourcen schonenden Betrieb einer DB sind. DB spezifisches Know How jenseits von SQL Standard. Da wäre dann fachliche Präzision gefragt.
Das erste Statement im Beitrag macht leider einen Join per Where Clause. Das ist nicht verboten, sagen wir, es ist ein minimalistischer oder traditioneller Standard. Ich würde es aber nicht hochpräzise nennen. BTW im Original ist von highly accurate die Rede. An der Stelle ist entweder schon das Original einem mäßigen Modell gefolgt oder das deutsche Sprachmodell.
 
Werbung:
zum Thema 'hochpräzise' und SQL vielleicht noch der Hinweis, daß ein "select *" niemals als 'hochpräzise' bezeichnet werden kann, höchstens als 'hochgefährlich', wenn das automatisiert und ungeprüft erstellt & übernommen wird.
 
Zurück
Oben