Re: foundations of relational theory?
Date: 5 Nov 2003 17:06:33 -0800
Message-ID: <b6da8ff0.0311051706.3e048add_at_posting.google.com>
Well put Chandru. My feeling here is that SQL was originally designed
as a Data Extraction Tool (i.e. query language). SQL was really
nothing more than a 'APPLICATION' that then touched the database. SQL
was then extended to do updates and was extended to be a end-all data
access application. The nice thing about this model was that it
forced all data access to go thru this one app. Any of us that write
application understand the benefits of using a standardized module for
data access/update.
Data integrity then became an issue. Data contraints were added, then
triggers, etc. But I believe we (the industry) has finally realized
that this was the wrong direction and has moved towards the 3-tier
data model. In this model we do not allow the end user direct access
to the database. Instead we develop business modules that the user
calls. This model has the advantages of Forced Data Integrity, the
end user does not have to know our data model. Essentially it creates
customized mini-sql engines for our data objects. As I study this
In this arena Pick is well positioned to do well. Why? Because we have a well integrated data tool (pick basic) that functions just fine as the language for the Business Logic. Before windows, pick competed just fine because of it's ease of use and speed in this area. Only as windows grew in popularity and picks inability to easily integrate with SQL tools did pick start to decline. I am now writing Pick Business Logic modules that are returning XML Datasets to a Microsoft Visual Basic Front end.
- Patrick