Re: Relational model versus object model
From: JXStern (JXSternChangeX2R_at_gte.net)
Date: 02/18/04
- Next message: Programmer Dude: "Re: Dijkstra gets it wrong [was: Re: D gets it right]"
- Previous message: Comic Book Guy: "Role-Oriented Programming [Was: Pool-oriented programming]"
- In reply to: Arkadiy Vertleyb: "Relational model versus object model"
- Next in thread: Arkadiy Vertleyb: "Re: Relational model versus object model"
- Reply: Arkadiy Vertleyb: "Re: Relational model versus object model"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Wed, 18 Feb 2004 17:25:30 GMT
On 17 Feb 2004 15:56:38 -0800, vertleyb@hotmail.com (Arkadiy Vertleyb)
wrote:
>The relational model, on the other hand, provides a very simple
>high-level language to convert data from one form to another --
>relational algebra.
Um, "convert data" is not exactly right, but we know what you mean,
sort of.
>The redundancy (indexing) is easily managed.
That's not redundancy.
The "redundancy" is the ability to access data anywhere in the
database with a single nonprocedural query. Which is of course not
really redundancy either.
>Besides, relational tables are easily serializable.
They are already serialized, in theory and usually in practice.
>The biggest problem, however, is that when people think "relation",
>they usually think "persistence", "SQL" and "Oracle" (or any other
>RDBMS on that matter).
You may be right that people do, but if so, they are mistaken at that
point. My relation to my cousin Dwayne is not persistence, SQL, or
Oracle. Neither is the relation of order #123 to customer #ZZX. Ah,
the humanity.
> The next moment, unless you have to manage
>tera-bytes of data, you decide to relax, and think of something more
>plesant (like "interface", "polymorphism", or "decorator").
Really, just a few weeks as the member of a team using a relational
database in anything like a competent manner, should remove the pain
and suffering that you seem to believe is so common in OO
practitioners who come near a relational database. I swear it's like
watching a guy use a screwdriver to pry screws out of their holes. I
think I'll start a business, get an old ambulance, like in
Ghostbusters, speed to the scene (for a price) everytime this happens,
and thus save the world.
>Does it really have to be this way? What if it was possible to define
>relational tables right inside your code, in the same way you create
>an array or map? These tables would be located in memory, and would
>have no restriction on the column type (you could store integers,
>strings, objects, polymorphic pointers, etc.). The interface would be
>one of the language you work in, as opposed to SQL. Wrong column and
>table names would be caught at compile time. You would be able to
>create redundancies (in form of indexes) to boost performance, and
>these redundancies would be automatically managed in a seemless and
>efficient way? And you would have serialization practically "for
>free".
Exactly how is this different from today? You can do pretty much all
of this using your favorite language interface to your favorite
relational engine, and never touch a line of SQL.
The one thing that the relational guys have been ridiculously slow
about is allowing type and/or operator extensions to the language and
tables. In most cases you can stuff them today into blobs, but not
add any semantics. It turns out there are some weak reasons for this
restriction, this hesitation to allow extension. OTOH, some simple
object-relational hybrids would be nice. I often want to treat a
table as a class and specialize it, a much more concise form than
defining child tables and linking them back to the common root with
foreign keys, referential integrity, cascades, and views. Oh, SOME
day, someone will do this. Sigh.
>The question is, if all that was available, would you find more use
>for relational model?
>
>Thanks in advance for your responce,
See also Oracle's PL/SQL.
Yes, one could have a more static, more Java-like (I guess that's the
modern, OO version of Algol-like) language than SQL, or the various
procedural extensions to pure SQL that are used for stored procedures,
and one could be allowed to cheat the engine and access the underlying
b-trees or hash tables, that's been done, if not recently.
J.
- Next message: Programmer Dude: "Re: Dijkstra gets it wrong [was: Re: D gets it right]"
- Previous message: Comic Book Guy: "Role-Oriented Programming [Was: Pool-oriented programming]"
- In reply to: Arkadiy Vertleyb: "Relational model versus object model"
- Next in thread: Arkadiy Vertleyb: "Re: Relational model versus object model"
- Reply: Arkadiy Vertleyb: "Re: Relational model versus object model"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
