InPart 3 we claimed »Inheritance and the flexibility of the graphical vertex & edge approach open sudden opportunities.« Let's prove it right away.

The power of RID

OrientDB is a »multi model database«, capable to act as a (SQL)RDMS-, a KeyStore- and a Graph-Database. The KeyStore-Design requires the presence of an universal Key, that'sRID.

Each record has aRID, each Object is fully identified through itsRID. Simple, but powerfull.

>Person.last.rid=>"34:0">"#34:0".expand.to_human=>"<Person[34:0] (...) >"

Data-items loaded from the database carry their class-id.ActiveOrient autoloads the object and assigns the corresponding ruby-class. Thus any method defined in the model is accessible, any attribute is present as well as any join and any connected edge is waiting to be discovered.

Time Grid

Think of a mesh of date-items, supporting one central goal: Provide an even access-time to any Date of a given time-period, to any item connected to the grid.

This Graph is realized

Jahr -- [MONTH_OF] -- Monat --[DAY_OF]-- Tag --[TIME_OF]-- Stunde

The nodes are crosslinked via GRID_OF-edges and any point of the grid is easily accessed.

To use the time-grid, install theOrientDB-Time-Graph-Gem. It creates the grid and defines a methodto_tg forString andDate/Time,

>Date.today.to_tg.datum=>Fri,02Aug2019#  and"4.6.2015".to_tg=>#<TG::Tag:0x00000000043c8c60 (...)

Store Items

By simplyassigning a database-record to theTag-Object, the universal store facility is created.

Lets go back to our family ofPart 3 and assignSeema's birthday. We use a specialized edge-classHAS_BIRTHDAY

>E.create_class:has_birthday>sema=Child.where(name:'Seema').first>"20.6.2010".to_tg.assignvertex:sema,via:HAS_BIRTHDAY

Query

Let's consider two use-cases

• we just want to know Seemas birthday
• we are interested in all birthdays in June 2010

Seemas Birthday

We can simply get the Child-Record and follow the link to the time-grid.

>sema=Child.where(name:'Seema').first.to_human"<Child[147:0]: in: {IS_CHILD=>1, HAS_BIRTHDAY=>1}, name : Seema>">seema.nodes(:in,via:/birth/).datum# firing a query#or>seema.in_has_birthday.out# performs action in ruby=>[Sun,20Jun2010]

This is similar to an RDMS(SQL)-approach.

Any Birthday in a given range

Suppose, you got a huge database, full of birthdays and want to mine the data. In the RDMS-World you would query the hole database-table. The more data, to longer it takes. Even if you are just interested in People with Birthdays in the same month then Seema, there is no way to avoid accessing all birthday-records in store.

The »Time-Graph« offers constant access time regardless of the size.
We just jump to one boundary of our range of interest and traverse the next 30 day-records.

>start="1.6.2010".to_tg>start.vector(30){:out_has_birthday}# INFO->select out_has_birthday from  ( traverse  outE('tg_grid_of').in  from #55:5042 while $depth < 30   )  where $depth >= 0=>["#52:5043"]>start.vector(30){:out_has_birthday}.expand.nodes(via:/birth/).to_human=>[["<TgChild[147:0]: in: {TG_IS_CHILD=>1, TG_HAS_BIRTHDAY=>1}, name : Seema>"]]

The method »vector« encapsulates the traverse query. We follow 30 time-grid-links (30 days) and are looking for an property »out_has_birthday«. The query returns an array ofRID's (of Time-Grid-Elements). We expand them manually and follow the linkHAS_BIRTHDAY.

If we are interested in the count of birthday's in a specific range:

>start.vector(30,function: :count){:out_has_birthday}=>1

Conclusion

Database Design matters, even if a flexible multi-model-database is used. This simple pattern opens a door to »sustainable programming«. In contrast to classical RDMS(SQK)-Databases, using a Time-Grid, time-dependent data are stored in an unified environment. Queries are time-invariant. That means: if a database matures, grows and evolves, on can expect constant access times to its heart: the Time-Grid. The possibility of an assignment of any (seriable) ruby object to the time-grid is self evident.