Re: abstract data types? - Mailing list pgsql-sql

Hi again,

Josh Berkus wrote:

> John,
>
> > Thanks for your comments. My 2c worth:
>
> That was at least $1.50 worth.  Teach me to speak 'off the
> cuff' on this list ...

Just because I went out and brought a stack of books doesn't mean that I
actually know anything ;-)

> > As
> > far as the
> > relationship between the schemas for financial and
> > spatial information
> > systems goes, a book I have (on OO database management)
> > goes so far as
> > to say "that relational database systems do not
> > adequately support these
> > so-called non-standard applications."
>
> I'd agree with you, I'm afraid.  Most of the "spatial
> database projects" I've been familiar with involved either:
> a) completely custom software, or b) *lots* of RAM and
> processing power, or c) both.

These are some of the things that have me scared - actually these
considerations are main reason that I was was thinking of a two-tier
approach.  The data "views" the applications would access directly would
be optimised for performance, the underlying store for flexible storage
and data integrity.  I figure big disks are a lot cheaper than a dirty
great machine.  Especially if I can use IDE RAID and run on otherwise
throwaway hardware - we don't need 100% uptime, just need to make sure
we don't loose the base data.  The ability to get it all running again
in several hours would be a definite plus as well!

> > Unfortunately I can't speak from personal
> > experience - I
> > don't have any access to it, as at uni we are a Oracle/MS
> > SQL
> > Server/mySQL shop, and from my preliminary investigations
> > none of these
> > seem to cut it for this task as far as I am concerned :-(
>
> A definite No for 2 of the above.  MySQL was built to be
> fast and light, with a minimal feature set.  As a
> semi-certified MS SQL Admin, I can tell you that MS SQL
> Server isn't up to anything better than a *simple*
> accounting database.  Oracle, on the other hand, claims to
> do anything.  They really have no geometic support?

Oracle does have geometric support (Spatial Data Cartridge I think it's
called).  My main concern after reading the Oracle8 technical reference
was the underlying fundamentals.  From what I could see, Oracle seems to
have just slapped an object-relational type syntax over the original
relational engine.  IIRC, all datatypes were still rigidly structured
i.e. fixed length arrays support only, no variable length data types
etc.  For any application trying to model the vagaries of the "real"
world, I feel that this can only lead to tears (or a tendency for DBA's
to go insane) sooner or later - probably sooner.

BTW, if any insomniacs out there are looking for a cure, try reading the
O8TR manual.  I can recall falling asleep after about 1 page just after
consuming about 3 cups of strong coffee - which would normally have me
bouncing off ceilings :-)

> > Interesting. This is a really cool site. Thanks. However
> > I don't see how
> > you draw the conclusion from what I have read on this
> > site "that
> > object-oriented and relational approaches to data
> > problems *cannot* be
> > made to reconcile." C.J. Date here seems to be arguing
> > more about the
> > semantics employed in UML modelling, Pascal more about
> > the quality of
> > database design. This site does give me the urge to read
> > up on set
> > theory - I've forgotten what little I once knew.
>
> You're right, that's what's currently on the site.  I'm
> basing my opinion more on the earlier writings of Pascal ...
> and porbably on my own expereinces.  Of course, we could ask
> him.
>
> > In [DAT00] (Section 25.1 pg 863) Date states "we need do
> > nothing to the
> > relational model in order to achieve object functionality
> > in relational
> > systems - nothing, that is, except implement it, fully
> > and properly,
> > which most of today's systems have so signally failed to
> > do."
>
> Yeah.  Few systems bother even to fully implement the SQL
> standard fully ... and SQL 99 was as much a product of
> politics in the computer industry as logic.
>
> For example, I agree with Pascal & Date that BLOBs are a bad
> idea, and a violation of relational priniciples (being data
> that cannot be stores as a value in a column in a relation).
> One need only look at the terrible and persistent
> implementation problems for BLOB support in various
> platforms for proof of this.
>
>
> > He then states that "the support is already there [in the
> > relational
> > model -jgr], in the shape of domains (which we prefer to
> > call types
> > anyway)."
> >
>
> Yeah.  Real DOMAIN and TYPE support (which are really two
> diffetent things, a Domain being a specification for a more
> general Type) in Postgres would be teriffic.

Also, IIRC, OO types have methods, domains have only values.  I'm not
100% sure on what distinction is made between them in SQL99, whether
domains are included in the spec or whether this concept is covered
instead by the create distinct type statement.  No book to check at the
moment :-)

> How about it,
> Tom, Stephen?

Just an idea :-)  I'm no cvs guru, but isn't it possible to define
seperate branches within the same cvs tree?  That way, anyone crazy
enough to get involved in this could experiment without running the risk
of breaking the MAIN branch, while still keeping up with the latest
changes to the code in other areas.  Then, when ready, any required
changes could be merged back into the main tree.  I think some approach
similar to this is probably a "Good Thing", as some changes will
probably be necessary in the core of the system, resulting in a
significant risk of major breakages that we probably don't want to
subject other developers to.

> > Chapter 1, pg 6). Interesting, I just noticed the
> > statement "is truly
> > relational (unlike SQL)."!
>
> Yes -- see my comments above.  Market pressues and politics
> have caused the ISO to abandon relational standards in
> formulating the SQL standard in many areas.
>
> > Sorry, disagree strongly here.
>
> Ok.  I'm probably just biased, anyway, from being burned by
> DB tools claiming both OO and SQL-relational support.
>
> > As far as I can tell, PostgreSQL has most, if not all, of
> > the building
> > blocks to supply support for abstract data types already
> > in place.
> > Whoever thought up the system catalogs (as well) was one
> > very smart
> > individual. Salutations, whoever you are!
>
> I'd definitely stand back and applaud any effort to support
> this.  When I first started with PostgreSQL, I thought it
> was a really nifty idea, until I tried to build a database
> on it.  Puls I soon discovered that nifty ideas do not a
> payment-processing database make :-(

Naivety is such a wonderful thing.  I speak from experience.  Now to get
bitter, cynical and twisted :-)

> > Any help people can give me would be much appreciated.
> > I'm already
> > feeling a little lost. I hope people don't mind if I ask
> > a lot of dumb
> > questions over the next few weeks :-) Is this the
> > appropriate list, or
> > should I move over to hackers?
>
> You should probably cross-post.  This list is the place to
> see if a number of other developers are interested in the
> functionality you propose (yes), hackers is probably the
> place to ask how to make the actual changes.
>
> I can't help.  Heck, I can't even get 7.1 beta to run on an
> alternate port.
>
> -Josh Berkus
>
> P.S. BTW, John, I'm thrilled to get a discussion of issues,
> going here in addition to the how-tos!

Cool.  However, I'm just not up to the stage of asking the how-to's yet!

cheers,
John
--
----------------------------------------------------------------------
john reid                                  e-mail john_reid@uow.edu.au
technical officer                                room G02, building 41
school of geosciences                           phone +61 02 4221 3963
university of wollongong                          fax +61 02 4221 4250

uproot your questions from their ground and the dangling roots will be
seen.  more questions!                                                      -mentat zensufi

apply standard disclaimers as desired...
----------------------------------------------------------------------