Re: Unknown SQL

>Better example would be a customer who wants to customise my
>application. Indeed, every merchant on the web wants different look and
>feel. In ideal world they buy ecommerce application and then do
>something like:

I would suggest that the solution to this lies in how you implement your application rather than how you manage your data.

>>>No matter now badly my application is written, the request is so
 simple so
 that
>>>it could be easily formulated in SQL. Some people like Peter Douglass
 from
>>>comp.object already expressed an idea of having general purpose
 relational
>>>engine within programming environment. Until then, however, the best Ican
 do is
>>>to navigate ala STL in 3GL language.
>>
>>
>>Or are you saying you would like a programming language with the
 functional
>>and declarative expressibility of a relational database language? I would
>>too.
>>
>>I would also like one of those that is well integrated with my DBMS,but I
>>still would not confuse the programming language with the DBMS. I would
 

>>still let the DBMS manage my data and would write my applications in the
>>programming language.
>
>You also want to raise abstraction above 3GL languages, right? Then, why
>are you trying to put arbitrary boundary where the scope of relational
>engine ends?

How am I doing that? I am placing a boundary on where the scope of the database management system ends, because a natural and extremely useful boundary already exists.

This in no way prevents an application programming language from understanding relations or from manipulating its own relation variables directly.

>Or you don't think it's possible? But, wait, we already
>have poor man declarative programming like functional programming or STL
>and DBC in 3GL. Who might envision anything as elegant as like STL was
>even possible for goofy C++?

Just about every C++ programmer I ever met. The language is ideally suited to a standard library.

>BTW, one quote I found relevant to the flame war:
>
>>>>> begin
>
>The key to STL is the notion of iterators, which are generalized
>pointers that provide a glue for connecting algorithms and data
>structures. STL is indeed retrograde in its disregard of the current
>academic dogma suggesting that pointers are evil. Instead of hiding
>pointers behind value semantics, it makes them the corner-stone of the
>design. The decision to bring pointers back into the realm of
>respectability was based on a simple fact: Most things in programming
>resemble pointers in that they identify a location of data. For
>instance, Internet addresses, SCSI addresses, and file descriptors all
>function as pointers
>
><<<< end

What is appropriate for a programming language need not be appropriate for a database management system. An application programming language need never worry about the consequences of pointers outside of an application. The DBMS has no such freedom.

On the other hand, many, if not most, uses of iterators are better handled with set-level operators. Received on Sun Jul 22 2001 - 01:29:10 CEST