Benefits of migrating from SQL Server to Versant OODB

Question

What benefits (if any) for a company (and not just for developers) could I get by switching from SQL Server 2008 to Versant OODB?

More on the project and facts to help with the answer (let me know if you need more):

• A very small team that almost never used OODB.
• The project uses NHibernate 2.
• About 75% of testing coverage.
• ASP.NET MVC application.

At this point, I could not justify the switch due to the following points (most related to db4o, not Versant mainstream OODB):

• Tool
• pretty bad compared to the RDBMS world, where there are a bunch of "Managers", profilers, integration / migration tools, and others;
• the documentation is pretty simple of what I can observe and mix a lot with Java;
• Not many network resources compared to RDBMS
• Switching to other databases can be problematic (unlike RDBMS);
• learning curve for developers and IT teams;
• additional licensing costs;
• additional maintenance costs;
• no integration with MSDeployment (including automatic backup, MSBuild, Packaging, etc.);

Answer 1

Here are the comments of a real user who switched from SQL Server 2005 to Versant:

Here are reviews from me and my colleagues about VOD.Net.

I grouped my ideas into pros and cons.

PROS: (in a word: speed)

• The database engine quickly reads and writes data from what weve done, about 5-10 times faster than SQL Server 2005
• This reduces the amount of code needed to do the same as the standards of data access technologies.
• It also shortens development time for new functionality.
• It creates a strict object structure and facilitates data integrity.
• Importing data into VOD is simple.

CONS: (in a word: need troubleshooting skills)

• Our main negative point is the convenience of using the administration tools (Administration Console and Object Inspector).
• Buttons / Links are not entirely clear as to what they do, we usually find out when we try to use it.
• Versal compilations / Database update errors are not explicit enough, we barely know that the class is causing an error, but not the reason, so we need to debug it ourselves.
• Using the menu option "Check database" cannot work and will show errors (depending on time)
• Application migration
• When porting a DAL template application, it will work with VOD for a long time if you try to keep the same code for the user interface

In summary, I would recommend using VOD.Net for enterprises with senior developer skills and a complex / large data structure. This definitely speeds up the creation of a new application than porting an existing application. The site inspector needs a redesign to make it more convenient.

We addressed some of the issues with Object Inspector by providing LINQpad support. I think you should decide to switch based on technical advantages, and not on any emotional discussions. Versant is also a Microsoft partner, and there are many opportunities for people with good OO Versatile skills or not.

Answer 2

Depends on your object model. If you are dealing with deep object graphs in your domain with complex hierarchical relationships, you will gain a lot of time by switching from SQL Server 2008 to Versant ODB. If you are dealing with flat objects tied to a relational engine. Please check the c / s results at www.polepos.org: http://polepos.sourceforge.net/results/PolePositionClientServer.pdf

Answer 3

You forgot ... Most likely, it will be much faster (but it will depend on your model. If you have a simple model, I recommend just stick to RDB).

If you have many-to-any, recursive relationships, nested subgraphs, etc ... then if it will be much faster.

Of course, it will also work on much less hardware. Research at IBM shows that you will save about 50% of the CPU at your mid-tier (for example, you are web servers where all type translations occur for RDB).

In addition, you do not need a database expert. If you are an OO guy, you already have a set of skills ... especially if you know Hibernate / nHibernate, because the lifecycle concepts of an object from Hibernate and ORM space were mainly captured from the OODB world and transferred to the RDB camp.

In addition, you can iterate much faster in development cycles without having to constantly contact the database administrator and request schema updates.

.... RDB will eventually switch to mainframe. Everything around, but not used for new projects. These Cobalt programmers didn't believe at this time ... so don't worry with all the speakers.

Answer 4

If you want to switch, do it. This is your only plus.

"getting rid of the mismatch of the object-relational impedance that we are all so tired of."

You have indicated most negatives. I will add two more:

• How can assignments set Versant OODB skills?
• How many developers will have Versant OODB skills?

Answer 5

In the disclosure, I work for Versant in Sales and comment on your questions, Versant is a commercial product, but like SQL Server, we have similar prices, Community Edition is free with database size restrictions, Standard Edition is a small server cost but limited by the number of threads allowed and Enterprise Edition, which is expensive, but less than SQL Server or Oracle if you need scalability and performance. In addition, by switching from nHibernate to LINQ, you can use it in the Versant database, and in the future, if you want to return to SQL Server, you can do this quite easily using EF or LINQ TO SQL, so it mitigates your risk in database infrastructure. This would be a question for Versant, and not using the KVP NoSQL store with a proprietary interface. True, there is much less documentation that Relational, but www.odbms.org really contains excellent information and reference materials. The learning curve, if your team owns C #, should be fairly simple, and from the point of view of administration, Versant is a database, so learning about backup and recovery should seem familiar. Our customers, C ++, Java, or .Net, all say that Versant's advantages are ease of development, performance, and the ability to support their needs with fewer resources on servers and storage.