Re: First Impressions on Using Alphora's Dataphor

On 26 Aug 2004 10:10:56 -0700, lajos.nagy_at_gmail.com (Josh Hewitt) wrote:

> so far. The end result is a complex web of dependencies between
> database objects where you cannot simply re-define anything without
> re-defining its dependents at the same time. Simply put, the
> create/drop cycle became the most annoying part of the development.

It seems an insignificant problem to me.

You only have to drop the database and to execute the modified script.

>- Although it is logical after giving it a little thought, it came as a
> nasty surprise that Dataphor demands that all scalar types that might
> appear in a context where duplicate elimination is required must have
> the less-than (Dataphor calls it 'iLess') operator defined on them.

It seems a little bug to me. The equality operator should suffice.

>How can one do software maintenance in a live Dataphor installation?

Export the data, drop the database, execute the new script and import the data.

>Since scalar types form the building blocks of the database design,

Scalar types don't change often in databases, specially in business systems.

>more than cosmetic changes in this setup? You cannot just drop the type
>since everything depends on it. Also, what are you going to do with the
>data in your relvars? You cannot just drop your production tables.

Why not?

If it is a 24-7-365 system then you have redundant servers and you can update them individually while the other servers still run.

>that designing UDTs is easier business in any way. So in a UDT-rich
>world developers would be forced to work with someone else's not-so-well
>designed UDTs most of the time.

The UDTs needed in biz systems tend to be few and trivial to design.

>Is it not better then to forget about UDTs
>in the database and only allow them in programming languages where
>developers have complete control over them?

Definitely not. They can be useful in the good hands, and in the bad hands the system will be a disaster anyway :).

> Is it not the case that
>the lack of UDTs in today's databases is more of a blessing then a curse?

The lack of UDTs in today's business systems is not a very important problem, but it is in GIS, CAD and other areas. The niches of the called OODBMSs (basically network DBMSs with UDTs).

>Sorry for the long post, but I felt that this might be an interesting
>topic to discuss in this news group.

The most interesting post in a long while.

Regards
  Alfredo Received on Fri Aug 27 2004 - 19:00:38 CEST