OODMS-FastObject.Net - Native object database for .Net

To follow-up on yesterday's blog entry about why we should be spending our time learning Object Databases as opposed to building O/R Mappers.

If you think about many data-driven applications, how much of the data is really transactional data that is reported on using standard RDBMS/Sql syntax versus data that hydrates our objects? In other words, we need to acknowledge the inherent need of our business software to enable reporting; however, how much of our business data do we really care about reporting on? For example, is 80% of the data we report on reside in 20% of our data-structures? Given that, it is fair to say that the complexity of our software is more closely related to the complexity of our persistent object-structures. In other words, are we solving the wrong problem? Shouldn't we be looking more closely at OODMS and figuring out a way to report on it....or if RDBMS support is needed for reporting (e.g. corporate mandate) should we figure out a way to make our persistence framework match more closely with how we design and program our software and then solve the reporting issue in the database.....where it belongs.....

The ServerSide.Net has an interesting post about FastObject.Net, a product by Versant technology http://www.theserverside.net/news/thread.tss?thread_id=25578. I haven't had a chance to delve into it too much, but it looks promising.

Some interesting links:
http://www.versant.net/eu_en/solutions/dotNet_en
http://community.fastobjects.com/community_fastobjects_net.htm
-Mathew Nolton

5 Comments

  • Hi Matthew,



    I have seen the FastObjects.NET in action on the basta/.net conference in Frankfurt am Main this spring. They have both: the OO-database AND O/R mapper, but they admit themselves that the fastobjects are working better with their native object oriented database.



    This object oriented database is not completely unknown: it is based on the poet object oriented database for java. The versant company fusioned with poet last year if I correctly remember...



    The FastObjects.NET use code enhancement btw. for field call interception. (the example from one of my articles)



  • Hey Igor,

    I read about the O/R Mapper portion on theserverside.net. This whole O/R Mapper implementation that everyone is jumping on seems to me to be necessary in the short-term but a complete waste of time in the long-term.



    My only concern with OODMS (which could kill the viability of an application) is query syntax and making sure it can perform with massive amounts of data. Have you worked with it at all?

  • DUDE... I *TOTALLY* agree with you... All these O/R mappers are being built to persist relational databases instead of building a better relational engine that understands objects.



    I've only had my hands on the Mattisse database: www.mattisse.com which has a Ado.net native provider that gives you hydrated objects based on object schemas built in the database.

  • I briefly glanced at poet oodbms few years ago as I was writing my master thesis. The current hype about o/r mappers indicates the increased awareness of impendance mismatch problem among developers and the need for an automatic solution. (The second reason probably is that with .NET reflection, it become much easier to implement a o/r mapper than in the dark age of c++ programming ;-) )



    The persistence layers are trying to look like OODMS to developer, while still working with RDBMS. I agree with you that that what we really want is oodms with a good query and transaction performance. (I think that this is only a matter of time.)



    It should be considered though, that an extra data layer is not necessarely always a bad idea. The applications using oodms are very tightly coupled with data, and the lack of standards (query syntax e.g.) makes it difficult to use another product.



    The other way to solve the impendance mismatch problem is to implement the object support in relational database itself (abstract data types in oracle e.g.), but I am not sure that that it is the right way: the object-relational and object-oriented data model are still different, the developer must be aware of another data model etc...



    Bye

    Igor (on the way to teched europe in amsterdam ;-)

  • Igor,

    You bring up a good point. Data Access Layers provide a layer of abstraction so that implementation details can change without impacting other layers. Moving to an OO implementation without this abstraction would be akin to running from the jaws of one beast into the jaws of another...maybe this isn't such a bad thing in the short term though. we as a community need to find our way with this technology and maybe breaking a few eggs along the way will enable us to provide a solution that we can all adopt. i agree about the object and relational models being fundamentally different. I don't know much about the latest Yukon release of SQL and whether or not they plan on supporting true oo types. My guess is similar to the conclusions you are drawing....specifically the models are totally different and difficult to reconcile.



    Later,

    -Mathew

Comments have been disabled for this content.