Re: theory and practice: ying and yang

mountain man wrote:

> "Paul" <paul_at_test.com> wrote in message
> news:429bad41$0$2349$ed2619ec_at_ptn-nntp-reader02.plus.net...

>> mountain man wrote:
>>>>Do you have a concrete example of a simple stored procedure, and how
>>>>you'd want this to be handled by your ideal DBMS?
>>>
>>> My claim is that the entire application software environment
>>> can be reduced to a series of stored procedures.  Here is
>>> the classic example, for the Northwind Trading Company:
>>> http://www.mountainman.com.au/software/southwind/
>>>
>>> In this example, we have a database (southwind) containing
>>> a series of stored procedures which act as the application
>>> software components for the Northwind data.
>>>
>>> In this arrangement both the data and *all* programs (ie: apps)
>>> can be confined to the environment of the database system.
>>
>> OK, but the stored procedure *are* stored within the DBMS, so doesn't
>> this contradict your claim that the relational model can't handle the
>> stored procedures?

>> Isn't what you've done standard practice in designing enterprise
>> database reporting systems? i.e. to have a stored procedure (or in an
>> ideal world, a view) for each report?

>> Are you saying that this method is preferrable to the "fat client" or
>> "middleware" method, where you have business logic held outside the
>> database in things like Cognos, Business Objects, or Crystal Reports? I
>> thought this was pretty much the same as most other people think.

>> Is the point you're making that the procedural language used in stored
>> proecedures isn't part of the relational model?

>> In which case all the
>> stored procedures you have could be replaced with views, which are part
>> of the relational model. This approach would only break down for the
>> cases I mentioned before i.e. when you have several data manipulation
>> statements in a single transaction. But I don't see any of these cases
>> in your example application.

Pete, I enjoy these discussions, but here I think you risk straying into dogma. Let me explain.

You seem to begin with the same contention that I do in my own systems, which I state as "The db server must implement all business rules at all times". You do it with sprocs, I use dictionary-generated triggers, but the goal is the same. The bottom line is that the server can in fact implement all business rules, and the arguments are all about implementation.

You then proceed to the claim that the UI can "ride" the table structures and provide complete workability. That at least is how I term that kind of UI, which our system also implements. In this system, the menu lists tables. You work on data in tables, and on the detail screen for each table are hyperlinks to drill down (or up) to child (or parent) tables, with appropriate intelligence making the results of those drill down/ups useful to the user.

BUT, you cannot then conclude that this is the "One true UI". This is where I detect a drift into dogma. My appeal would be that, once the biz rules have been successfully implemented, you have discharged your responsibility for data correctness and completeness, and must now accomodate human quirks and foibles. So for instance, when people make schedules, they like pictures of calendars. When they peruse real estate listings they like pictures of houses. And while the flat array display is always *correct*, it is not always *appealing*. A key point here is that appealing=nice demo=sales.

Am I mis-characterizing your position? Have I missed something?

-- 
Kenneth Downs
Secure Data Software, Inc.
(Ken)nneth_at_(Sec)ure(Dat)a(.com)