Graph Schema
From: <barias_at_axiscode.com>
Date: 13 Nov 2006 02:16:10 -0800
Message-ID: <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. 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?
Received on Mon Nov 13 2006 - 11:16:10 CET
Date: 13 Nov 2006 02:16:10 -0800
Message-ID: <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.
- 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
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?
Received on Mon Nov 13 2006 - 11:16:10 CET