Re: theory and practice: ying and yang

mountain man wrote:
> My thesis is that if you take this migration to its logical
> conclusion there may be achievable an optimal stage in which *all*
> application software in internal to the DBMS in the form of stored
> procedures.
>
> That is precisely what this tool does. It enables a service level
> portal to the RDBMS for the user which is based solely on the
> execution of stored procedures, and the ability to handle the
> consequent sets of data being returned to the user.

I think this may be confusing two separate advantages of having a centralised system. The first advantage is to be able to enforce data integrity constraints centrally. The second is to have managerial control over all parts of the system.

Having business logic in the form of stored procedures offers no advantage (with respect to data integrity) over having the business logic held externally, if both are managed by the same person.

The advantage would come if the DBMS would somehow ensure the integrity of the stored procedures. For example, if you tried to drop a row from a table, it might refuse to let you if there existed stored procedures referencing that column. Or if you rename a column it might update all stored procedures that use it. Maybe some DBMSs do this kind of thing already; I'm not sure. But you've still got the problem of ensuring that the logic is semantically correct as well as syntactically.

Now your system does offer an advantage in the second way; that updates to clients don't need to be installed on all users' machines - they just use the generic client. But this is more of a management issue than a data modelling issue.

I guess the contents of stored procedures aren't considered as "data" in the same way as tables are because there's no real way of the DBMS telling if they are right or wrong other than some basic syntax checking. Actually here's somewhere that views may be superior to stored procedures. Maybe you have something in a report that should always be zero or more (items in stock for example). With a view you could have a constraint on the relevant column of the view, if your DBMS supports it. Of course, you could have a corresponding and equivalent constraint just involving base tables, but this might be a lot more complicated to write and understand.

Here's a thought, building on your idea: design a client, maybe as an executable, or as HTML or somthing. Then store this in the database, either in a binary column or in some more structured way. Now you only have to give your users a minimal "bootstrapping" client that first downloads the "real" client from the database and runs it. Now you can have an arbitrarily complex client and it's all stored in the database!

In a way this is how web clients work: the code is supplied from the central data store (in this case a web server, but in theory it could have a database backend) and downloaded by the clients, who then use it.

Paul. Received on Fri Jun 03 2005 - 16:17:22 CEST