Re: PostgreSQL native
Verfasst: Sa, 06. Jul 2019 5:40
zurück zum Thema Index
ich hatte schon im anderen Thread über den PostgreSQL Index gesprochen und das dass xBase "Denken" da mal wieder eine Rolle spielt.
---
ohne Index würde man unter xBase LOCATE verwenden was einem WHERE in SQL entspricht.
wenn wir in xBase einen Index erzeugen müssen wir SEEK / FIND nutzen und den Suchbegriff als Argument.
klar das wir in xBase "den" Index aktiveren müssen mit OrdSetFocus()
ein SQL Index arbeitet völlig anders was die Verwendung angeht denn das bestimmt der SQL Server
bei ein SQL Qwery "sucht" der SQL Server nach einem "passenden" Index zu ORDER während die Syntax von WHERE nicht geändert werden muss.
zum "suchen" und der Bewertung von "passend" gibt ANALYZE die "Kosten" an. wo die wenigsten "Kosten" sind da "passt" es am besten
---
unter xBase kann ein IndexKey() über mehrer Felder gehen. ein SQL Index verwendet üblicherweise nur ein FIELD.
ein Index hat als "Neben Effect" eine (BTREE) Sortierung und das ist gemeint wenn man mehrere Felder im IndexKey() hat.
das war nun der Punkt zu meiner Theorie warum PgDBE die internen Index FIELD hat die man IMHO nicht benötigt
unter SQL gibt es ORDER BY was dafür zuständig ist
wenn das erste Argument von ORDER BY das selbe FIELD wie "in" einem Index ist wird der Index vom Server aktiviert.
---
üblicherweise ist ein xBase IndexKey() ein String d.h. man muss alles nach Type "C" umwandeln
unter SQL können die Argumente für ORDER BY jeden Type haben !
wenn man einen IndexKey() Ausdruck für SQL verwenden will muss man alle xBase Function entfernen
die Feldname bekommt man ja mit DbStruc() die ich mit dem IndexKey() Ausdruck vergleichen kann.
es reicht also wenn ich von den xBase Index Dateinen den IndexKey() hole/speichere mit DBF Namen zu den die gehören.
um einen xBase Index zu simulieren brauche ich nur in der Qwery mit ORDER BY den bearbeiteten IndexKey() als Argument angeben.
die Information in den internen Index FIELD werden deshalb NICHT gebraucht
ich brauche PostgreSQL Index und ein FIELD reicht aus
ich hatte schon im anderen Thread über den PostgreSQL Index gesprochen und das dass xBase "Denken" da mal wieder eine Rolle spielt.
---
ohne Index würde man unter xBase LOCATE verwenden was einem WHERE in SQL entspricht.
wenn wir in xBase einen Index erzeugen müssen wir SEEK / FIND nutzen und den Suchbegriff als Argument.
klar das wir in xBase "den" Index aktiveren müssen mit OrdSetFocus()
ein SQL Index arbeitet völlig anders was die Verwendung angeht denn das bestimmt der SQL Server
bei ein SQL Qwery "sucht" der SQL Server nach einem "passenden" Index zu ORDER während die Syntax von WHERE nicht geändert werden muss.
zum "suchen" und der Bewertung von "passend" gibt ANALYZE die "Kosten" an. wo die wenigsten "Kosten" sind da "passt" es am besten
---
unter xBase kann ein IndexKey() über mehrer Felder gehen. ein SQL Index verwendet üblicherweise nur ein FIELD.
Code: Alles auswählen
CREATE INDEX cIndex_Name ON cTable_Name (cField_Name)
das war nun der Punkt zu meiner Theorie warum PgDBE die internen Index FIELD hat die man IMHO nicht benötigt
unter SQL gibt es ORDER BY was dafür zuständig ist
wenn das erste Argument von ORDER BY das selbe FIELD wie "in" einem Index ist wird der Index vom Server aktiviert.
---
üblicherweise ist ein xBase IndexKey() ein String d.h. man muss alles nach Type "C" umwandeln
unter SQL können die Argumente für ORDER BY jeden Type haben !
Code: Alles auswählen
SELECT * FROM artikel ORDER BY artnr,artikel,apreis LIMIT 100
die Feldname bekommt man ja mit DbStruc() die ich mit dem IndexKey() Ausdruck vergleichen kann.
es reicht also wenn ich von den xBase Index Dateinen den IndexKey() hole/speichere mit DBF Namen zu den die gehören.
um einen xBase Index zu simulieren brauche ich nur in der Qwery mit ORDER BY den bearbeiteten IndexKey() als Argument angeben.
die Information in den internen Index FIELD werden deshalb NICHT gebraucht
ich brauche PostgreSQL Index und ein FIELD reicht aus