dbms/rdbms software & its environment
From: mountain man <hobbit_at_southern_seaweed.com.op>
Date: Wed, 29 Oct 2003 05:24:09 GMT
Message-ID: <Z9Inb.169368$bo1.106498_at_news-server.bigpond.net.au>
There have been a few astute posts here and there to the effect that notwithstanding the benefit of the development of "the relational model" for databases, for the last 20 years database theory (a la Date for example) has remained database centric in its thinking.
Date: Wed, 29 Oct 2003 05:24:09 GMT
Message-ID: <Z9Inb.169368$bo1.106498_at_news-server.bigpond.net.au>
There have been a few astute posts here and there to the effect that notwithstanding the benefit of the development of "the relational model" for databases, for the last 20 years database theory (a la Date for example) has remained database centric in its thinking.
Finally three questions:
- To what extent is "an environment external to the database" referenced within database theory?
- What extent of the user interface in any general database
application software system and supporting dbms/rdbms
(or depending on how your view it ... in any general
dbms/rdbms software and supporting application software
system) is external to the dbms/rdbms, and what is internal?
- In the above, "internal" means literally defined with the dbms/rdbms software as sql or contraints or triggers or indexation management etc. Considering this definition
are there any examples of solutions in today's world
whereby database application software systems are
functioning close to 100% within the dbms/rdbms environment
rather than distributed on the clients, or application servers?
(ie: they are defined close to totally within the dbms/rdbms env)
Thanks for your consideration of the above three questions and any comments on the fairness of the opening comment.
Farmer Brown
Falls Creek
OZ
www.mountainman.com.au/music
Q: What is a djembe?
A: An African drum.
Received on Wed Oct 29 2003 - 06:24:09 CET