# ActiveOrient Case Study: Universal Store Facility

**URL:** <https://metaruby.com/t/activeorient-case-study-universal-store-facility/2266>\
**Category:** Learning Ruby\
**Created:** [August 5, 2019, 6:21pm UTC](https://metaruby.com/t/activeorient-case-study-universal-store-facility/2266 "2019-08-05T18:21:24Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![hartmut](https://metaruby.com/letter_avatar_proxy/v4/letter/h/958977/32.png) [@hartmut](https://metaruby.com/u/hartmut)\
**Post date:** [August 5, 2019, 6:21pm UTC](https://metaruby.com/t/activeorient-case-study-universal-store-facility/2266/1 "2019-08-05T18:21:24Z")

</div>

In a recent screencast [Dave Kimura](https://metaruby.com/t/screencast-working-with-large-data/2265) worked hard to get quick responses from large tables in a sql-database.

Recently I published an introduction of ActiveOrient in [dev.to](https://dev.to/topofocus/active-orient-introduction-overview-4knj). The latest part covers a setup to build a time-grid based graph-database which offers constant access times to big data tables by design.

Would be interesting to compare the Postgres-based solution with the ActiveOrient-Approach

Details:

> **[ActiveOrient: Universal Store Facility](https://dev.to/topofocus/activeorient-universal-store-facility-58bi)**
>
> In Part 3 we claimed »Inheritance and the flexibility of the graphical vertex & edge approach ope...

## Conclusion

Database Design matters, even if a flexible multi-model-database is used. This time-grid 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.