Avantages de passer de SQL Server à OODB Versant

Question

Quels sont les avantages (le cas échéant) à la société (non seulement pour les développeurs) que je pouvais gagner en passant de SQL Server 2008 à OODB Versant?

En savoir plus sur le projet et les faits à l'aide d'une réponse (laissez-moi savoir si vous avez besoin de plus):

• Très petite équipe, OODB presque jamais utilisé.
• Projet utilise NHibernate 2.
• A propos de la couverture de test de 75%.
• application ASP.NET MVC.

À ce stade, je ne pouvais pas justifier l'interrupteur en raison des points suivants (le plus lié à db4o, pas grand public OODB Versant):

• outillage est assez mauvais comparant au monde SGBDR où il y a des tas « gestionnaires », profileurs, outils d'intégration / migration et d'autres;
• la documentation est assez basique de ce que je peux observer et fortement mélangé avec Java;
• pas tant de ressources sur le net à comparer SGBDR;
• passer à d'autres bases de données peut être problématique (par opposition à SGBDR);
• courbe d'apprentissage pour les développeurs et l'équipe IT;
• coût de licence supplémentaire;
• coût d'entretien supplémentaire;
• pas d'intégration avec MSDeployment (y compris les sauvegardes automatiques, MSBuild, emballage, etc.);

Answer 1

Voici un commentaire par un utilisateur réel qui passe de SQL Server 2005 à Versant:

Voici les commentaires de de moi et mes collègues sur VOD.Net.

Je regroupé mes idées en avantages et les inconvénients

PROS: (En un mot: vitesse)

• Le moteur de base de données est rapide pour la lecture des données et écrit, de ce que nous avons fait, il est d'environ 5 à 10 fois plus rapide que SQL Server 2005
• réduire la quantité de code nécessaire pour faire même chose que les normes d'accès aux données technologies de couche
• réduire également le temps de développer de nouvelles fonctionnalités
• Il crée une structure d'objets stricte et qui facilite l'intégrité des données
• importer des données dans VOD est facile

CONS: (en un mot: besoin de compétences de dépannage)

• Notre principal point négatif est sur les outils d'administration la facilité d'utilisation (console d'administration et inspecteur d'objets)
• Boutons / Liens pas tout à fait explicite sur ce qu'ils font, nous figurons habituellement quand nous essayons de l'utiliser
• erreurs de compilation / Versant mise à jour la base de données ne sont pas assez explicites, nous savons à peine ce classe la cause de l'erreur, mais pas la raison, nous avons donc besoin de déboguer par nous-mêmes.
• Utilisation Vérifiez option de menu de base de données ne pourrait pas fonctionner et montrera des erreurs (En fonction du temps)
• Migration d'applications
• Lors de la migration d'une application de modèle de DAL, il est temps pour le faire fonctionner avec VOD si vous essayez de garder le même code pour l'interface utilisateur

En résumé, je vous recommande d'utiliser VOD.Net pour les entreprises ayant des compétences seniors développeurs et structures de données complexes / grande. Il est certainement plus rapide de créer toute nouvelle application que la migration application existante. L'inspecteur d'objets ont besoin d'une nouvelle conception pour être plus facile à utiliser.

Nous avons répondu à certaines des préoccupations de l'inspecteur d'objets en fournissant un soutien LINQPad. Je pense que vous devriez prendre la décision de passer en fonction des avantages techniques et non sur toute discussion émotionnelle. En outre, un partenaire est Versant Microsoft, et il y a beaucoup de possibilités pour les personnes avec un bon OO ou non des compétences Versant.

Answer 2

dépend de vous de modèle d'objet. Si vous avez affaire à un objet graphique profond dans votre domaine avec des relations hiérarchiques complexes, vous bénéficiez grand temps en passant de SQL Server 2008 à ODB Versant. Si vous traitez avec des bâtons d'objets plats à un moteur relationnel. S'il vous plaît vérifier les résultats du c / dans www.polepos.org: http://polepos.sourceforge.net/results/PolePositionClientServer.pdf

Answer 3

Vous avez oublié .... Il va probablement me beaucoup plus rapide (mais dépendra de votre modèle. Si vous avez modèle simple, je vous recommande juste bâton avec RDB).

Si vous avez beaucoup à tout, les relations récursives, sous-graphes imbriqués, etc ... alors si sera beaucoup plus rapide.

Bien sûr, il sera également fonctionner sur beaucoup moins de matériel. Des études avec IBM montrent que vous économiserez environ 50% du CPU dans votre niveau intermédiaire (par exemple vous Webservers où tous les happend de traduction de type pour le RDB).

En outre, vous ne pas besoin d'un expert de la base de données .. si vous êtes un OO gars, alors vous avez déjà l'ensemble des compétences ... surtout si vous connaissez Hibernate / NHibernate parce que les concepts de gestion du cycle de vie des objets de mise en veille prolongée et la l'espace ORM ont été essentiellement pris en otage dans le monde OODB et porté au camp de RDB.

En outre, vous pouvez itérer beaucoup plus rapide dans vos cycles de développement sans avoir à passer constamment à un DBA et demander des mises à jour de schéma.

.... RDB finira par prendre le chemin de l'ordinateur central. Toujours autour, mais ne sont pas utilisés pour les nouveaux projets. Les programmeurs de Cobalt ne croient pas à l'époque non plus ... donc ne vous embêtez pas avec toutes les na-Sayers.

Answer 4

Si vous voulez changer puis le faire. Ceci est votre seul point « plus ».

« se débarrasser de désadaptation d'impédance objet-relationnel que nous sommes tous si fatigués de. »

Vous avez énuméré la plupart des négatifs déjà. Je vais ajouter deux autres:

• comment les emplois peuvent demander à jamais des compétences OODB Versant?
• Combien de développeurs auront des compétences OODB Versant?

Answer 5

Dans la communication, je travaille pour Versant dans les ventes, et de faire des commentaires à vos questions, Versant est un produit commercial, mais comme SQL Server, nous avons des prix similaires, Community Edition est gratuit avec limitation sur la taille de la base de données, Standard Edition est un petit coût par serveur, mais limité dans le nombre de threads autorisés, et une édition entreprise qui est cher, mais moins de SQL server ou Oracle si vous avez besoin d'évolutivité et de performance. En outre, en se déplaçant de NHibernate LINQ vous serez en mesure d'utiliser pour la base de données Versant, et dans l'avenir si vous voulez revenir à SQL Server, vous pouvez donc le faire assez facilement avec EF ou LINQ to SQL, il atténue votre risque dans l'infrastructure de base de données. Ce serait un point pour plutôt que d'utiliser Versant un magasin KVP NoSQL avec une interface prorprietary. Certes, beaucoup moins que la documentation Relational, mais www.odbms.org a une certaine grande information et de référence. La courbe d'apprentissage si votre équipe est compétent en C # devrait être assez facile, et du point de vue de l'administration, est une base de données Versant, afin d'apprendre les procédures de sauvegarde et de restauration devraient sembler familiers. Nos clients, C ++, Java ou .Net, disent tous les avantages de Versant sont la facilité de développement, la performance et la capacité de subvenir à leurs besoins avec une faible quantité de ressources dans les serveurs et le stockage.