Re: Graph Schema

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

This is a vague question, as you don't specify what you want to do with the graph. If you want to ask the database questions such as "what is the shortest path from node A to node B", then you're going to have a problem doing this in the subset of SQL typically implemented by major DBMS products.

That said, there are well-understood techniques to deal with problems like that. Often, they involve using triggers to overcome the limitations involved in the query language. For example, while problems like shortest path of a graph are not possible in plain SQL (excluding some SQL99 features that are not widely implemented), it is entirely possible to add triggers in practically all reasonable DBMS products that will maintain auxiliary tables allowing you to get that kind of information. These auxiliary tables would be logically equivalent to views, even though they are likely to be explicit tables as far as the DBMS is concerned.

It's also possible to use a procedural extension to SQL (such as most stored procedure languages) to implement an algorithm for a tough problem like shortest path.

So I wouldn't call it a nemesis; but it does require some consideration in the design process.

> 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).

As has been pointed out, this question can't be answered in the abstract. You should represent data using an appropriate set of normalized relations for that data.

-- 
Chris Smith