In building my latest database, I faced the following design problem. The system will have three types of loans that are (for all practical purposes) identical and differ only how there transaction will be processed afterwrods. I was tempted to build a single Loan table and derive three views that will handle the three different types of loans. Then it struc me that LLBL would generate a TypedView class (instead of an entity class) from each of the three views. I have two options: 1- derive three entity classes from the Loan entity class 2- build three different loan tables

Although the first option sounds valid, I couldn't help thinking that LLBL should be able to build an entity class out of single-table views. If Ms-SQL (I don't know about the others) treets these kind of views differently (they don't have the normal limitations you would normally have with multi-table views) why wouldn't LLB do the same?

What do you think Frans

OMAR

Omar,

I have a lot of table structures that are similar, I simply foreign key a field to a 'Type' table. i.e. I have a Comments table with a CommentTypeID field that is foreign keyed to the CommentType table, then in my business layer I create retrieve and proccess methods that use predefined predicates to pull only back the specific set of comment types in my lists.

If you need to pull back multiple types as different fields in a TypedList just create it in your business layer joining the same table with alias's skipping the designer, is what I do.

This works great, keeps my data normalized etc.

Hope that helps =) John

read-only entities based on views are planned for the end of january (and writable on some databases, if they support view writing (sqlserver/oracle/db2)