{"id":34734,"date":"2019-10-31T22:00:06","date_gmt":"2019-10-31T19:00:06","guid":{"rendered":"https:\/\/prohoster.info\/blog\/sravnenie-i-vybor-sistem-migratsii-dannyh\/"},"modified":"2019-10-31T22:00:06","modified_gmt":"2019-10-31T19:00:06","slug":"sravnenie-i-vybor-sistem-migratsii-dannyh","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/sravnenie-i-vybor-sistem-migratsii-dannyh","title":{"rendered":"Confronto e scelta dei sistemi di migrazione dei dati","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Confronto e scelta dei sistemi di migrazione dei dati<\/h2>\n

\n\"Confronto
\n
\nIl modello dei dati in fase di sviluppo \u00e8 soggetto a cambiamenti e a un certo punto pu\u00f2 smettere di corrispondere al database. Certamente, \u00e8 possibile eliminare il DB, e in tal caso l'ORM creer\u00e0 una nuova versione che sar\u00e0 in linea con il modello, ma questa procedura porter\u00e0 alla perdita dei dati esistenti. Pertanto, la funzione del sistema di migrazione \u00e8 quella di sincronizzare la scheda con il modello dei dati nell'applicazione a seguito di cambiamenti, senza perdere i dati esistenti.<\/p>\n

In questo articolo, desideriamo esaminare vari strumenti per la gestione delle migrazioni dei database. Speriamo che questa panoramica sia utile per gli sviluppatori che si trovano di fronte a questa scelta.
\n<\/a><\/noindex><\/p>\n

Compito<\/h3>\n

\nNella nostra azienda stiamo attualmente sviluppando attivamente la prossima generazione del prodotto \u2013 Docs Security Suite (DSS). La parte server \u00e8 scritta in .Net Core e il database utilizzato \u00e8 Entity Framework Core. Durante la progettazione dell'applicazione, adottiamo l'approccio Code First.<\/p>\n

Il modello a dominio dell'applicazione \u00e8 creato contemporaneamente da pi\u00f9 sviluppatori, ognuno dei quali \u00e8 responsabile per la propria parte logica del sistema. <\/p>\n

Nella precedente generazione di DSS, il sistema di gestione delle migrazioni utilizzava le classiche Migrations di Entity Framework (EF 6). Tuttavia, ci sono state alcune lamentele su di esso, la principale delle quali riguardava l'assenza di un approccio ragionevole alla risoluzione dei conflitti di versione in EF. Questo fatto ci preoccupa ancora durante il bug fixing nell'ambito del supporto, quindi \u00e8 stata presa la decisione di esplorare opzioni alternative.<\/p>\n

A seguito della discussione, sono emerse le seguenti esigenze per il sistema di gestione delle migrazioni:<\/p>\n

    \n
  1. Supporto per diversi DBMS. \u00c8 necessario MS SQL Server, PostgreSQL, Oracle, ma \u00e8 potenzialmente possibile l'uso di altri.<\/li>\n
  2. Collaborazione con ORM. Inizialmente si prevedeva di utilizzare EF Core, ma durante la fase di progettazione eravamo pronti a considerare anche altri ORM.<\/li>\n
  3. Generazione automatica delle migrazioni. Data la progettazione Code First, ci piacerebbe evitare di 'scrivere a mano' le migrazioni.<\/li>\n
  4. Conflitti di versione. Nello sviluppo distribuito, durante il merging, EF Core pu\u00f2 incorrere in conflitti. Questo diventa un problema significativo, dato che diverse parti dell'applicazione vengono create da sviluppatori diversi, portando a una notevole perdita di tempo su ciascun conflitto.<\/li>\n
  5. Documentazione e supporto avanzati. Qui, non servono ulteriori spiegazioni.<\/li>\n
  6. Gratuit\u00e0. Questo criterio \u00e8 soggettivo, poich\u00e9 siamo anche pronti a considerare sistemi economici o costosi ma eccellenti in termini di usabilit\u00e0.<\/li>\n<\/ol>\n

    \nDopo una breve ricerca, sono stati trovati e considerati desiderabili i seguenti opzioni:<\/p>\n

      \n
    1. Migrazioni di EF Core<\/li>\n
    2. DBup<\/li>\n
    3. RoundhousE<\/li>\n
    4. ThinkingHome.Migrator<\/li>\n
    5. Fluent Migrator <\/li>\n<\/ol>\n

      <\/p>\n

      E ora in modo pi\u00f9 dettagliato<\/h3>\n

      \n\"Confronto
      \n      Migrazioni di EntityFramework Core<\/a><\/noindex><\/b><\/p>\n

      Naturalmente, questa \u00e8 stata la prima e principale opzione da considerare. Uno strumento nativo, funzionante out-of-the-box senza alcun passaggio complicato. Ampia documentazione, ufficiale e non, semplicit\u00e0, ecc. Tuttavia, le critiche mosse a EF classico sono del tutto valide anche per EF Core. <\/p>\n

      Pertanto, EF Core presenta i seguenti vantaggi:<\/p>\n