{"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 ha la propriet\u00e0 di cambiare, e a un certo punto smette di corrispondere al database. Certamente, il database pu\u00f2 essere eliminato, e allora l'ORM creer\u00e0 una nuova versione che corrisponder\u00e0 al modello, ma tale procedura porter\u00e0 alla perdita dei dati esistenti. Pertanto, la funzione del sistema di migrazione si riduce a sincronizzare lo schema modificato con il modello dei dati nell'app senza perdere i dati esistenti.<\/p>\n

In questo articolo ci piacerebbe esaminare diversi strumenti per la gestione delle migrazioni dei database. Speriamo che questa panoramica sia utile per i programmatori che si trovano di fronte a una simile scelta.
\n<\/a><\/noindex><\/p>\n

Compito<\/h3>\n

\nAttualmente nella nostra azienda si sta attivamente sviluppando la prossima generazione del prodotto \u2013 Docs Security Suite (DSS). La parte server \u00e8 scritta in .Net Core e come DBMS utilizziamo di conseguenza Entity Framework Core. Nella progettazione dell'app, utilizziamo l'approccio Code First.<\/p>\n

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

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

Dopo una discussione, si sono definiti i seguenti requisiti per il sistema di gestione delle migrazioni:<\/p>\n

    \n
  1. Supporto per diversi DBMS. MS SQL Server, PostgreSQL, Oracle sono obbligatori, ma \u00e8 potenzialmente possibile utilizzare anche altri.<\/li>\n
  2. Lavoro con ORM. Inizialmente si prevedeva l'uso di EF Core, ma durante la fase di progettazione eravamo aperti a considerare anche altri ORM.<\/li>\n
  3. Autogenerazione delle migrazioni. Considerando lo sviluppo Code First, vorremmo evitare la necessit\u00e0 di \"scrivere a mano\" le migrazioni.<\/li>\n
  4. Conflitti di versione. In un contesto di sviluppo distribuito, durante il merging EF Core pu\u00f2 andare in crisi a causa dei conflitti. Questo diventa un problema significativo, poich\u00e9 le diverse parti dell'applicazione vengono create da sviluppatori diversi, e perci\u00f2 si perde molto tempo per ogni<\/li>\n
  5. Documentazione avanzata e supporto. Qui, ci sembra, non siano necessarie spiegazioni.<\/li>\n
  6. Gratuit\u00e0. Il criterio \u00e8 soggettivo, poich\u00e9 sistemi non molto costosi o costosi, ma ideali in termini di comodit\u00e0, siamo comunque stati disposti a considerare.<\/li>\n<\/ol>\n

    \nA seguito di una piccola ricerca sono stati trovati e considerati desiderabili i seguenti opzioni:<\/p>\n

      \n
    1. Migrazioni 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 un po' pi\u00f9 nel dettaglio<\/h3>\n

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

      Naturalmente, questa \u00e8 stata la prima e principale opzione da considerare. Strumento nativo, funzionante 'out of the box' senza alcun rito. Un'enorme quantit\u00e0 di documentazione, ufficiale e non, semplicit\u00e0, ecc. Tuttavia, le critiche rivolte al classico EF sono perfettamente valide anche per EF Core. <\/p>\n

      In questo modo, per EF Core sono stati evidenziati i vantaggi:<\/p>\n