Utilisez-vous Schemaexport et SchemaUpdate dans des applications réelles? Initialement, vous créez un modèle, puis générez du schéma? Est-ce que ça marche? Ou, vous n'utilisez que pour les tests ...
Habituellement, je crée dB (à l'aide du projet de base de données Visual Studio), puis des mappages et des classes persistantes ou des entités EF à l'aide de designer. Mais maintenant, je veux essayer la première approche de code avec NHibernate fluide.
J'ai recherché Schemaexport et SchemaUpdate et j'ai trouvé des problèmes. Par exemple, la mise à jour ne supprime pas les objets DB, ne crée pas de colonnes nullables telles que NULLABLABLABLABLABLABLABLABLE, ne génère pas la clé primaire sur plusieurs tables et ainsi de suite. Cela signifie que je dois recréer dB très souvent. Mais qu'en est-il des données? Et comment déployer des modifications apportées à la production DB et ainsi de suite ...
Je veux savoir que vous utilisez vraiment le code d'abord et Schemaexport (SchemaUpdate) dans vos applications? Peut-être que vous pouvez me donner des conseils ...
4 Réponses :
J'utilise SchemaUpdate dans la production. C'est sûr précisément parce que cela ne fait jamais d'opérations destructrices, comme la suppression de colonnes. Cependant, ce n'est pas une solution globale pour mettre à jour votre base de données. Si vous l'utilisez, vous devrez toujours le compléter avec le script pour mettre à jour votre schéma pour faire des choses telles que la suppression (comme mentionner), les index, le type de colonne, l'ajout de données de table, etc. Mais SchemaUpdate couvre le cas de 90%.
Le seul inconvénient que j'ai découvert est que, avec le temps, il semble d'occasion ajouter des contraintes de clé étrangère en double à ma table.
Une dernière chose: vous devez exécuter manuellement SchemaUpdate à partir d'un outil de construction, pas votre application elle-même. Il est pas sûr de donner à votre application les droits de modifier votre schéma de base de données!
Oui, vous pouvez les utiliser dans des applications réelles; Je fais.
Bien sûr, presque tout le travail se passe dans cette première Go. Ma pratique a été de créer un projet distinct qui fait référence aux mappages dans mon ensemble de projet principal et gère la création de la base de données et l'importation initiale des données, le cas échéant.
Une fois que le projet est en production, je décharge habituellement ce projet de la solution, mais le maintient pour référence ou si je devais passer à partir de créer des scripts pour mettre à jour les scripts.
Comme pour la façon dont NHibernate crée la base de données, vous devez faire une petite spécification dans vos mappages fluides que vous ne pourriez autrement. J'aime spécifier des noms de contraintes de clé étrangère null / non nuls, etc. Pour avoir un contrôle maximal sur la manière dont la base de données est créée.
Je ne pense pas que vous voudriez jamais utiliser AutoSappepping dans ce scénario.
J'utilise SchemaUpdate / Schemaexport pour une évolution rapide de mon modèle, mais ils ne remplacent pas un outil de migration de base de données. Comme vous le mentionnez, les données ne peuvent pas être migrées de manière sensible dans de nombreux cas. L'outil n'a pas assez de contexte. (E.G. Comment pouvez-vous automatiquement migrer une colonne FULLNAME en prénom / Nom?) J'ai répondu à une question similaire ici où je discute des outils de migration de DB dans le contexte de NHibernate.
NHibernate, orm: Comment refactoring est-il traité? Données existantes?
Juste avec tout code générateur, qu'il s'agisse de génération de POCO à partir d'un outil ou d'une génération de base de données comme dans votre question, cela vous obtiendra probablement 80% du chemin. À partir de là, il serait sage de le modifier les 20% d'autres pour ajouter vos index et tout autre geste de performance pour l'obtenir juste.