Zitat von
Hansa:
Und sprechende (nicht) Primary Keys finde ich auch überflüssig.
IMHO sollte man zusammengesetzte benutzen, aber keine im Klartext ! Zumindest bei mir siehts so aus, daß ich z.B. für einen Preis, den Key zusammensetze als ID_KUNDE + ID_ART und dann natürlich als unique. Ich könnte ihn auch eindeutig machen durch Kunde.Nr + Art.Nr, aber dann wäre ich wieder in dem Dilemma, falls sich eine Nr. ändert.
Zum Schluß noch der Matchcode. Wozu den extra speichern ?
Das sind dann Redundanzen und die sollte man vermeiden. Hinzu kommt dann noch ein Problem. Entweder er wird so abgekürzt, daß ein Dritter gar nicht drauf kommt, oder er ist so lang, daß auch der kleinste Schreibfehler dazu führt, daß nichts gefunden wird. Und ich habe trotz UPPER,%LIKE% usw. noch keine Performance-Einbußen bemerkt.
Vielleicht sollte wir hier mal genauer unterscheiden:
Felder <> Key !
Es wir ja "nur" ein Key auf das Feld gesetzt.
Ds Zusammensetzen eines Keys bedeutet damit noch nicht, dass es ein neues Feld gibt, wo die Feld-Inhalte zusammengesetzt werden. Als zusammengesetzter Key kann das dann wieder Unique sein, aber die Felder bleiben getrennt.
Matchcode:
Benutzen wir auch bei Adressdaten. In der Firmenbezeichnung stehen of genug Daten, die du mit einem Upper und Like nicht finden kannst. Denke nur mal an Firmenabkürzungen mit und ohne Punkt/Leerzeichen. Wir legen zumindest Wert darauf, dass die Kunden so angeschrieben werden, wie in ihrer offiziellen Firmenbezeichung. Das ist aber auch die einzige Stelle, an der wir einen Matchcode verwenden.