While migrating data for a client, I noticed that the newly optimized v.Connection View inserted 30,062 connections in about 1 second. Zooooom.
A key component of any database is the lookup table and the Foreign Key. From countries and states, to statuses, and colors, the standard lookup table provides a known set of options for combo boxes. The proper term is "domain relation" that provides a limited set, or a domain, of possible correct items for an attribute.
Relational database modelers even argue about whether a system with many domain lookup tables should have a table for each lookup list, or if the multiple lookup lists should be merged in to one massive lookup table. There are pros and cons to each pattern, and my goal here is not to weigh into that debate but to illustrate how critical lookup tables can be,
In a pure graph database, rows can only be represented in nodes. Every domain lookup item would be a node and the Domain lookups FK relationships would be relationships, or connections to the domain node.
TejonDB is a hybrid database so we can pull the best features of each type of database and avoid the limitations that cause problems. Lookup lists are built in TejonDB by creating and populating Domain Classes. This keeps the first class, or main, objects in the object classes, and keeps the lookup items from appearing as nodes. Attributes with the Lookup data type can then point to the domain classes, which in effect creates a foreign key form the attribute to the domain class. The TejonDB application automatically reads the meta-data about the attribute and the domain class can creates a combo box with a drop down list.
And that's how lookup tables work in TejonDB.
Please join me this month at the Colorado Springs SQL Server User Group as I discuss graph database theory and query and demo TejonDB.
A relational database design uses an entity (table) for each logical groupings of tuples (rows: people, places, things). It follows then that each foreign key relationship between tables is a specific foreign key. For example, a relational database with about 50 tables might have 50 different foreign keys.
So the answer to, Why a Graph Database? is that TejonDB is designed to be highly configurable and flexible, and the graph database design is extremely flexible - much more so than the traditional relational database. (as a side note, I designed the initial pattern for generalized connections while experimenting with sentence structures for data, several years before I heard the term graph database. The pattern is just that intriguing.)
TejonDB takes it a step further by adding object-oriented structure and usage rules to which classes (types) and statuses (statuses), because just adding a label to a node or connection is too slippery for enterprise use.
There are several graph databases out there. But TejonDb takes it a step further, by building the graph that can be manipulated using the visual tools and with normal relational SQL - e.g. by inserting into the Connection view like this,
this connection is created:
Of course, if your users prefer to create connections directly in the Connection Viewer, TejonDB does that too.
I'm a science fiction geek and I admit I liked Timeline - the book by Michael Crichton and the 2003 movie. Give me adventure, swords, a little romance, and some time travel and I'm hooked. Which is a problem for relational databases.
TejonDB takes the basic concepts of data auditing and modeling historical data and pushes it to the next level. To visualize the temporal data, TejonDB sports a graphical timeline of the object's type / status and region history. What's more, every Filter Element can search for current data, data at any time in the history of the object, or data for a specific date range. For us, data history is just a audit trail, deep in the database engine, TejonDB is a temporal (timeline) database.
Why did we go to such lengths? Because organizations are about relationships, and relationships are about history.