Re: First Impressions on Using Alphora's Dataphor
Date: Fri, 27 Aug 2004 19:00:38 +0200
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.
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.
Alfredo Received on Fri Aug 27 2004 - 19:00:38 CEST