Zum Datenmodell noch einige Anmerkungen:
Feldnamen in einheitlicher Sprache, Englisch ist quasi Standard
Bei Feldnamen einer einheitlichen Nameskonvention für Schlüsselfelder, Flags, Logikattributen folgen
Primärschlüssel wie schon genannt als Zahlwert, Namen (änderbar) als separates Feld, ebenfalls unique
Tabellen und Feldbezeichnungen möglichst passend, aber allgemein wählen. Spätestens wenn die Leute auch Snickers und Twix bestellen, ist Getränkename unglücklich gewählt, also z.B. Tabelle "Produkt", Feld "Name"
Schlüsselwerte am besten für alle Tabellen über eine zentrale Sequenz erzeugen.
Datenmodel-Constraints (unique, not null, ref constraints, ..) möglichst eng fassen und bei Bedarf lockern oder Ausnahmen definieren.
Cascading Constraints mit Vorsicht (oder gar nicht einsetzen), bwahrt Entwickler/Anwender vor Datenverlust.
16:
Ich hoffe, es werden nicht 16 Buttons!
Man braucht viele z.B. 27 Buttons für die Buchstaben einer virtuellen Tastatur, 10 für die Ziffern des Nummernblocks usw., aber nicht für verschiedene User. Bitte diese Zahl vergessen - auch wenn sie eine Marke für die "Dimension" des Projekts ist!
In dem Moment, wo man in solchen Kategorien denkt, geht das Design (des Datenmodells oder der
GUI/der Logik) leicht in die Hose.