Re: SQL
- From: "Dmitry A. Kazakov" <mailbox@xxxxxxxxxxxxxxxxx>
- Date: Fri, 3 Feb 2006 11:02:32 +0100
On 2 Feb 2006 17:13:49 -0800, topmind wrote:
Dmitry A. Kazakov wrote:
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.),
This is a definition of a class: the set of types, each of them has "<",
"=". Further one might wish "<" to be order relation and "=" be equality
relation. You can argue that all objects should be of this type, but this
is mathematically unsound. For example, tables themselves, as objects,
aren't ordered. Complex numbers aren't ordered, etc. There also might be
incomparable objects.
then relational can
operate on it. (And possibly only just equal or not equal are needed.
Need more pondering on this.)
You need order for sorting, otherwise everything will become O(n).
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.
Thank you for explaining why ADT is so great! (:-)) You are right, with ADT
one just need to implement the interface of a
thing-that-can-be-in-a-relational-table and here it is, the engine works!
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.).
How else, you can extend the DB for dealing with something new without
changing the engine?
You probably meant not new types, but new classes, new interfaces
additional to a thing-that-can-be-in-a-relational-table. But I don't see
why this should be any advantage. Note that even for things you can put in
a table, it makes a lot of sense to refine interfaces to have:
integer-number-in-a-table with specific operations to sum a column, and
string-in-a-table, and so on.
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?
The only difference is "A1" (a run-time object of the type String) vs. A1
(statically known name, not an object, not a type, nothing). The first can
be trivially typed as SQL does. There are two types: String and Table. The
second requires sets of types to be handled in a generic way. To bring it
back to the language. OO offers you both. SQL can only the first. When you
criticize OO, you refer to the second, which in the most of languages does
not allow any kind of generic programming, because A1 is just a name. But
OO does not force you to do so. Moreover OOA/D requires you to carefully
consider whether it is really just A1, the singleton, or there is a set of
values A1, A2, ..., you have to factor out. If somebody ignores good
advises, then it isn't a problem with OO.
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.
Relational model is just a view. It might be formally correct, but
inappropriate for technical reasons, or because it just appears unnatural
for humans (like relational representation of graphs.) OO model offers a
choice which IMO by no means excludes relational model.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
.
- Follow-Ups:
- Re: SQL
- From: topmind
- Re: SQL
- References:
- Prev by Date: Re: Features in my application: Any solution or pattern?
- Next by Date: Re: SQL
- Previous by thread: Re: SQL
- Next by thread: Re: SQL
- Index(es):
Relevant Pages
|
