- Software Extensibility
- How Do We Call It?
- IDS 9.x Object-Relational Features
- Usage Examples
- A New Approach to Problem Solving
- What's Next?
This chapter is from the book
This chapter is from the book
This chapter is from the book
A New Approach to Problem Solving
As I mentioned earlier, there is a tendency to apply the relational limitations to designs that are implemented using IDS 9.x. I believe that the preceding area management example is a great example of this issue. How can we go beyond this problem? Reading the rest of this book will certainly help break the relational mold. The other step is to start looking at the characteristics of relational-type databases and IDS 9.x features.
Over the last several years, we have heard a lot about patterns. Suddenly everything had patterns: analysis, design, implementation, programming, and so on. What about relational databases? The major relational patterns revolve around the ability to provide set processing and the nonprocedural user interface (SQL). The capabilities include grouping, sorting, applying conditions, and so on. The most efficient use of extensibility is to add functionality that enables the set processing instead of doing it "stored procedure style" and postprocessing the data, doing your own set processing.
Instead of thinking about how to process the information to get to the answer, you must think in terms of how you define the sets that SQL could process. If the processing is not available in SQL, you can also add it to the database server. This is easier said than done because every programming language is basically procedural. This includes object-oriented languages because the approach is always to process one object at a time, looping on collections of objects. As far as I know, the only language that provides set processing is APL (it is rumored to have had a role in the creation of the relational model).
Here is a very simple example to illustrate this approach: Let's assume you need to provide the total revenue generated for each product on a quarterly basis for an entire year. You cannot do it through SQL directly. A first approach is to submit four SQL statements to get the answers. Then sort the results to provide the result per product and quarter instead of per quarter and product.
A second approach would be to do it all in a stored procedure. This could become difficult because of the final sorting. The stored procedure may require submitting four SQL statements per product.
A third approach, more set oriented, would be to use a table that identifies the quarter for each available date. This requires joining to this table and making sure that there were no omissions of dates, which could be difficult to detect.
Thinking in terms of the strength of relational databases, the solution becomes to tell the database how to sort the data, in this case, providing a function that provides a more efficient solution than the third approach. Assuming that function is called quarter(), you could submit the following statement that covers the year 2000:
SELECT product, quarter(order_date), SUM(amount) FROM orders WHERE order_date BETWEEN '01/01/2000' AND '12/31/2000' GROUP BY 1, 2 ORDER BY 1, 2;
The quarter() function is very simple because it only knows how to take a date and return a value representing the quarter. There is no complex processing here and no awareness of set processing. The result could be a character string such as 2000Q1 or an integer like 20001. Both representations allow the database to sort the data in the right order. In this example, we assumed that the business year started on January 1. Of course, this covers only a fraction of businesses. The fact that the year is provided in the result allows us to have a different business year than calendar year and also provides the information when multiple years are covered in an SQL statement.
When comparing this last solution to any other, we see that it is the simplest and the one that provides the best performance. It does not require the joining of tables, the execution of multiple SQL statements, or the transfer of a large amount of data to a client application. So, when solving a problem, always ask yourself: "How can I take advantage of the strength of the relational model to solve my problem?"