Re: SQL
- From: "topmind" <topmind@xxxxxxxxxxxxxxxx>
- Date: 2 Feb 2006 17:13:49 -0800
Dmitry A. Kazakov wrote:
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?
Related discussion:
http://c2.com/cgi/wiki?DoesRelationalRequireTypes
The "expression engine" can be logically seperated from a relational
engine it appears to me. As long as the expression engine supports
equality comparisons (less than, equal, etc.), then relational can
operate on it. (And possibly only just equal or not equal are needed.
Need more pondering on this.) SQL is a specific language with certain
constructs hard-wired in. However, SQL is not the end-all-be-all of
relational nor query languages.
Thus, if somebody wanted to include imaginary numbers in a relational
query language, in theory they could without busting relational. It
demands very little of the underlying expression model.
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.
Well, this gets into a sticky issue of a definiton of types. Let me
just put it this way: "a reduction of a reliance on types to model the
domain". In other words, the language may have a few native "types"
(functions, arrays, variables) to serve as the building blocks.
However, one does not add new "types" to model the domain in such
languages, rather using other approaches instead (schemas, functions,
etc.).
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?
Indirection?
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.
Well, if everything you are considering is an attribute, then you will
have a kind of database anyhow, just a navigational one in your case.
But that is not usually what is done, so it is only a speculative
situation.
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?
Because SQL stinks in certain areas. And, there are cases where a
procedural interface may be more appropriate than a declarative one. I
don't dispute that. I never claimed SQL or relational was best for the
*entire* app. Sometimes use Yin, sometimes Yang.
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. ]
There is a certain balance between standards and flexibility.
Relational reigns in the some of "creativity" found in navigational
structures, and this is usually a good thing. Sure, there are
side-effects that can be annoying, but it is the net benefits that
count.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
-T-
.
- Follow-Ups:
- Re: SQL
- From: Dmitry A. Kazakov
- Re: SQL
- References:
- Prev by Date: Re: SQL
- Next by Date: Re: Is it a facade
- Previous by thread: Re: SQL
- Next by thread: Re: SQL
- Index(es):
Relevant Pages
|
