Re: SQL

On 1 Feb 2006 19:14:42 -0800, topmind wrote:

> Dmitry A. Kazakov wrote:
>> On 31 Jan 2006 19:36:38 -0800, topmind wrote:
>>
>>> Relational normalization is
>>> driven pretty much by avoiding duplication (at least the first 3
>>> "laws"). OO tends to duplicate interface patterns such as add, change,
>>> delete, sort, etc. for each class. It does not factor similar "database
>>> verbs" into one spot, replicating them per class (with "creative"
>>> twists for each personality). And many-to-many in OO often results in
>>> two-way pointers.
>>
>> The difference is between one type and multiple types. Relational model
>> deals with *one* class: table. OO tries to handle more than one class.
>> Consider tables of types instead of tables of objects, and we'll see if
>> that will be any simpler.
> 
> I don't believe in "types" as a useful model, at least not for my
> domain.

That's up to you, but there is no any viable alternative. The point is that
the relational model is a particular case of more general typed model. Then
you aren't sincere. In SQL you are using types like integers, strings and
some others. If you didn't believe in them, then you should have replaced
them all with relations. Note that mathematically it is quite possible. Now
the question, why didn't you?

> If I was forced to be an OO'er, I would probably take Smalltalk
> or Python over Java or Eiffle.

They all are typed, as well as SQL. It is impossible to have a truly
untyped language. You might reduce it to a very narrow or singleton set of
types, but not further. There could only be well and poorly typed
languages.

>>>>> Yes, mass repetative verbose static Set/Get's.
>>>>
>>>> There are bad languages, which don't fully implement ADT. So?
>>>
>>> Converting attribute-driven interfaces into ADT's is still pretty much
>>> Set/Get.
>>
>> They implement attribute access. It is up to the language to provide
>> X.Attribute notation rather than nasty X.Get_Attribute. I don't see any
>> problem here.
> 
> For simple stuff it might be okay, but for more complicated stuff it
> turns into a Bachmanian navigational mess. For example, specifying
> many-to-many relationships.

Between what an what? Again, with one table type you have

   X."Attribute" or (X."A1" and X."A2" and X."A3" ...)


instead of

   X.Attribute or (X.A1 and X.A2 and X,A3 ...)

See what is different?

It is up to you to map things to types or to objects. There is no best
choice. In each concrete case the software designer shall reconsider it
anew.

>>>> What about inserting when no
>>>> row exists and updating otherwise?
>>>
>>> MySql has a command just for this.
>>
>> The advantage of ADT is that you can define that command and provide an
>> implementation for. SQL does not have proper ADT, otherwise people would do
>> higher-level programming directly in SQL. The methodology of higher-level
>> programming is OO.
> 
> I can write a function to do the same thing. However, function
> interfaces to such are often not as flexible as query-based interfaces.

How INSERT is different from user function? Why is it more flexible?

> Ideally the query language would be extendable if a DBA etc. wanted to
> add an operation to it. However, SQL's excessively complex syntax makes
> such very difficult. SQL has some weak spots, I will agree. However, no
> standard is perfect and the current alternatives are net uglier.

And the only good way to extend languages is by letting user to define
ADTs! [ In 60-70s there was a lot of extendable languages in the sense of
syntax-extensible. They all are gone, because programs were unreadable and
unmaintainable. ]

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
.

Relevant Pages

  • Re: SQL
    ... custom biz app setting. ... Put a program code in a relational table and write compiler in SQL ... SQL is one of an infinite possible relational languages. ... how would making each pixel an ADT or Object improve the picture ...
    (comp.object)
  • Re: Database Model - Class, objects and interaction [LONG]
    ... Be aware that we are talking about the relational model, ... We all know that the type system in most SQL ... only specific vendors or specific languages. ... "limits" are not necessarily a bad thing. ...
    (comp.object)
  • Re: SQL
    ... SQL is a specific language with certain ... relational nor query languages. ... which don't fully implement ADT. ... interfaces to such are often not as flexible as query-based interfaces. ...
    (comp.object)
  • Re: Is there a mainframe skills shortage?
    ... That's because the author of the article is comparing it to standard SQL. ... and material around Lamdas and functional programming. ... obvious which languages were the ones to learn. ... stick to writing system software and leave applications to the COBOL ...
    (comp.lang.cobol)
  • Re: SQL
    ... SQL is more or less based on "COBOL thinking". ... If you add X with one constraint to Y with other constraint and what would ... RDBMS exist only because in 70s there were no languages capable to provide ... The biggest problem I see with it is that different app languages are ...
    (comp.object)