Re: Graph Schema

<barias_at_axiscode.com> wrote in message news:1163412970.065910.237890_at_e3g2000cwe.googlegroups.com...
> I have two questions related to theory, practice, or principles of
> designing an application's schema for a relational database.
>
> A) Is it true that a graph (as in graph theory, nodes and edges), when
> represented recursively in a schema, is considered a nemesis to DBAs
> and application developers? Or are such schemas considered "routine"
> for skilled DBAs and application developers?

You seem to imply that DBAs and database designer are one and the same. In my experience, they are not. While there is considerable overlap in the skillset, many professional DBAs are junior database designers and vice versa.

Could you be a little more specific about "represented recursively in a schema"?

>
> B) For a given application, suppose you had a choice between a schema
> that was domain centric, or a schema that took the various domain
> "entities" and abstracted them into a graph (see question #A). Suppose
> the "graph" schema was (1) half the size (2) more data-driven and (3)
> seemingly easier to do application development with. Would that be
> sufficient cause to choose the "graph" flavored schema? Or is it a
> well understood database principle and practice to avoid such
> "temptations" in favor of the domain centric schema? Why?
>

Half the size: disk space is cheap.

More data-driven: again, could you be more specific?

seemingly easier to do application development with:

It depends. Many times, in the past, a database that was highly adapted to the problem as stated met this criterion. But, over time, the database outlived the application. The usefulness of the database with regard to the new problems as stated turned out to be low, due to the same features that made it initally attractive. If this happens, the cost of redesigning the database may outweigh the short term convenience.

Are you thinking long term or short term? Received on Mon Nov 13 2006 - 13:37:45 CET