Re: SQL
Dmitry A. Kazakov wrote:
> On 31 Jan 2006 19:36:38 -0800, topmind wrote:
>
> > Dmitry A. Kazakov wrote:
>
> >> There are many clean and consistent things, which lead to a total mess when
> >> used inappropriately. DB applications represent an excellent example.
> >
> > True, but OO has no consistent "right way".
>
> As well as programming in general.
Well, I find a lot more consistency between schemas than between code
of different shops. I'll usually take messy schemas over messy code.
>
> > 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. If I was forced to be an OO'er, I would probably take Smalltalk
or Python over Java or Eiffle.
>
> >>> 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.
>
> >> 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.
And, not sharable across languages.
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.
>
> >>>>>> Similarly, just because different object-oriented programming languages
> >>>>>> may have problemsinteroperating with each other's objects, isn't a failing
> >>>>>> of object-orientation.
> >>>>>
> >>>>> Non-OOP protocols are usually easier to share.
> >>>>
> >>>> True, when they are low-level.
> >>>
> >>> I disagree. Please justify.
> >>
> >> Consider machine code as a protocol. Why would you like to have any
> >> programming language instead?
> >
> > I don't know what you are implying. Perhaps an example would help.
>
> Isn't machine code a simple communication protocol to CPU? You send the
> code of MOV and CPU does that. Simple? Can you handle it without a
> compiler? Protocol must match the complexity of what you want to tell to
> the receiver. Simplicity alone isn't an advantage.
I still don't see how this relates to the topic at hand.
>
> --
> Regards,
> Dmitry A. Kazakov
-T-
.
