Re: Dreaming About Redesigning SQL

Bob Badour wrote:

> "Lauri Pietarinen" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>  
>
> > Bob Badour wrote:
> >
> >    
> >
> > > "Lauri Pietarinen" <[EMAIL PROTECTED]> wrote in message
> > > news:[EMAIL PROTECTED]
> > >
> > >      
> > >
> > > > So my guess why many programmers dislike SQL (and hence, databases) is
> > > > that they have to deal with two different paradigms.
> > > >        
> > > If by "paradigm" you mean: "A set of assumptions, concepts, values, and
> > > practices that constitutes a way of viewing reality for the community
> > >      
> that
>  
>
> > > shares them, especially in an intellectual discipline"
> > > (http://dictionary.reference.com/search?q=paradigm), then I suggest we
> > > consider that programming and database management exist within a single
> > > paradigm of computing.
> > >
> > > SQL does not exist within a separate paradigm so much as it represents a
> > > different computational model.
> > >
> > >      
> > Well, however you want to call it. SQL (or relational) represents a
> > different way of thinking.
> >    
>
> In my experience, effective programming requires exactly the same way of
> thinking effective data management requires. For instance, to programme
> effectively, one must start from "What do I want the computer to do?" and
> then work toward "How do I get the computer to do it?"
Programmers that are taught to program (e.g. in universities) and know a 
lot of how to desing programs
and do concurrent stuff etc don't necessarily understand the relational 
approach.  They could be e.g. great
game programmers, but when they start doing "commercial typ" 
applications it takes some educating and
convincing that they understant how to merge Java with SQL so that each 
part does the job it knows
best.  They tend to design clean object oriented programs that just 
don't scale to larger environments
because they use the database just as a "dumb" data store.


> > > > e end up with
> > > > J2EE, where everyting becomes a bean of some kind and we hide simple
> > > > SQL in the beans without leveraging the power of the DB.  Guess what -
> > > > we get performance problems!!
> > > >
> > > > Or we end up with programmers building their own DBMS'es so as to at
> > > > least get an illusion of unification.
> > > >        
> > > Ignorance, laziness and stupidity cause far worse problems, but ignorance
> > > tends to mask the problems to those most affected.
> > >
> > >      
> > >
> > > > Now, the alternative COULD be to widen the domain of the DMBS.
> > > >        
> > > Instead of widening the dbms, consider applying the dbms's computational
> > > model to a wider scope of problems.
> > >
> > >      
> > Yes, thanks for clarifying.  That's what I meant.
> >    
>
> I observe that the ability to apply the dbms's computational model to a
> wider scope of problems suggests a single paradigm.
It's just two different appoaches to building applications.  At the 
moment we are stuck in a situation
where we have to live in two (slightly incompatible) worlds to get the 
job done.

The billion dollar question is:  could we get everything done in one 
world only, the relational one?


Lauri