Re: Graph Schema

barias_at_axiscode.com wrote:
> 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?

No.

   Or are such schemas considered "routine"
> for skilled DBAs and application developers?
>

No.

Graphs, themselves, are not a big issue but DBMS products provide little support for operations on graphs and some sort of "procedural processing" scribbling is necessary. If that happens "outside" the database (the application), it might be impossible guarantee data integrity. If that happens "inside" the database (in some variety of DB/PL), there might be limits to what can be readily handled.

I have seen implementations where maintaining graphs was very time-consuming and other where, because of limits on recursion, depth was limited to 30.

> 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?
>

I don't get the distinction between "domain centric" and "abstracted into a graph."

I've never heard of - never mind understood - practicing to avoid temptation. Received on Tue Nov 14 2006 - 11:51:54 CET