und ich bezweifel einfach, das ein einziger Mensch das DB-Desing entwirft und sämtliche Serverapis dazu codet
Ich habe die erschreckende Feststellung gemacht das man es wirklich am besten einer möglichst kleinen und (hoffentlich) kompetenten Gruppe von Leuten überlässt eine Datenbankstruktur zu entwickeln, zumindest wenn die Datenbank nicht ein einfacher MySQL-Datendump ist (für das man meist besser SQLite nimmt). Größere Datenbankschiffe wie Oracle und DB2 neigen dazu exzentrisch zu reagieren, vor allem wenn es um Performance geht. Das führt dann dazu das komplexere Abfragen nur durch einfaches Umstellen der Abfrageparameter um mehrere Faktoren schneller ablaufen können.
Leider fühlen sich die meisten PHP-Programmierer befähigt Datenbanken zu "designen" weil sie halbwegs SELECT, INSERT und UPDATE verstanden haben. Die meisten haben aber das relationale Datenbankmodell nicht kapiert, und es fehlt meist auch am Grundlagenwissen. Wie zum Beispiel was eine Normalisierung ist und wieso man das macht und wie viele "Normalformen" es überhaupt so gibt, und warum man in der Praxis meist nicht komplett durchnormalisiert.
Case in Point: Das Datenbankschema von OTRS, einem Trouble Ticket System:
http://ftp.otrs.org/pub/otrs/misc/otrs-2.2-database.pngTickets (das wichtigste sozusagen an einem Ticket-System) haben eine numerische ID (bigint). Die wird aber nicht nach außen gegeben, die haben noch eine zusätzliche interne ID die als "tn varchar(50)" definiert ist. Natürlich haben solche Tickets auch einen Customer und einen "Customer User". Die werden abgespeichert in den Tabellen customer und customer_user, aber im Ticket nicht über deren numerische id (die in den Tabellen existiert!) referenziert, sondern über: "customer_id varchar(150)" und "customer_user_id varchar(250)".
Da kann man sich auch nicht mehr wundern das die Tabelle "customer_company" an "customer_user" hängt und über das Feld "customer_id" verknüpft ist. In der einen Tabelle als "varchar(100)" definiert, in der anderen als "varchar(200)".
