mysql und PHP (wieder)

Impressum | Werbung

Geizhals » Forum » Programmierung »

mysql und PHP (wieder) (30 Beiträge, 170 Mal gelesen)

Top-100 | Fresh-100

Du bist nicht angemeldet. [ Login/Registrieren ]

a%

google -> wildcard mysql

Wozu weibliche Unvernunft imstande ist, hat sich schon an der Idee erwiesen, sich von einer sprechenden Schlange Diätvorschriften geben zu lassen. (Orson Welles)

kA
würde mal auf nein tippen (kann aber auch ja sein

)

Wozu weibliche Unvernunft imstande ist, hat sich schon an der Idee erwiesen, sich von einer sprechenden Schlange Diätvorschriften geben zu lassen. (Orson Welles)

probiers aus

Wozu weibliche Unvernunft imstande ist, hat sich schon an der Idee erwiesen, sich von einer sprechenden Schlange Diätvorschriften geben zu lassen. (Orson Welles)

Wenn du alle a's willst - also groß und klein:

SELECT * FROM tabelle WHERE UPPER(feld) LIKE 'A%';
wenn's aber nur die mit kleinem a sein sollen:
SELECT * FROM tabelle WHERE feld LIKE 'a%';

Ich kenn ja "mysql" nicht, aber würde bei einem solchen SQL-Statement überhaupt noch ein Index Anwendung finden?

Ich kenn die MySQL auch net

Bei "richtigen" DBs wie Oracle, DB2 und PostgreSQL kommt bei
LIKE aber sehr wohl ein Index zur Anwendung, wenn möglich und sinnvoll (Optimizer-Entscheidung).

Also LIKE 'ABC%' kann index Nutzen, LIKE '%ABC' net.

Ein beliebter Fehler [auch in prof. Programmen] ist ja, daß wer
WHERE SUBSTR(feld,1,3) = 'ABC'
schreibt... anstelle von
WHERE feld LIKE 'ABC%'.

Denn ersteres kann niemals den Index nutzen, zweiteres schon...

Meine Bedenken galten eher der "upper()" als der "like"-Angabe

Das UPPER() wird nur einmal ausgewertet - und über das Ergebnis der Index-Scan (eben nicht ein Full-Table-Scan) gemacht.

Da bin ich mir bei der PostgreSQL 100pro sicher (habe selbst öfter eigene Datentypen plus dazugehörige Indizes für die Firma entwickelt) und bei Oracle ebenso (Optimizer-Ausgabe kontrolliert).

Das UPPER() wird nur einmal ausgewertet - und über das Ergebnis der Index-Scan
(eben nicht ein Full-Table-Scan) gemacht.

Du hast die "upper()"-Function ja nicht auf den zu vergleichenden Wert, sondern auf das DB-Feld angewendet.
Wennst jetzt 2Mio Records hast, müssen doch zwangsweise 2Mio Felder via "upper()" umgerechnet und danach vergleichen werden um auf das Ergebnis zu kommen.
Ich selber verwende diese Art des vergleiches ja nie. Da bei meiner DB die Indizies automatisch auf Kleinbuchstaben umgerechnet werden (nicht die Felder

AUTSCH! Ich bin ein /DILLO/.
Ich war gedanklich völlig falsch und bei einer Abfrage wie

SELECT xyz FROM tabelle WHERE UPPER(benutzereingabe) = feld

- einfach weil ich das oft brauch

.

Du hast Recht, im Normalfall kann er dann so keinen Index verwenden - außer du hast einen Function based Index wie

CREATE INDEX idx ON tabelle(UPPER(feld))

Dann natürlich schon (PostgreSQL-Syntax)

Danke! Daß Du mir mein naives Weltbild bezüglich Indizierung nicht ruiniert hast.
Ich dachte schon, hier hätte sich mehr getan als ich geistig aufnehmen könnte

Es gibt ja DB´s (und ich arbeite mit einer solchen), wo die zu indizierenden Felder vom Typ "char" innerhalb der Index-Kette jeweils als "case-sensitive" / "case-insensitive" gekennzeichnet werden können. Daher hab ich mir bei SQL-Abfragen nie wirklich Gedanken darüber gemacht.
Aber ich war mir sicher, daß Funktionen innerhalb einer Query, die sich auf DB-Felder beziehen, nie indiziert ablaufen können.

Wie gesagt... Mit function based Index schon...

Beweis:

=# CREATE TABLE bubu ( a varchar(20) );
CREATE TABLE
x=# INSERT INTO bubu values('jsfkf');
INSERT 17145 1
x=# CREATE INDEX xxx on bubu(upper(a));
CREATE INDEX
x=# EXPLAIN SELECT * from bubu where upper(a) = 'X';
                     QUERY PLAN
-----------------------------------------------------
 Seq Scan on bubu  (cost=0.00..1.01 rows=1 width=24)
   Filter: (upper((a)::text) = 'X'::text)
(2 Zeilen)

x=# set enable_seqscan = off;
SET
x=# EXPLAIN SELECT * from bubu where upper(a) = 'X';
                           QUERY PLAN
-----------------------------------------------------------------
 Index Scan using xxx on bubu  (cost=0.00..4.68 rows=1 width=24)
   Index Cond: (upper((a)::text) = 'X'::text)
(2 Zeilen)

x=# EXPLAIN SELECT * from bubu where upper(a) like 'X%';
                                     QUERY PLAN
------------------------------------------------------------------------------------
 Index Scan using xxx on bubu  (cost=0.00..4.68 rows=1 width=24)
   Index Cond: ((upper((a)::text) >= 'X'::text) AND (upper((a)::text) < 'Y'::text))
   Filter: (upper((a)::text) ~~ 'X%'::text)
(3 Zeilen)

Mag ich eh sehr... Dadurch, daß er so generell ist - die verwende ich echt öfter.

EDIT:
Scheint so, als ob sich doch mehr getan hat als Du verarbeiten willst, hehe

EDIT²:
Wobei function based Indizes zwar immer (PostgreSQL und Oracle) auch bei selbstdefinierten Funktionen klappen - aber nur, wenn sie IMMUTABLE sind, d.h. wenn bei derselben Eingabe dieselbe Ausgabe resultiert. Dabei baut er halt den Index statt über die Werte über die Funktionsergebnisse der Werte - aus Sicht der DB eine sehr primitive Ergänzung, für den Benutzer aber extrem praktisch.

10.08.2005, 18:33 Uhr - Editiert von gepeinigter_aon_neukunde, alte Version: hier

Tut mir leid, aber ich verstehe hier nur "bubu"!
Du hast eine Table mit einem Record erstellt?

Naja - wie auch immer, ich weiß daß Indizies auch Funktions-Basierend aufgebaut werden können. Wie diese über den DB-Server sinnvoll aufgelöst werden können, wenn die Query mal komplexer wird, und die Syntax zwar auf einen funktionsbasierenden Index refernziert, aber mit anderen Konditionen verknüpft werden, kann ich mir nimma vorstellen.

Denn anstatt im Index die Werte mit Pointer auf die Rows wegzuspeichern, muß
er nur noch einen Zwischenschritt machen: Anstatt die Werte selbst zu
speichern, speichert er die Funktionsergebnisse der Werte.

Ja sicha!

Mir geht es darum, welche wahnsinns-mörder-irrsinns-DB-Engine kann eine komplexe SQL-Query derart auflösen, daß nicht nur das Statement zerlegt und in Indizierte Komponeneten geteilt werden, sondern auch noch (und dies auf intellliegente Weise) die Expression der Index-Defintion (über function-based-expressions) mit integrieren kann.

Spürst was ich denk?

Das ist nicht so wild...
Die Statement-Parser sind IMHO via flex/bison geschrieben - da ist das extrahieren der Infos net sooo schlimm. Klar steigt der Parse-Aufwand etwas an (minimst) - aber dazu legt er sich ja die geparsten Statements in einem eigenen Buffer ab... Damit er sie bei einem nächsten mal nicht nochmal Parsen muß.

Viel genialer find' ich die Postgres beim allgemeinen Optimizer-lauf...

Oracle verwendet ja immer cost-based und ab einer gewissen Tabellenanzahl fällt's zurück auf rulebased.

Postgres:
Dursucht bis zu konfigurierbaren Tiefe (AFAIK default 11) alle Variationen - wenn's mehr Tabellen sind: Plan B nicht cost-based sondern genetische algorithmen, um zumindest schnell zu einer sehr guten Lösung zu kommen...

So oder so, das Hirnschmalz, das in Datenbanken geflossen ist, ist so oder so phantastisch... Ich finde ja sogar schon die Transaktionsmodelle faszinierend (bin leicht zu begeistern

)

sicherlich, sonst könntest die datenbank gleich scmeissen

problematischer is es schon wenn du mit irgend welchen funktionen auf ne column losgehst; da streiken auch die meisten großen datenbanken.

rennegade@gmx.at

problematischer is es schon wenn du mit irgend welchen funktionen auf ne
column losgehst;

Genau darum geht es ja! (upper)

kannst da aber eh sparen mit
... (like 'a%' or like 'A%' )

is sicher besser und schneller als eine columnfunction.

rennegade@gmx.at

Hallo und sorry, dass ich mich da Reinhänge.

Aber was ist, wenn ich jetzt einen längeren String vergleichen möchte und nicht nur einen Buchstaben?

Lg
Da Horstl

Möge die Macht mit Dir sein!

Und wennst hast ...

(like 'Mustermann%' or like 'mustermann%' or like 'MUSTERMANN%' or like 'MusterMann%' or ........)

.. dann wirds aber ein bisserl öd!

Und vor allem, was machst wenn der Vergleich nicht mit einer Konstante, sondern einer Variable erfolgt?

Dieses Forum ist eine frei zugängliche Diskussionsplattform.
Der Betreiber übernimmt keine Verantwortung für den Inhalt der Beiträge und behält sich das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
Datenschutzerklärung