Hallo Janosh!
Im Normalfall wäre aber die Abfrage, welche Kunden werden von
Betreuer X bearbeitet? In diesem Fall wäre nur 1 Tabelle
betroffen, während bei der Einführung des Integer-Schlüssels 2
Tabellen betroffen wären.
Ist das dennoch effizienter bei grossen Tabellen?
Die richtige Antwort darauf: Das kann man so nicht sagen 
. Vielleicht etwas hilfreicher und ausführlicher geht’s mit Extrembeispielen:
Bsp A mit nur einer Tabelle:
Irgendwann kommst du zum Schluss, dass du zum Betreuer nicht nur den Namen, sondern auch noch den Lebenslauf abspeichern willst (so ein netter VARCHAR2(2000) oder so). Dieses speicherst du jetzt pro Kundenbetreuungssatz ab (also wenn der Betreuer XYZ 100 Kunden betreut, dann eben 200 K) und liest es dann auch gleich jedesmal mit, wenn du die Tabelle liest. Des weiteren stellst du ein wenig später auch noch fest, dass du einen Betreuer hast, der aber im Moment mal keine Kunden betreut (neu, karenziert, wasauchimmer). Den spiecherst du jetzt entweder gar nicht, woanders oder mit einem Dummy-Kunden. Erscheint mir alles nicht besonders hübsch, aber wenn ich das da oben alles nicht habe und ein Betreuername 3 Zeichen hat, dann bin ich dafür mit Sicherheit schneller, als wenn ich das ganze über zwei Tabellen mache).
Bsp B mit zwei Tabellen:
Es gibt nur zwei Betreuer, einer Betreut Kunde X, der andere betreut alle anderen Kunden (so 10.000.000 an der Zahl, schliesslich sind wir ja ein dotcom, da geht das schon). Du speicherst jetzt anstelle des 100-stelligen (sprich 100 Byte) langen Betreuercodes 10.000.001 mal nur jeweils 22 Byte für die Zahl. Macht 724 MB Ersparnis - bei keinerlei Performance Verlust (die Betreuungsdaten des ersten Betreuers zu lesen ist zusätzlich zum Index-Zugriff auf die Kunden-Betreuer-Daten noch ein Full-Table-Scan auf die Betreuer (den Index hier sparen wir uns lieber, bevor unsere DB noch auf die Ide kommt, den auch tatsächlich zu verwenden); die Betreuungsdaten des zweiten Betreuers zu lesen ist ein Full-Table-Scan auf beide Tabellen, wobei der FTS der Betreuer-Tabelle wohl kaum ins Geweicht fällt).
Fazit: Welche Lösung performanter ist, hängt nicht nur von der Struktur, sondern auch von der Verteilung und Natur der Daten ab. Allerdings würde ich generell das Performance-Problem - das es ja möglicherweise gar nicht gibt - erst dann behandeln, wenn die Datenstruktur einmal RICHTIG ist, und das hat wiederum viel weniger mit Normalformen und schlauen Büchern als mit Hausverstand, TESTS und vor allem den Anforderungen zu tun (eine DB, aus der primär gelesen wird [aka OLAP] stellt ganz andere Anforderungen, als eine, in der gleichermassen gelesen, Sätze eingefügt, geändert und gelöscht werden [aka OLTP]). Konkret sollte es einer modernen relationalen DB ziemlich wurscht sein, ob sie gerade aus einer, zwei oder fünf Tabellen liest, schliesslich wurden relationale Datenbanken genau dafür konzipiert (und schön langsam fängt das sogar auch noch an zu funktionierenn).
Ich hoffe das war nicht allzu verwirrend,
lg
Martin
