nicht angemeldet
Tach!
Wenn du schon nicht mit Unit-Tests versuchst, robusten Code zu schreiben,
ich nehme ja nicht an, dass das so unfreundlich gemeint war, wie es für mich jetzt klingt. =) Abgesehen davon ... ich verstehe den Satz nicht. Unit-Tests?
Das ist eine Vorgehensweise, bei der man zuerst definiert, wie sich ein bestimmer Code-Teil (Unit) zu verhalten hat, was er in den verschiedenen Fällen inklusive Fehlerfällen für ein Ergebnis liefern soll. Diese Definition kippt man in kleine Codehäppchen, für jeden zu testenden Fall eins. Jetzt erst schreibt man den eigentlichen produktiven Code und lässt immer wieder den Testcode laufen, bis alles "grün" ist. Das ist natürlich aufwendig, zahlt sich aber später aus, weil man durch die Tests schnell feststellen kann, wenn man etwas inkompatibles in den Code eingebaut hat.
Allerdings ist ein Unit-Test in deinem Fall mit Vorsicht zu genießen, weil er gegen ein externes System (das DBMS) gefahren werden müsste. Das macht man nicht, weil man nicht das exteren System testen will.
Wie auch immer, das war jetzt keine Ermunterung zum TDD (Test Driven Design), sonden nur mal so erwähnt.
dann solltest du wenigstens im Laufe der Entwicklung mit Debug-Ausgaben die beiden Fälle provozieren und dir deren genaues Ergebnis anschauen.
Hatte ich jetzt Recht mit der Annahme, dass da entweder 0 oder 1 rauskommt - oder nicht?
Darauf kommt es nicht an, sondern was das System liefert. Ich nehme an, es ist so, weil MySQL nicht wirklich boolesche Werte kennt sondern dafür 0 und 1 nimmt.
Selbst wenn es viele sind, kann die Performance ganz hervorragend sein, wenn zum Beispiel ein Index bei der Suche helfen kann.
Das verstehe ich nicht ganz. Um bei meinem Beispiel zu bleiben: Wenn die Tabelle eine Spalte ID hat (Primärindex) und eine Spalte mit gesperrten Mailadressen und ich jetzt überprüfe, ob eine bestimmte Mailadresse in der Tabelle vorhanden ist - inwiefern soll/kann mir der Primärindex ID jetzt behilflich sein?
Der nicht, aber ein (weiterer) Index auf der Mailadressen-Spalte. Den wirst du vermutlich in der Ausprägung Unique Index sowieso brauchen, um doppelte Einträge zu verhindern.
Ich denke, du kannst die Lösung mit EXISTS im Hinterkopf behalten und darauf zurückkommen, wenn du an dieser Stelle Performanceprobleme bemerkst. Natürlich kannst du auch gleich EXISTS verwenden - zum Preis von etwas mehr Komplexität.
Verstehe ich Dich richtig, dass für meinen gegebenen Fall die Art, wie ich es im Ursprungsposting gelöst habe, in Ordnung ist?
Ja, wenn die genannten Bedingungen zutreffen.
dedlfix.