Elastic Data Model

[SN]

I am working in banking industry.  Banks have a well defined relational data model to support core banking functionality.  What I want to do is to represent that the bank data model in OrientDB to accomplish two things:

1. I want to retail all the relationships defined by baking data model

2. I want to have the flexibility to add additional fields/properties to existing tables/classes.  When I do that I need to make minimum changes in my code to see the newly added field on the UI or in API exposed to end users.

How can I do that?  Is there an example that I can look at?  Can graph model be used by setting the strict mode to false to accomplish the two goals I listed above? Any thoughts you an offer would be greatly appreciated. Thanks

[scott molinari]

Hi,

For 1. Have a look at the new Teleporter system. 

http://orientdb.com/orientdb-labs/teleporter/

http://orientdb.com/orientdb-teleporter-making-migrations-easier/

http://orientdb.com/docs/last/Teleporter-Home.html

For 2. First thing, although ODB is a No-SQL database, there are always gotchas (as with any No-SQL DB) you should be aware of with changing the schema (i.e. adding properties on-the-fly, as you'd like). The good news is, you can add and remove properties on the fly very easily. The bad news is, if you add too many properties on too many records at one time, you might cause havoc with the storage engine. Just be aware that No-SQL (again, any No-SQL solution, not just ODB) also has limitations in terms of flexible schema. Yes, they can offer flexible schema and no, it isn't unlimited flexible schema. The good news is, ODB allows you to set up the database with larger record size padding (towards the bottom), should you know you will be going crazy with adding properties. This does mean higher disk and I believe even memory requirements, but it also means, available, fast and uninterrupted schema changes. That is the compromise you'll have to decide on from the start, as the padding settings can't be changed on-the-fly (at least I don't believe they can). 

Secondly, OrientDB doesn't currently properly support the avoidance of the object/ relational impedance mismatch(ORIM), because it doesn't allow for indexing on non-schema properties. That means, you still always have to carry the schema baggage around with you, when developing with ODB, if you want ODB to also perform well. (Some hardcore developers believe the DB must contain schema. They are still living in the RDBMS world, unfortunately...) That being said, ODB tries to support avoiding ORIM in ways way beyond any other No-Sql solution, like with the class hierarchy system, which is ingenious. Still, this last hurdle of not being able to index properties not defined in schema needs to be taken, in order for ODB to be a pure No-SQL DB solution IMHO. The good news is, I believe it is planned to be added in Version 3.0, which is due to be released sometime at the end of this year. Once ODB gets this right, along with very good driver support, it will be probably the most versatile and powerful DB on the planet. :-)

Edit: Anyone with more knowledge, please do correct me, if I am wrong, or confirm, if I am correct.

Scott