MySQL-select-Suchfunktion verfeinern

[Sandra]

Hallo Forum,
weiss jemand wie ich Folgendes definieren muss?:
Ich möchte mit einem Schlag aus einer Tabelle alle Spalten löschen , die die in products_image aufgelisteten Werte (0058.jpg,0064.jpg,....usw) haben.
Ist das möglich??

DELETE products_image FROM products
WHERE products_image = "0058.jpg,0064.jpg"

Martin

[Cheatah]

Hi,

WHERE products_image = "0058.jpg,0064.jpg"

beschäftige Dich mit dem IN-Operator.

Cheatah

[Sandra]

kann leider keine passenden Beispiele finden.
Leider leider nicht

Sandra

[Tom]

Hello,

kann leider keine passenden Beispiele finden.
Leider leider nicht

Wie wäre es dann, wenn Du uns nochmal auf Deutsch erzählst, was Du vorhast?
Kleines Klartextbeispiel von Dir, und wir können Dir helfen.

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[sandra]

danke, antwort erhalten:
UPDATE products SET products_image = NULL WHERE products_image IN ("0134.jpg", "0141.jpg")

[Cheatah]

Hi,

UPDATE products SET products_image = NULL WHERE products_image IN ("0134.jpg", "0141.jpg")

bedenke: NULL != ""

Cheatah

[Philipp Hasenfratz]

Halihallo Cheatah,
Halihallo Sandra

UPDATE products SET products_image = NULL WHERE products_image IN ("0134.jpg", "0141.jpg")
bedenke: NULL != ""

Jep, und zudem lässt sich NULL nicht vergleichen, da das Ergebnis
nicht deutbar wäre. Deshalb gibt es auch products_image IS NULL,
denn *das* ist deutbar.

Folglich musst du korrekterweise schreiben:
a:=NULL
(a IS NULL) != (a="")

:-)

Viele Grüsse

Philipp

[Ilja]

yo holladiho,

jetzt muss ich auch noch mal meinen senf dazu geben.

Jep, und zudem lässt sich NULL nicht vergleichen, da das Ergebnis
nicht deutbar wäre.

ist es nicht vielmehr so, dass es sich zwar vergleichen läßt, aber immer das gleiche ergebnis hervorbringt, nämlich false ?

Ilja

[Philipp Hasenfratz]

Halihallo Ilja

jetzt muss ich auch noch mal meinen senf dazu geben.

Naja, das habe ich mir bei meinem Posting eben auch gedacht ;-)

Jep, und zudem lässt sich NULL nicht vergleichen, da das Ergebnis
nicht deutbar wäre.
ist es nicht vielmehr so, dass es sich zwar vergleichen läßt, aber immer das gleiche ergebnis hervorbringt, nämlich false ?

Nein. Das Ergebnis eines Vergleiches ist in der Tat wiederum NULL,
wenn einer der Operanden NULL ist. Es ist jedoch IMO eine Konvention,
dass dieses NULL z.B. bei einer WHERE-Klausel zu "false"
uminterpretiert wird. Merkbar wird dies bei einem attr >= ALL
(subselect), oder eben attr => ANY (subselect) [oder halt einem
anderen Vergleichsoperator].

Ich hab das jetzt nicht auf meiner DBMS ausprobiert, aber dort müsste
sich schliessen lassen, dass es als false interpretiert wird, wie du
gesagt hast.

Faktum bleibt, dass NULL ein nicht vergleichbarer Wert ist, denn NULL
hat zum einen viele Bedeutungen (not applicable, unknown, not
known yet etc.) und genauso unterschiedlich kann die Interpretation
des Vergleichsergebnisses sein. Da eben kein eindeutiger Schluss aus
einer Vergleichsoperation folgt, ist das Ergebnis wieder NULL.

Dies stimmt nicht immer bei Bool'schen Operatoren:
z.B. ist NULL OR TRUE = TRUE, denn es spielt keine Rolle, was als
Wert oder "Unwert" für NULL angenommen wird.
Genauso verhält sich ein NULL AND FALSE, das gibt immer FALSE.

Viele Grüsse

Philipp

[Ilja]

yo Philipp,

Faktum bleibt, dass NULL ein nicht vergleichbarer Wert ist, denn NULL
hat zum einen viele Bedeutungen

aber fakt ist doch auch, dass vergleiche mit NULL durchaus gemacht werden und sie wie auch immer unter dem strich den wert False erhalten, weil es nur zwei zustände geben kann (True/False) ?

Ilja

[Philipp Hasenfratz]

Halihallo Ilja

Faktum bleibt, dass NULL ein nicht vergleichbarer Wert ist, denn NULL
hat zum einen viele Bedeutungen

aber fakt ist doch auch, dass vergleiche mit NULL durchaus gemacht werden und sie wie auch immer unter dem strich den wert False erhalten, weil es nur zwei zustände geben kann (True/False) ?

Nein. Ein Vergleich mit einem NULL-"Wert" endet mit NULL, die
Wertung in einem Kontext, der kein NULL-"Wert" erlaubt ist einfach
FALSE. In der Datenbanktheorie spricht man von einer dreiwertigen
Logik, es gibt eben nicht nur TRUE und FALSE, sondern auch NULL
(unknown). In einem relationalen Datenbanksystem gibt es nicht nur
zwei Zustände, sondern deren drei.

Ein Vergleich ist möglich, das stimmt. Aber in dieser dreiwertigen
Logik gibt es nicht nur die Ergebnisse true|false, sondern auch
unknown (NULL).

Viele Grüsse

Philipp

[Ilja]

yo,

Ein Vergleich ist möglich, das stimmt. Aber in dieser dreiwertigen
Logik gibt es nicht nur die Ergebnisse true|false, sondern auch
unknown (NULL).

ein vergleich in einer WHERE klausel muss meiner meinung nach immer nur zwischen zwei zuständen unterscheiden, False oder TRUE oder wörtlich gesprochen nimm ich den datensatz oder nicht. ein dbms muss halt eben eine entscheidung treffen, insofern ist mir der undefinierte zustand noch nicht ganz klar. ;-)

Ilja

[Philipp Hasenfratz]

Halihallo Ilja

Ein Vergleich ist möglich, das stimmt. Aber in dieser dreiwertigen
Logik gibt es nicht nur die Ergebnisse true|false, sondern auch
unknown (NULL).

ein vergleich in einer WHERE klausel muss meiner meinung nach immer nur zwischen zwei zuständen unterscheiden, False oder TRUE oder wörtlich gesprochen nimm ich den datensatz oder nicht.

Genau, deshalb muss genau hier eine Konvention eingeführt werden,
die eben besagt, dass NULL als Auswertung der WHERE-Klausel als
FALSE *interpretiert* wird.

ein dbms muss halt eben eine entscheidung treffen, insofern ist mir der undefinierte zustand noch nicht ganz klar. ;-)

Nun, der NULL-"Wert" ist in der relationalen Datenbank-Welt (und
nicht nur da, es gibt ihn ja auch in einigen Programmiersprachen) ein
wichtiger Bestandteil. Aber wenn man sich erstmal entscheidet sowas
aufzunehmen, muss man das semantisch auch wirklich durchziehen. Die
Folge war, dass alle Operatoren und Funktionen einen wohldefinierten
Rückgabewert auf einen NULL-Operanden liefern mussten (String,
arithmetische, boolsche, ... Operatoren). Genauso musste z.B. auch
die WHERE-Klausel einen wohldefinierten Rückgabewert haben und dieser
ist per Definition (und wie du sagst) zwingend false oder true.
Entweder Tupel rein, oder raus aus der Ergebnisrelation [1]. Dieser
wohldefinierte Rückgabewert musste jedoch definiert werden, da man
aus einer dreiwertigen Logik nicht einfach auf ein zweiwertiges
Ergebnis (true|false) kommen kann. Dafür gibt es dann die
Konventionen, welche bei SQL besagt, dass wenn der Kontext eine
zweiwertige Logik erzwingt, NULL zu false wird; genausogut hätte man
sagen können, dass NULL zu true werden soll. Eine andere Konvention
besagt, dass NULL-Werte bei Agregatsfunktionen (ausser COUNT(*), der
ist ja nicht Attributwertbezogen) ignoriert werden. Wieder eine
andere Konvention besagt, dass NULL bei einem GROUP BY auch
als Wert angesehen wird. etc. etc.
Der undefinierte Wert hat also weitreichenden Einfluss auf eine
RDBMS. Und dies alles "nur", weil man ein unbekannter Wert auch
speichern möchte (sei es ein Preis eines Artikels, den man nicht
kennt, oder eine Referenz auf ein nicht vorhandenes Tupel (Foreign
Key) oder bei einem OUTER JOIN)...

Naja, der NULL-Wert ist wirklich ein spezieller Zeitgenosse, der
Umgang mit ihm birgt auch einige Gefahren...

[1] Ein "ich weiss nicht wohin mit dem Tupel" gibt es nicht :-)

Viele Grüsse

Philipp

[Ilja]

yo Philipp,

Genau, deshalb muss genau hier eine Konvention eingeführt werden,
die eben besagt, dass NULL als Auswertung der WHERE-Klausel als
FALSE *interpretiert* wird.

ohne kleinlich wirken zu wollen, das bestätigt doch die aussage, dass es nur zwei ergebnisse bei bedingungen gibt, true oder false und nicht drei.  NULL ist ein wert, den ein Feld innerhalb seiner domäne einnehmen kann. und bezogen auf eine bedingung kann ein argument einen wert von NULL einnehmen, nicht aber die gesamte bedingung. die frage ist nur, wie eine bedingung diesen wert verarbeitet, sprich es gibt nicht drei zustände, sondern nur zwei was bedingungen betrifft, egal ob man sich nun für False oder TRUE entscheidet oder nicht ?

Ilja

[Philipp Hasenfratz]

Halihallo Ilja

Genau, deshalb muss genau hier eine Konvention eingeführt werden,
die eben besagt, dass NULL als Auswertung der WHERE-Klausel als
FALSE *interpretiert* wird.

ohne kleinlich wirken zu wollen, das bestätigt doch die aussage, dass es nur zwei ergebnisse bei bedingungen gibt, true oder false und nicht drei.  NULL ist ein wert, den ein Feld innerhalb seiner domäne einnehmen kann. und bezogen auf eine bedingung kann ein argument einen wert von NULL einnehmen, nicht aber die gesamte bedingung.

Man muss hier vorsichtig mit der Wahl der Begriffe sein:
Der WHERE-"Teil" ist keine Bedingung sondern ein bool'scher
Ausdruck. Dieser hat wirklich drei mögliche Ergebnisse. Das WHERE
Keyword besagt einfach, dass wenn der bool'sche Ausdruck TRUE ist,
wird das Tupel selektiert. Was nun bei einem NULL passiert, ist eben
konventionssache.
Die Bedingung bei WHERE ist also: Falls bool'scher Ausdruck nach NULL
aufgelöst wird, wird das Tupel nicht selektiert, bei FALSE
ebensowenig, nur bei TRUE wird selektiert. Folglich ja, die Bedingung
kennt nur zwei Zustände, aber der bool'sche Ausdruck hat drei!

Aber ein bool'scher Ausdruck wird intern stets in dreiwertiger Logik
ausgewertet:

Verwende z.B. MySQL und gib dir folgendes aus:

SELECT 1+NULL;

gibt NULL und nicht true, false, 1 oder irgendwas anderes.

SELECT NULL OR 0;

gibt NULL und nicht FALSE (0).

die frage ist nur, wie eine bedingung diesen wert verarbeitet, sprich es gibt nicht drei zustände, sondern nur zwei was bedingungen betrifft, egal ob man sich nun für False oder TRUE entscheidet oder nicht ?

Bei der WHERE|HAVING-Klausel, ja. Die Bedingung liefert zwei mögliche
Ergebnisse. Aber intern wird der *Ausdruck* (nicht die Bedingung) in
einer dreiwertigen Logik verarbeitet. Beispiel:

Vielleicht ein kleines Beispiel, warum der Ausdruck wirklich
dreiwertig verarbeitet wird:

Wir haben eine Tabelle a mit einem Attribut a. Es existiert ein
Tupel, bei dem a NULL ist. Also:

Tabelle a:

a

NULL

SELECT * FROM a WHERE NOT(a)

Wenn man von einer zweiwertigen Logik ausginge und NULL als FALSE
interpretiert, würde NOT(a) TRUE sein! - Die RDBMS wird dir jedoch
ein Empty-Set liefern, warum? - Weil wenn a NULL ist, ist NOT(a) eben
auch wieder NULL und wird für die WHERE-Klausel in FALSE
uminterpretiert, somit wird kein Tupel selektiert => Empty-Set.
Fazit: Die Datenbank arbeitet intern mit einer dreiwertigen Logik und
wandelt in bestimmten Kontexten das Ergebnis in eine zweiwertige
Logik um (NULL:=FALSE). Aber: Das Ergebnis eines Ausdrucks ist und
wird immer dreiwertig bleiben, was die WHERE-*Bedingung* daraus macht
ist dann eine andere Geschichte.

Du siehst, du hast schon recht, eine WHERE|HAVING-*Bedingung* ist nur
zweiwertig, da ein NULL-Wert eben nicht ausgewertet werden könnte.
Aber der Ausdruck *ist* dreiwertig.

Ich hoffe, dass mit der kleinen Begriffsdefinition einiges klar
geworden ist, denn bool'scher Ausdruck != WHERE-Bedingung :-)

Viele Grüsse

Philipp

[Ilja]

yoho Philipp,

Der WHERE-"Teil" ist keine Bedingung sondern ein bool'scher
Ausdruck.

ich habe noch mal in meinen unterlagen nachgeschaut und zumindestens die oracle lehr(leer)bücher sprechen von conditions in der WHERE klausel also von bedingungen. diese bedingungen können durchaus durch logische (bool'sche) operatoren miteinander verbunden werden, muss aber nicht. insofern würde ich immer noch von bedingungen in der WHERE klausel sprechen. und bei diesen logischen operatoren ist in meinen buch auch nur von zwei zuständen die rede, true und false, ein dritter kommt dort nicht vor, wenn zum beispiel erklärt wird, wie AND, OR und NOT funktioniert.

Keyword besagt einfach, dass wenn der bool'sche Ausdruck TRUE ist,
wird das Tupel selektiert. Was nun bei einem NULL passiert, ist eben
konventionssache.

eine bedingung kann immer noch meiner meinung nach nicht NULL sein, sondern eben nur TRUE oder FALSE. ein wert innerhalb einer bedingung kann sehr wohl NULL sein.

SELECT 1+NULL;

gibt NULL und nicht true, false, 1 oder irgendwas anderes.

SELECT 1, 2, 3, 4, NULL FROM dual;

das beispiel ist nun in meinen augen merkwürdig, weil ganz einfach viel mehr als nur drei werte herauskommen können. es zeigt eigentlich nur, das NULL eben ein wert unter vielen ist, auch wenn es sich um einen besonderen wert handelt.

SELECT NULL OR 0;

gibt NULL und nicht FALSE (0).

jau, weil es auch keine bedingung ist.

SELECT if(NULL, 1, 0);

das gibt 0 zurück.

Bei der WHERE|HAVING-Klausel, ja. Die Bedingung liefert zwei mögliche
Ergebnisse.

grundsätzlich würde mir diese aussage ja reichen.

Wenn man von einer zweiwertigen Logik ausginge und NULL als FALSE
interpretiert, würde NOT(a) TRUE sein! - Die RDBMS wird dir jedoch
ein Empty-Set liefern, warum? - Weil wenn a NULL ist, ist NOT(a) eben
auch wieder NULL und wird für die WHERE-Klausel in FALSE
uminterpretiert, somit wird kein Tupel selektiert => Empty-Set.

um ehrlich zu sein, dieses beispiel würde meiner meinung nach für meine these sprechen oder ich lese einfach nur falsch. würde es drei zustände geben, könnte er ein record-set zurückliefern, nämlich den mit den wert NULL. da NULL werte innheralb einer bedingung aber grundsätzlich als FALSE gewertet werden, gibt er keinen zurück. und zweimal FALSE ergibt keinen record in der ergebnistabelle. würde es wirklich true, false und NULL geben, könnte er eventuell den NULL wert zurückgeben. tut aber nicht und das widerspricht nicht meiner annahme.

Fazit: Die Datenbank arbeitet intern mit einer dreiwertigen Logik und
wandelt in bestimmten Kontexten das Ergebnis in eine zweiwertige
Logik um (NULL:=FALSE). Aber: Das Ergebnis eines Ausdrucks ist und
wird immer dreiwertig bleiben, was die WHERE-*Bedingung* daraus macht
ist dann eine andere Geschichte.

nun ja, ich sprach von bedingungen und die kommen nun mal in der WHERE klausel vor. insofern ist es nicht ganz unerheblich, was daraus gemacht wird. ich habe imme noch den eindruck, NULL ist nur ein besonderer wert eines feldes, aber keine dritte option, die eine bedingung einnehmen kann.

Ilja

[Philipp Hasenfratz]

Halihallo Ilja

Der WHERE-"Teil" ist keine Bedingung sondern ein bool'scher
Ausdruck.

ich habe noch mal in meinen unterlagen nachgeschaut und zumindestens die oracle lehr(leer)bücher sprechen von conditions in der WHERE klausel also von bedingungen. diese bedingungen können durchaus durch logische (bool'sche) operatoren miteinander verbunden werden, muss aber nicht.

Klar. Du kannst auch WHERE substr(attr,0,5) schreiben, das substr-
Ergebnis wird einfach entweder als TRUE, FALSE oder NULL gewertet.
Es ist jedoch in jedem Fall ein Prädikat (ob nun bool'sche Operatoren
vorkommen oder nicht).

insofern würde ich immer noch von bedingungen in der WHERE klausel sprechen. und bei diesen logischen operatoren ist in meinen buch auch nur von zwei zuständen die rede, true und false, ein dritter kommt dort nicht vor, wenn zum beispiel erklärt wird, wie AND, OR und NOT funktioniert.

Schmeiss das Buch weg :-)
Gibt's darin kein Kapitel über NULL-Werte?

Keyword besagt einfach, dass wenn der bool'sche Ausdruck TRUE ist,
wird das Tupel selektiert. Was nun bei einem NULL passiert, ist eben
konventionssache.

eine bedingung kann immer noch meiner meinung nach nicht NULL sein, sondern eben nur TRUE oder FALSE. ein wert innerhalb einer bedingung kann sehr wohl NULL sein.

Nicht nur ein Wert, sondern auch ganze Teilausdrücke. Am Schluss
bleibt einfach true oder false übrig, das kann ich stehen lassen.

SELECT 1+NULL;
gibt NULL und nicht true, false, 1 oder irgendwas anderes.
SELECT 1, 2, 3, 4, NULL FROM dual;

das beispiel ist nun in meinen augen merkwürdig, weil ganz einfach viel mehr als nur drei werte herauskommen können. es zeigt eigentlich nur, das NULL eben ein wert unter vielen ist, auch wenn es sich um einen besonderen wert handelt.

Achtung, das ist zwar richtig. Ich spreche jedoch nicht von Ausgabe,
sondern von Prädikaten/Bedingungen/bool'schen Ausdrücken, nicht von
Werten.

SELECT NULL OR 0;
gibt NULL und nicht FALSE (0).
jau, weil es auch keine bedingung ist.

Nein, immer. Was die "Bedingung" daraus macht ist ihr Süppchen.

SELECT if(NULL, 1, 0);
das gibt 0 zurück.

Natürlich. Das IF-Statement besagt, dass wenn die Bedingung zu true
ausgewertet wird, 1 zurückgegeben wird, 0 andernfalls. "NULL!=true"
deshalb wird 0 ausgegeben.

Wenn man von einer zweiwertigen Logik ausginge und NULL als FALSE
interpretiert, würde NOT(a) TRUE sein! - Die RDBMS wird dir jedoch
ein Empty-Set liefern, warum? - Weil wenn a NULL ist, ist NOT(a) eben
auch wieder NULL und wird für die WHERE-Klausel in FALSE
uminterpretiert, somit wird kein Tupel selektiert => Empty-Set.

um ehrlich zu sein, dieses beispiel würde meiner meinung nach für meine these sprechen oder ich lese einfach nur falsch. würde es drei zustände geben, könnte er ein record-set zurückliefern, nämlich den mit den wert NULL.

Nein und ja. Was soll die Datenbank bei dem Prädikat NULL machen.
Dies heisst weder true noch false, also soll jetzt die Datenbank das
Tupel aufnehmen oder nicht? - Es nimmt es nicht auf, weil es eine
Konvention ist, dass NULL bei der WHERE-Klausel false ist.

da NULL werte innheralb einer bedingung aber grundsätzlich als FALSE gewertet werden, gibt er keinen zurück. und zweimal FALSE ergibt keinen record in der ergebnistabelle. würde es wirklich true, false und NULL geben, könnte er eventuell den NULL wert zurückgeben. tut aber nicht und das widerspricht nicht meiner annahme.

Es wiederspricht deiner Annahme nicht und meiner genausowenig. Wir
sagen ja unter dem Strich genau dasselbe, nur mit anderer
Argumentation.

Fazit: Die Datenbank arbeitet intern mit einer dreiwertigen Logik und
wandelt in bestimmten Kontexten das Ergebnis in eine zweiwertige
Logik um (NULL:=FALSE). Aber: Das Ergebnis eines Ausdrucks ist und
wird immer dreiwertig bleiben, was die WHERE-*Bedingung* daraus macht
ist dann eine andere Geschichte.

nun ja, ich sprach von bedingungen und die kommen nun mal in der WHERE klausel vor. insofern ist es nicht ganz unerheblich, was daraus gemacht wird. ich habe imme noch den eindruck, NULL ist nur ein besonderer wert eines feldes, aber keine dritte option, die eine bedingung einnehmen kann.

Oh, oh. Lies mal:
http://www.informatik.uni-stuttgart.de/ipvr/as/lehre/skripte/DBISWS0203/kapitel05.pdf
(Seite: 5-50), dort siehst du dass AND, OR, NOT etc. alle dreiwertig
sind und <cite>Das Ergebnis NULL bei einer Auswertung einer WHERE-
Klausel wird wie false behandelt</cite>
http://www.ipd.uni-karlsruhe.de/~ovid/Seminare/IMPWS03/Vortraege/OVID-IMPWS03_Null-Werte_in_Relationalen_Datenbanken.pdf
http://www.ipd.uni-karlsruhe.de/~ovid/Seminare/IMPWS03/Ausarbeitungen/OVID-IMPWS03_Null-Werte_in_Relationalen_Datenbanken_Ausarbeitung.pdf

(hab mal kurz gegoogled...)

Viele Grüsse

Philipp

[Ilja]

yoho Philipp,

Schmeiss das Buch weg :-)

nun, zwei büchlein (keine dicken wälzer) kosten sage und schreibe um die 100 euro. und davon habe ich wiederum 4 einheiten, also gesamtwert über 400 euro. das sollte man sich das wegschmeißen noch mal überlegen, zumal der inhalt eigentlich von guter qualität ist, halt orginal oracle mit oracle kugelschreiber und notizblock. ;-)

Nicht nur ein Wert, sondern auch ganze Teilausdrücke. Am Schluss
bleibt einfach true oder false übrig, das kann ich stehen lassen.

Oh, oh. Lies mal:
http://www.informatik.uni-stuttgart.de/ipvr/as/lehre/skripte/DBISWS0203/kapitel05.pdf

ja, da steht es schwarz auf weiss. dreier logik und andere interpretation des NULL zustandes bei der WHERE klausel. am ende unserer diskussionen bin ich immer ein stück schlauer. das muss ich mir mal ausdrucken, wenn ich wieder einen toner habe. der drucker ist zwar umsonst gewesen, aber irgendwie muss einer die gesamte tonerkassete mitgenommen haben. und da lohnt sich fast der ersatz nicht.

hast du noch andere gute links bezüglich datenbanken und abhängig von der NULL logik ?

Ilja

[Ilja]

hast du noch andere gute links bezüglich datenbanken und abhängig von der NULL logik ?

unabhängig von der NULL Problematik solte das heißen ;-)

Ilja

[Philipp Hasenfratz]

Halihallo Ilja

Schmeiss das Buch weg :-)

nun, zwei büchlein (keine dicken wälzer) kosten sage und schreibe um die 100 euro. und davon habe ich wiederum 4 einheiten, also gesamtwert über 400 euro. das sollte man sich das wegschmeißen noch mal überlegen, zumal der inhalt eigentlich von guter qualität ist, halt orginal oracle mit oracle kugelschreiber und notizblock. ;-)

Ich empfehle dann also den Kugelschreiber und den Notizblock zu
behalten :-)

ja, da steht es schwarz auf weiss. dreier logik und andere interpretation des NULL zustandes bei der WHERE klausel. am ende unserer diskussionen bin ich immer ein stück schlauer.

Das freut mich.

hast du noch andere gute links bezüglich datenbanken und abhängig von der NULL logik ?

Uhh, nö, ich halte mir im Kopf was ich zu halten vermag. Sonst
speichere ich zwar auch immer alles Wissen auf externen Datenträgern
um die Gehirnressourcen für wichtiges freizuhalten, aber Datenbanken
(und ein paar andere Gebiete :-)) bilden hierbei anscheinend eine
Ausnahme :-)
Hm. Mein externes Wissen ist eigentlich auch nur so gross wie das
Google-Universum :-)  will heissen: Wenn ich was nicht weiss, weiss
ich es (hoffentlich) nach Konsultation von Google.

Viele Grüsse

Philipp

[Ilja]

yo,

Ich empfehle dann also den Kugelschreiber und den Notizblock zu
behalten :-)

die bücher haben auch im gegensatz zu mir nicht von einer zweiwertigkeit geprochen, quasi das thema ein wenig ausgeschwiegen. und was das wort bedingung betrifft, so würde ich da immer noch meine zustimmung geben. insofern muss ich die bücher ein wenig in schutz nehmen. und bezogen auf eine bedingung kommt zumindestens am ende ja auch nur eine zweiwertige entscheidung raus und das nicht nur in der WHERE klausel. insofern ist nicht hopfen und malz verloren ;-)

Ilja

[Cheatah]

Hi,

bedenke: NULL != ""
Jep, und zudem lässt sich NULL nicht vergleichen, da das Ergebnis
nicht deutbar wäre.

Pseudocode != SQL

Cheatah ;-)

[Philipp Hasenfratz]

Halihallo Cheatah

bedenke: NULL != ""
Jep, und zudem lässt sich NULL nicht vergleichen, da das Ergebnis
nicht deutbar wäre.

Pseudocode != SQL

Jep, das lässt sich auch in einer binären Logik auswerten :-)

Viele Grüsse

Philipp

[Ilja]

yo,

Ich möchte mit einem Schlag aus einer Tabelle alle Spalten löschen , die die in products_image aufgelisteten Werte (0058.jpg,0064.jpg,....usw) haben.

ich bin mir nicht sicher, ob du datensätze löschen willst, die in einer spalte einen entsprechenden wert besitzen oder aber den spaltenwert ändern willst (eventuell NULL werte). willst du eine spalte löschen, so geht das nur für die gesamte tabelle, sprich alle datensätze.

DELETE products_image FROM products
WHERE products_image = "0058.jpg,0064.jpg"

DELETE löscht auf jeden fall datensätze und ändert keinen spalteninhalt oder löscht eine spalte aus einer bestehenden tabelle. wie auch immer, es wäre gut zu wissen, was genau du machen willst. ich tippe mal drauf, dass du datensätze löschen willst und dann wäre wie bereits von CHetah gesagt, der IN operator das richtige werkzeug.

Ilja

[Sandra]

ich möchte den Inhalt der Spalte products_image von "0134.jpg" auf
"" setzen. Also den Inhalt der Spalte löschen.

geht so nicht:

delete products_image from products where products_image="0134.jpg, 0141.jpg"

Sandra

[Ilja]

yo,

geht so nicht:

delete products_image from products where products_image="0134.jpg, 0141.jpg"

das kann so auch nicht gehen, da DELETE wie gesagt datensätze löscht und nicht einzelne Felder mit einem neuen Wert belegt. dafür verwende bitte die UPDATE Klausel, in der du die gewünschten datensätze in der WHERE klausel mit hilfe des IN operators auswählst.

UPDATE products SET producte_image = NULL WHERE products_image IN ("0134.jpg", "0141.jpg", ....)

Ilja

[sandra]

super
vielen Dank. Jetzt verstehe ich auch den in-operator
sandra

[Andreas Lindig]

Martin

Du hast Dich verraten "Sandra"

Gruß, Andreas