Release 10.1A: OpenEdge Development:
ProDataSets

> ## Defining the right granularity for your ProDataSets

> A ProDataSet can represent one or more tables (and any external data structure that can be mapped to it). Often, of course, a single object or document in your application has a complex structure that requires multiple levels of master-detail relationships. This is what the multiple tables of a ProDataSet can be used for.

> What then is the right size for your ProDataSets?

> There is no single right answer to this question, but if you think of your ProDataSets as representing business objects or documents your application manages, then you should be able to define the right scope for them. Even with such a simplified database as the Progress Sports2000 database that we have been using to illustrate the use of the ProDataSet, you can identify some combinations of tables that can properly be thought of as single business objects and some that probably can’t.

> For example, an `Order` is a common object in many applications. Generally, an `Order` has a header record. This is likely the right choice for the top level of an `Order` ProDataSet. The `OrderLines` for an `Order` can then be a separate table in the same ProDataSet, if you think of the `OrderLines` as being a part of the `Order`.

> Are the `Item` records then also a part of the `Order`? Well, probably not, even though we have added an `Item` temp-table to the `Order` ProDataSet in these examples so that we can demonstrate certain things about how ProDataSets work. The `Item` identifier is a part of each `OrderLine`, but the `Item` list or catalog itself is really independent of any particular `Order`. You might decide that having a separate temp-table in an `Order` ProDataSet that lets you pull in `Item` detail information for all the `Items` used in a particular `Order` is a useful way to represent the data, as we have done in some of these examples. This is perfectly legitimate if it suits your purposes, but that is different from how you think of the `Item` catalog as a whole.

> In this situation, ProDataSets let you define multiple levels of granularity and then combine them as you need to. For example, you can define an `Item` temp-table `ttItem` and an `Item` ProDataSet `dsItem` to represent `Items` as objects in their own right. You could use this ProDataSet to present a list of all `Items` or all `Items` that satisfy some selection. Having a ProDataSet that contains just one table is perfectly reasonable. Even though there are no relations within the ProDataSet, the ProDataSet structure still provides services for you to manage the `Items`. For example, it could provide a common internal definition for the `ttItem` table and perhaps common `FILL` logic to map the external `Items` onto the internal temp-table, as shown in Figure 9–1.

> Figure 9–1: ProDataSets and data granularity

> In Figure 9–1, `itemSource.p` represents a procedure that manages the Data-Source and `FILL` logic for the `ttItem` table. This is the kind of procedure we’ll use to build a simple example later in this section.

> You could then use this same `ttItem` temp-table and any of its logic as part of a larger ProDataSet, such as an `Order` ProDataSet that wants to present `Items` used in the `Order`, as shown in Figure 9–2.

> Figure 9–2: Reusing temp-table buffers

> Note that while you can’t actually make a ProDataSet such as `dsItem` a part of another ProDataSet, you can make its temp-tables part of another ProDataSet such as `dsOrder` by using a different buffer for the temp-table. Because the `SET-CALLBACK-PROCEDURE` mechanism lets you associate event procedures in any running procedure with a ProDataSet event, you can combine logic from multiple support procedures in a single ProDataSet.

Copyright © 2005 Progress Software Corporation www.progress.com Voice: (781) 280-4000 Fax: (781) 280-4095