Re: SQL
Dmitry A. Kazakov wrote:
> On 29 Jan 2006 12:11:41 -0800, topmind wrote:
>
> > Dmitry A. Kazakov wrote:
> >> On 28 Jan 2006 22:58:08 -0800, topmind wrote:
> >>
> >>> Christian Brunschen wrote:
> >>
> >>> But data is more "mathable" than behavior in this point in history
> >>
> >> This deserves an explanation, why do you think so. It seems obviously
> >> wrong. Mathematics deals with categories such as rings, fields, graphs,
> >> topos etc and studies their behavior. It has very little to do with
> >> processing data.
> >
> > The practical techniques for managing data are further along.
> > Techniques such as relational normalization, ACID transaction handling,
> > change-logs, triggers, etc. are fairly consistent, clean, and
> > well-understood for DBMS.
>
> 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". 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.
> OK, I
> don't want to blame biz-people, let's take another example, many numeric
> applications are just nightmare with respect of coding standards.
>
> Anyway, the point about mathematics was wrong.
I meant relational itself, not the domain of math.
>
> >>>>>In fact, DB tables are more sharable across languages than objects.
> >>>>>Thus, by that criteria they are more generic.
> >>>>
> >>>> ... but only for storage of and sharing data. If you want to do more than
> >>>> that, the database is simply not sufficient.
> >>>
> >>> Perhaps, but OO is no improvement over other approaches. Plus, many
> >>> things that OO calls "behavior" can be *turned* into attributes if one
> >>> knows how.
> >>
> >> This is an argument to Turing completeness, so it is irrelevant, because a
> >> finer measure than equivalence is required here to judge. What you call
> >> tables can be converted to "behavior", and everybody knows how.
> >
> > 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.
> What about
> obtaining the ID of a newly added row in SQL?
There are vendor-specific solutions. I agree there is a standards
problem in this arena, but no standard is perfect, and an incomplete
standard is often better than no standard. (It is mostly something to
address as the ODBC or equiv level, not SQL.)
> What about inserting when no
> row exists and updating otherwise?
MySql has a command just for this.
> Is relational data concept responsible
> for these faults of SQL design?
Since there are vendor-specific solutions for each of these, obviously
solutions are possible. SQL and existing RDBs are not perfect, I will
fully agree. But like Church-codd-hill said, the non-relational
alternatives are worse. (I am all for a new query language to replace
SQL, or at least fix up SQL.)
>
> > Again, we need to make a
> > distinction between "possible" and "practical". Being possible to write
> > any app in assembler may prove a point about possibilities, for
> > example, but says nothing about the practicality of such.
>
> Here we agree! It is just impracticable to delegate everything to SQL. So
> people are creating OO front-ends.
Relational partly aside, I don't think OO is necessarily the best way
to build front-ends. But, that is perhaps another debate for another
time.
Again, I never claimed that RDBS and query languages should be the
whole kitten kabootal.
>
> >>>> 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.
>
> >> 2. If they are and communication is inherently complex, then it is a heavy
> >> burden for the participants. Example: the boot time of well-known OSes
> >> paradoxically grows with the CPU speed, because protocols are so low-level.
> >
> > They grow because the vendor puts more crap in it, partly because OS's
> > are expected to do more now, such as TCP/IP, multimedia, dynamic device
> > installation, etc.
>
> And? This does not explain, why the advantage of having non-OOP protocols
> seemingly does not pay off. Why this wonderful simplicity [to wait for a
> timeout, what could be simpler!] is not scalable?!
You lost me. Maybe the context got snipped (no blame).
>
> --
> Regards,
> Dmitry A. Kazakov
-T-
.
