A related, perhaps overlapping, issue is the use of stored procedures in the generation of business objects/data access layer. I, conceptually at least, favor the satisfying of all joins required to populate a given business object in the database via stored procedures. To use MM Business Layer Generator it is necessary to specify an entire set of CRUD procedures (sometimes using a dummy procedure for all cases where a db modification will not actually occur). One can end up with some strange default 'table' names - the Business Layer Generator uses the name of the sproc as the default name of the 'primary' table. But once donem, you can just change the name in the busines object properties.

The related, perhaps overlapping, I referred to is that, in this manner one can better map the data provision of a business object to the needs of the UI or application - as opposed to the granularity of the database schema. Since stored procedures are used, the business object and any dependent objects can remain impervious to tables, foreign keys, etc. I think, hope and I'm about to find out, the MM Framework can also remain impervious to these issues as long as the appropriate stored procedures are provided and specified for saving results - though the notion of housekeeping PK may require some creativity similar to that of providing a table name that makes sense.

There is also the VS 2005 Data Soruce support for specifying datasets with multiple tables and, if necessary, relationships. I hope Kevin is looking at that.