Entity Framework : Code First avec Migration 2/2

La 1ère partie de l’article concernait l’implémentation de Code First Migration.

Dans cette 2ème partie d’article sur La migration Entity Framework, nous allons voir:

  • Comment insérer ou mettre à jour des données en même temps que les changements de la structure de la base de données.
  • Configurer la migration pour qu’elle s’effectue automatiquement.
  1. Migration sur les données

    Dans la classe de configuration qui a été créé lors de l’activation de la migration, il y a une méthode Seed (créé par défaut) qui va permettre d’insérer des données.

    En effet lors des migrations il se peut que le (ou les) tables doivent être détruites pour être reconstruite, donc éviter de perdre des données il est possible de insérer dans la configuration de migration.

    Pour cela il faut utiliser la méthode AddOrUpdate qui a pour avantage de ne pas faire uniquement des insert mais s’il l’enregistrement existe déjà elle fera un update (ca évide donc d’avoir des doublons).


    Il y aussi une autre possibilité c’est d’utiliser un script SQL, et de l’exécuter dans la méthode seed, par exemple :

  2. Migration automatique

    La migration automatique permet d’appliquer automatiquement les changements à la base de données lors de l’exécution de l’application.

    Pour l’activer il faut:

  • modifier la propriétés AutomaticMigrationsEnabled et la renseigner à true, et rajouter une autre propriété AutomaticMigrationDataLossAllowed = true car la migration automatique ne permet pas la perte de données. On a donc dans la configuration :


  • Implémenter la méthode OnModelCreating:

    Dans la classe configuration il faut rajouter une méthode OnModelCreating avec :

    Database.SetInitializer(new MigrateDatabaseToLatestVersion<MvcApplicationEFCodeFirst.Models.MvcMusicStoreEntities, Configuration>());

    Ce qui nous donne:


Et voilà lors de l’exécution de l’application, la base de données sera mise à jour à partir du model.
Remarques sur la migration automatique:
La migration automatique peut se révéler pratique dans un cadre de développement, par contre à mon sens elle n’est pas à être utilisée en production car lors de modification de la base des données peuvent être perdues.

[JSS 2013] Session : HEKATON

Présentateur : Christophe Laporte
Niveau : 300

Christophe commence par nous poser la question suivante :

Pourquoi HEKATON ?
L’objectif est d’améliorer la performance des bases de données.

Pour cela, Microsoft commence par analyser comment sont consommées les ressources pendant les différentes transactions dans une base de données SQL Server. Et note donc que les disques Flash sont plus rapides que les disques rotatifs, mais moins rapides que la RAM.

Comment améliorer ?
Le choix effectué est celui de supprimer les éléments suivants :

  • Les latches
  • Les locks

HEKATON, c’est quoi ?
C’est un nouveau moteur SQL Server avec des tables et des indexes en mémoire, une compilation native des procédures stockées, plus de locks ni de latches.

HEKATON est pleinement intégré à SQL Server et l’utilisateur a le choix de migrer ou pas certaines tables en mémoire (c’est-à-dire sur le moteur Hekaton). Ce qui signifie qu’une requête peut utiliser des tables provenant de trois moteurs différents.

Durabilité des transactions :
Les trois options sont les suivantes :

  • Schema_And_Data (option par défaut)
  • Schema_Only (plus performant que schema_And_Data)
  • Delayed_Durability

Pendant les démonstrations, on note les points importants ci-dessous :

  • Collation : la collation est importante pendant la création d’une table HEKATON.
  • Memory-Optimized : on doit avoir memory-optimized = ON
  • Chaque transaction a un Begin TimeStamp et un End TimeStamp

Gestion des indexes :
Les indexes ne sont présents qu’en mémoire avec au moins 1 indexe et 8 indexes maximum.

On note deux types d’indexes : Hash et Range.

Conclusion :
HEKATON apporte un gain réel au niveau de la performance.

Ghislain – Consultant décisionnel MCNEXT