Ilja: auto_increment und LAST_INSERT_ID()

Beitrag lesen

yo,

in der theorie trennt man was nicht zusammen gehört (normalisierung), sag ich mal so salopp. nun ist die theorie nicht immer das gelbe vom ei, letztlich soll es sich ja in der praxis bewähren und laufen und zwar auf deine bedürfnisse optimiert. deswegen muss man von fall zu fall sehen, was gut ist.

mein erster vorschlag wäre, alles zu trennen, was nicht zusammen abgefragt wird, selbst wenn sie haargenau die gleichen attribute hätten und natürlich auch bei unterschiedlichen attributen. mir fällt jetzt kein wirklich gutes beispel ein, aber ich sage mal, wenn du ganz sicher weißt, dass die mietshäuser in berlin niemals mit den mietshäusern in münschen zusammen abgefragt werden, könnte man diese trennen. das hängt sicherlich auch immer ein wenig von der anzahl der tabellen ab. es würde nun wiederum keinen sinn machen, für jede stadt eine eigene tabelle zu haben. man muss da den goldenen mittelweg finden. diese aufteilung macht sinn, wenn man eine grosse anzahl von datensätze hat.

der zweite vorschläg wäre, genau das gegenteil zu tun, alles in eine tabelle zu schreiben, so wie du es selbst beschrieben hast und dann einfach bestimmte felder leer zu lassen. außerdem führt man noch eine zusätzliche spalte ein, welche die unterschiedlichen objekte klassifiziert, zum beispiel M für mietshaus, etc. dies ist zum beispiel eine gute lösung, wenn du nicht all zuviele datensätze (immobilien) hast und somit die geschwindigkeit sowieso hoch ist und sich der verwaltungsaufwand durch eine tabelle niedrig halten läßt.

das was du machst, die gemeinsamen attribute in einer tabelle verwalten und die speziellen in extra tabellen, dass würde ich nicht tun. die performance wird schlechter und auch die verwaltung dürfte nicht einfacher werden, eher im gegenteil, der aufwand wird größer, weil man ja immer mehrere tabellen ansprechen muss. selbst speicherplatz wird daurch nicht weniger. es gibt zwar fälle, wo man die attribute einer tabelle voneinander trennt. das hat aber anderen ursachen, weil man attribute die selten abgefragt werden, von den attributen die häufig abgefragt werden trennt, um die performance zu erhöhen, zumal das auch nicht jedes dbms mitmacht.

Ilja