Re: theory and practice: ying and yang

"Paul" <paul_at_test.com> wrote:

> A DBMS is very good at extracting data in a fixed-column tabular form,
> but this is all about presenting that data in formats that don't fit
> that template. I'd argue that that job is much better done by a client
> tool.

At the end of the day, that the job is done may be sufficient.

However in the following I have outlined some of considerations of "schema evolution" (ie: change management) that are relevant to the (often hidden) ongoing job of maintaining the arrangement of a client tool environment.

Supposing you have to maintain 23,337 client tools and a large volatile database. To be specific, assume you have to maintain an enormous number (n) of ...

P1, P2, P3, ., Pn (where P = component stored procedures)
S1, S2, S3, ., Sn (S = server side application components)
C1, C2, C3, ., Cn (C = client side application components)

Let us further assume that the components have been extremely well written in such a manner that internally, each set Pn, Sn and Cn are redundant free.

Given the above component objects, for the application suite to be cohesive there must exist physical coordination tasks in place, whereby each of the component sets Pn, Sn and Cn are defined to one another, and to the data.

The following two-way excessive and high-level cost incurring  tasks of coordination CTn are constantly required in order that integrity of the suite is preserved:

CT1 between Cn (C1, C2, C3, ., Cn) and Sn (S1,S2,S3,.,Sn) ie: between the client and server sides of application suite componentry.

CT2 between Cn (C1, C2, C3, ., Cn) and Pn (P1,P2,P3,.,Pn) ie: between the client application suite and RDBMS stored procedure componentry.

CT3 between Sn (S1, S2, S3, ., Sn) and Pn (P1,P2,P3,.,Pn) ie: between the server application suite and RDBMS stored procedure objects

CT4 between Cn (C1, C2, C3, ., Cn) and the database. ie: between the client application suite and database schema

CT5 between Sn (S1, S2, S3, ., Sn) and the database. ie: between the server application suite and database schema

CT6 between Pn (P1, P2, P3, ., Pn) and the database. ie: between the RDBMS stored procedure objects and database schema

There exists a mandatory implication that wherever a change is made at one place, then that change must be communicated to other components in the suite. For example, if the database schema is altered to allow another column in one table, all above 6 tasks are required.

The size of these six coordination tasks of course is proportional to the number of component objects being coordinated. When the size is large, as is the case with most comprehensive applications, then the coordination tasks in change management are excessively highly detailed.

Certainly, there have of course evolved automation tasks and functionality products to assist in these administrative and management tasks. But these tasks require establishment and continual calibration, and only serve to hide the undercurrent of thrashing about outlined above.

Now, if you were able to use only SQL to deliver application software functionality, the coordination tasks CT1 through CT5 no longer exist. There is only one cordination task CT6.

Other benefits include performance, seeing as though both the "programs" and the data are together in the RDBMS. Received on Wed Jun 08 2005 - 04:49:18 CEST