About the foreign keys, you CAN have real foreign keys in MySQL as of the time they started including innodb tables.
What I'd like is an "innodb only" version of MySQL that couldn't use any other type of table to enforce data integrity on a system. Or some way to deny users the rights to make the older myisam tables.
Whether or not fks are useful is up to you to decide based on what you're doing with your database.
If you're running a banking system, you'll likely have fks. If you're doing a system to keep track of bingo scores, probably not.
The primary advantage to REAL fk implementation is the ability to cascade your deletes, so that you can setup the table to behave differently for each situation where an fk would go away.
you can have it so that the children are deleted when the parent is deleted, and, with triggers, so that when the last child is deleted the parent record is too.
If they're the same type, and common sense says they should be, and properly indexed, then retreival should be much faster than sequentially scanning, so the tendency of pk/fks to need an index usually helps performance as well.
Lastly, if you can get firebird / ibphoenix or postgresql running, do so. They are infinitely better databases when it comes to the features that seperate a storage system from a database.
MySQL is getting there, but the other two are still better choices. Development on SAP DB is about nil, by the way, so unless it does exactly what you want now and you'll never need a feature, you'd probably be better served by pgsql or ib, both of which have active development and support communities.
