Questions & Answers

• What about this platform that makes the development cycle faster?

• For every RAD product there is a point of application complexity and/or requirement distinctiveness at which the benefit of the approach is no longer valid.

• How are this product's stored procedures any more "optimized" than the SP's developed by one of our DBA's?

• You write that DB3NF and the Session Server are fast. How fast? Can you provide any benchmarks?

What about this platform that makes the development cycle faster?

The table below illustrates the difference in design process between DB3NF and the traditional approach. It virtually eliminates the need in database and component design and reduces the time needed to design ASP pages since most of the needed functionality is encapsulated into DB3NF component. The bigger the application, the more time savings there will be. Most ASP pages are generic so when one page is designed, chances are it will be re-used with minor changes in many places throughout the application.

Most of the code in DB3NF is either automatically generated or is inside of the component. This code is extensively tested and works reliably. The code that needs to be added on top of DB3NF is very short and simple - there are not many options to make an error, therefore the QA process is dramatically reduced.

These time savings are not theoretical, but achieved in various implementations of DB3NF.

For every RAD product there is a point of application complexity and/or requirement distinctiveness at which the benefit of the approach is no longer valid. What is the "point of no return" for this product?

a) Application complexity. From the design and implementation perspective, there is hardly anything as simple as DB3NF once the "learning curve" is completed. DB3NF makes even the simplest applications simpler. With more complex applications the benefits of DB3NF are more evident.

b) Distinctiveness. DB3NF is transaction oriented. It does well such tasks as user registration and management, purchase orders, managing different types of accounts, catalog browsing, etc. It does not do well complex queries or reports. From our experience, we had to add custom procedures for such reports as a select of investment vehicles with returns most correlated with a benchmark. Another example of a report where the native DB3NF methods are not most effective would be a select of users who often visited the site last year, but haven't been to the site in the last month. For such tasks there are generic methods in the Database class that execute custom SQL statements or stored procedures. If needed, custom objects can be added to the "data" database and custom components created to work with them and/or with native DB3NF tables and procedures. In short, DB3NF native elements can be used whenever it is appropriate (in most cases, it will cover 3/4 of the application) while the rest of the application can be done with traditional methods. There is not a single obstacle to use DB3NF and traditional methods together.

How are this product's stored procedures any more "optimized" than the SP's developed by one of our DBA's?

There is nothing in DB3NF that humans cannot do as well or even in some cases better. That's in theory. In practice, where there are more than 50 tables in the database, it becomes very hard and expensive to maintain the perfect state of the database design. People do make errors and with complex application many people are involved in the design and some of them have lesser skills then the others. One example:

Suppose there is a column "Number of dependents" in a Social Security application. What are the chances that the designers will add a check constraint in the database [Number of dependents]>=0 and [Number of dependents]<100? Or how often the real world DBA's write explicit index hints? Have they never forgotten to add a useful index or never accidentally dropped one?

DB3NF will never "forget" to add them. In a world where there are no budget limitations and developers are all experts and don't get bored of writing the same code over and over again there is no need in DB3NF. In the real world, DB3NF makes applications better, faster and reduces design costs.

You write that DB3NF and the Session Server are fast. How fast? Can you provide any benchmarks?

Application performance of course depends on the hardware. On a single processor average server DB3NF performance ranges in most cases from 10 ms to 40 ms per page depending on the code. It means that the server can reliably serve up to 50 pages a second or 1,500,000 pages a day (assuming good performance during busy hours).

The Session Server round-trip time depends on the session data size. If session data is less than a few KB, the round-trip time is about 10 ms.