Try OpenEdge Now
skip to main content
Advanced Read Operations : ProDataSets as a data access layer : Defining the right top-level table for a ProDataSet

Defining the right top-level table for a ProDataSet

In many simplified examples that use the Sports2000 database, we show one or more Customers and the Customer's Orders. Would Customer-Order-OrderLine then be a good basis for a ProDataSet? To answer this, ask yourself another question: Do you think of all of a Customer's Orders as being a part of the Customer object itself? Probably not. You might want to represent or work with a Customer object and its Order objects at the same time, but this does not mean that you should combine them into a single ProDataSet or think of them as a single business entity.
In a real database, a customer or client is typically represented by data in several tables. There might be a Customer header table, one or more addresses from an Address table, one or more contacts from a Contacts table, and so on. This is probably the right set of tables to combine in a Customer ProDataSet.