Simplifies SQL-style Computations -Relational Computation on Groups

During developing database applications, we are often faced with complicated SQL-style computations like relational computation on multilayered groups. As SQL requires summarizing during data grouping and it doesnât support object-style relational access, it is difficult to deal with these computations. We have to resort to an advanced technique of window functions nested with multilayered subqueries. esProc, however, can handle them more easily by supporting real grouping and visual object-style relational access.

In practice, there are a lot of cases in which relational computation on groups is needed, such as the one presented on the website http://forums.bit-tech.net/showthread.php?t=207052. Based on this practical example, we have designed a more common one for illustrating in detail how esProc works to realize the relational computation on groups.

Computing target: Query branches of a DVD store where there are less than four categories of DVD copies.

Data Structureï¼Branch Table stores information of the branch stores. DVD Table stores titles and categories of DVDs, in which DVDs, like Transformers IV, are virtual data items instead of physical disks. DVDCopy Table stores physical DVD copies branch stores have. Note: DVDCopy Table is related to Branch Table through BranchID field, and to DVD Table through DVDID field. The following is part of the data:

Descriptionï¼

1. Computed results should be certain records in Branch Table.

2. That the Status field of a record in DVDCopy shows Miss means the DVD is missing, and that a recordâs LastDateReturned field is empty means the DVD has been rented out but not returned. Obviously the DVDs that are missing and havenât been returned are outside of our computing objects and should be filtered away.

3. We should consider the situation that there may be certain branch stores whose information isnât included in DVDCopy Table, though it is rarely seen.

Solution:

1. Select valid, existing DVD copies the branch stores have from DVDCopy Table.

2. Group DVDCopy Table by BID. Each group will contain all DVD copies a branch store has.

3. Select the DVDs corresponding to the DVD copies each branch store has, and compute the number of categories to which these DVDs belong.

4. Select branch stores where the number of categories of existing DVDs is less than four. These branch stores are eligible.

5. Select branch stores which DVDCopy Table hasnât. They are also eligible.

6. Combine the two kinds of eligible branch stores.

Now we can perform object-style relational access only with the operator â.â. For instance, DVDCopy.(DVDID). (Category) represents the category of each DVD copy, and DVDCopy.(BID) gets the detailed information (complete record) about the branch store corresponding to each DVD copy.

It can be seen that group function only groups data, but doesnât summarize the data at the same time. In this point, it is different from the function for grouping in SQL. Sometimes, we need to further process the grouped data, rather than simply summarizing them. To do this, esProcâs group function is more convenient to use, as shown in the code in A7:

A7ï¼=A6.new( ~.BID:BonList, ~.(DVDID).id(Category).count():CatCount )

That is, branch store B002 has three categories of DVD copies, B003 also has three categories and B001 has four categories.

The above branch stores that are in short supply are computed according to DVDCopy Table. But maybe some branch stores with serious supply shortage are not in the DVDCopy, such as the cases that all the DVD copies in the branch store has been rented out, or that the branch store hasnât any DVD copies. So these branch stores should also be counted. The code for this step is as follows:

A9ï¼=A8.(BonList) | (Branch \ A7.(BonList))

Or we can realize the computation indirectly. For instance, first compute âbranch stores that are not in short supplyâ, and then compute the complement of the result and Branch Table. The final result should be the same as that of A9.

Please note variables like A8 or Branch cannot be used to represent a data set in SQL because it doesnât support explicit set. Thus the simple code in the above have to be replaced by lines of complicated SQL statements.