Re: First Impressions on Using Alphora's Dataphor

Josh Hewitt wrote:

> I have recently downloaded Alphora's Dataphor product and begun
> experimenting with it. I tried to write a simple (non-GUI), toy
> application based on the principles put forward in the The Third
> Manifesto (TTM) and also in the articles published on the Database
> Debunkings [http://www.dbdebunk.com] site. I defined scalar types and
> scalar operators and I also spent some time designing a normalized
> database schema along with integrity constraints.
>[...]

> Nuisances
>
> - Since the DBMS now can be extended with user defined types (UDTs) along
> with their operators it follows that types and operators become
> database objects themselves. This means that they must be 'CREATE'-ed,
> later, possibly, 'ALTER'-ed, and eventually, 'DROP'-ed, just like
> tables (I use the Dataphor terminology here), views, and constraints.

Types are really different (from things like tables, columns, triggers, procedures), aren't they? Once the exclusive realm of compiler designers, later roll-your-own classes. Neither approach does the job for datamanagement. Somehow their significance extends beyonds one shop - much more so than e.g. tables.

> In addition, the strongly-typed nature of Dataphor means that each
> database object, in any reasonably large system, will have several
> dependencies and several dependents.

I don't understand what it is you 'ld want to see/have instead.

> Types can depend on other types
> and operators for their definition; operators depend on types and can
> depend on tables and views; tables and views depend on types and
> operators; and finally, constraints can depend on everything mentioned
> 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.

Uncharted territory does that to you.

> For example, when I realized that I have to change an operator I had to
> drop all the constraints and operators that used the one being changed.
> The situation was even uglier when I realized that I had to change one
> of the scalar types. In this case I practically had to drop every
> database object and then re-create them again.

Types are very basic to your operation, in an (as yet) elusive way. Maybe it's like "schema is to development what type-definition-system (one beer for a better name) is to schema" - but that is just a guess.

>[...]

They always did (depend on them). However, now you can play with them because of the gained tecnical freedom to find out it is somehow bounded by other phenomena. Which? (I am not asking you to solve, just to ponder :-)

> Relvars and operators are all defined using types while
> constraints are defined in terms of expressions involving relvars and
> operators. The consequence is that every scalar type will have several
> dependencies and several dependents. How can one fix a bug that requires
> 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.
> What are you going to do with older applications that depend on (the now
> obsolete) old types/operators/tables/views. Some suggested creating
> views for the old applications based on the new tables. I do not think
> that this approach is viable in the long run. It would mean duplicating
> the affected parts every time there is a bug fix. Also, the added
> complexity of maintaining 'parallel universes' for old and new programs
> is not something that one would want.

A type bug is a serious bug indeed.

> Now I digress a little bit so the following musings are about UDTs in
> RDBMSs in general. Please do understand that I am in full support for
> truly relational systems and I pose the following question in order to
> provoke a healthy debate that might focus attention to areas neglected by
> relational theory but which are still important in practice:
>
> What if major vendors 'do get it' but enterprise environments simply
> 'squeeze out' anything but atomic types (numbers, character strings,
> booleans, etc.) from the database?
>
> Quite often, in enterprise environments, development teams rarely have
> access and/or control over applications written by other teams. Given
> the tangled web of dependencies in a 'UDT-enabled' RDBMS, achieving
> success suddenly becomes a factor of how well-designed those UDTs are in
> the first place, and if they need modification, who has the right (and
> the resources) to perform those modifications. I think this is the make
> or break question of the real life success of truly relational databases
> right along with the questions of performance (which I do not want to
> address right now.) Most development projects try to have control over
> as many factors of their success as possible. (That is why everybody is
> building several layers of abstractions in order to 'insulate' themselves
> from the ever-changing environment.) Average workplaces have average
> developers on average. This means that it is rarely the case that
> developers can work on a database that is well-designed. Even in
> database design there are a lot of ways to screw up and I do not think
> 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. Not to mention that fixing a badly
> designed mess can be very time-consuming, especially if it is not the job
> one were hired to do in the first place. Even fixing serious database
> design flows in today's UDT-free databases often meets with severe
> resistance because of the (not completely unsubstantiated) fear of
> breaking other applications. 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? Is it not the case that
> the lack of UDTs in today's databases is more of a blessing then a curse?

Nice thought. I am sorry I don't feel up to go into this right now. Received on Fri Aug 27 2004 - 01:04:58 CEST