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? Or are such schemas considered "routine"
> for skilled DBAs and application developers?

When graph theory applies to the problem considered, one can apply graph theory to simplify the problem during analysis and design. Representing the data in relations is no problem.

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

1. Half the size by what measure?
2. Define 'data-driven'
3. What could simplify application development more than the full power of predicate logic?