B Handling Property Graphs Using a TwoTables Schema
For property graphs with relatively fixed, simple data structures, where you do not need the flexibility of <graph_name>VT$
and <graph_name>GE$
key/value data tables for vertices and edges, you can use a twotables schema to achieve better runtime performance.
Note:
Support for the twotables schema approach described in this topic has been deprecated and will probably be removed in a future release.
Instead, you are encouraged use the property graph schema approach to working with graph data, described in Property Graph Schema Objects for Oracle Database.
The twotables schema approach is a deprecated alternative to the recommended approach of using the property graph schema (described in Property Graph Schema Objects for Oracle Database).

The property graph schema approach is designed mainly for heterogeneous and/or large graphs. When a graph model is used to present a dynamic application domain in which new relationships and possibly new data types for the same property name(s) are introduced and added to the graph model on the fly, using the property graph schema is recommended.
When a graph model is used to present a dynamic application domain in which new relationships and possibly new data types for the same property name(s) are introduced and added to the graph model on the fly, using the property graph schema is recommended.

The twotables schema approach is designed for homogenous graphs.
If a graph model represents an application domain where the set of relationships is already known and the total number of distinct relationships is relatively small (less than 1000), then the twotables approach is a potential option. This situation usually happens when the original data source is from one or a set of existing relational tables or views.
An example of where the twotables approach might be useful is if all nodes are employees of a specific organization, and each employee has a limited and fixed set of attributes and potential relationships. An example of where the twotables approach would not be useful is if the nodes can be any individuals who can have different attributes and relationships, and where attributes and relationships can be dynamically added and altered.
In the flexible key/value approach (not twotables), Oracle Spatial and Graph stores property graph data with a flexible schema: <graph_name>VT$
for vertices and <graph_name>GE$
for edges. In this schema, vertices and edges are stored using multiple rows where each row represents a key/value property associated with the vertex (or the edge) with a flexible data type, determined by the attribute T
(type). This schema design can easily accommodate a heterogeneous graph where vertices (edges) have different set of properties or data types of property values.
On the other hand, for a property graph with a homogeneous structure, you can store graph data using a twotables schema. With this approach, each vertex is stored as a single row in a named vertex table, and each edge as a single row in a named edge table. This way, each column in the row corresponds to a property with a fixed data type. The inmemory analyst can then use this approach to construct and manage the inmemory graphs.
Note:
The twotables approach is mainly for providing graph data for the inmemory analyst to existing Blueprintsbased Java APIs, and text indexing does not work with the twotables approach.
Graph data change tracking is only available when the property graph schema approach is used.
The following topics focus on how to create a property graph using a twotables schema, as well as how to execute read and write operations over this data.