nicht angemeldet
hallo ilja,
worum geht es dir eigentlich? die tatsachen habe ich weder erfunden noch beeinflußt. ich gebe sie hier lediglich wieder.
aus wie vielen tabellen eine datenbank besteht ist kein wunschdenken, sondern das ergebnis einer analyse zum datendesign. ich gehe davon aus, daß dir dieses bekannt ist. begriffe wie relation, normalisierung usw. wollen wir hier ja nicht sinnlos ausdiskutieren. zwischen sortiert und organsiert besteht ein nicht zu verwechselnder unterschied.
wenn du eine abfrage findest, welche 'mein' wunder-design aus allen nähten platzen läßt, wurde diese anforderung bei der analyse vergessen, oder diese anforderung wurde nicht verlangt. um wie viele datensätze es konkret geht, spielt hierbei keine rolle.
zudem sollen hier keine wunder produziert werden.
datenbanken sind organsiert. wie diese organisation im ergebnis aussieht, ist folge der analyse und designs. in der regel gibt es hier auch sortierungen.
in zeitgemäßen softwarearchitekturen ist die schnittstelle zur persistenzschicht eh nur als objektmodell vorhanden. wenn dort bspw. n:m beziehungen physisch durch eine zwischentabelle abgebildet werden, ist dies diesseits der schnittstelle völlig unbekannt. diese, natürlich zwangsläufig sortierte und indizierte, tabellen werden völlig automatisch von der persistenzschicht gemanaged. ein schönes beispiel hierfür ist die CMP (container managed persistenz) der entity-beans aus java enterprise.