Weil es eben nicht immer gut ist, z.B. wenn Vererbung ins Spiel kommt.
Wenn du sowas mal in einer relationalen Datenbank abgebildet hast, dann weisst du wieso es nicht gut ist.
Bzw. ich kann's dir auch sagen: es skaliert scheisse schlecht. Abfragen sind dadurch schnell mal um ein Vielfaches langsamer als wenn man alle Spalten in einen einzigen Table wirft. Was dann aber auch wieder schlecht ist, weil der Table irre breit wird (=unübersichtlich). Und weil man kaum mehr sinnvoll Constraints auf die Felder setzen kann. Alle Felder bis auf die der ersten Basisklasse müssen dann nullable sein, was aber wieder doof ist, wenn die Felder für Objekte eines bestimmten Typs eben nicht NULL sein dürfen.
Natürlich kann man auch pro konkretem Typ eine Tabelle machen, die alle Felder enthält, inklusive der von der Basisklasse geerbten Felder. Das ist aber wieder doof, weil man dann in vielen verschiedenen Tables suchen muss, wenn man ein Objekt sucht vom dem man nur den Primary-Key und die Basisklasse kennt, nicht aber den konkreten Typ.
Ein weiterer Punkt: beim Programmieren hat man oft mal Objekte deren Daten Listen oder z.T. sogar Baumartige Strukturen enthalten. In einer Tabellenbasierten DB lässt sich sowas kaum sinnvoll abbilden. Listen gehen natürlich noch mit Detail-Tables. Ist aber lästig in der Handhabung, und z.T. sind Detail-Tables auch nicht optimal was die Performance angeht.
Baumartige Strukturen sind natürlich theoretisch auch mit Tabellen abbildbar, aber was Handhabung und Performance angeht noch schlimmer als einfache Listen.
Einige RDBMS bieten als Mittelweg auch Dinge wie z.B. XML Spalten an. Auf diese kann man dann spezielle XML-Indexe definieren, in denen man dann mehr oder weniger performant mit XPath/XQuery suchen kann.
