Dove mettere la tabella del paese?

La risposta potrebbe essere più semplice di quanto si pensasse inizialmente: sostituire la tabella "Paesi" condivisa tra app monolitiche basate su database con un microservizio o semplice servizio web che espone la stessa funzionalità a una semplice chiamata REST (nota: I ' m suggerendo REST anche se non è la tua unica opzione, anche se è probabilmente l'opzione più leggera).

L'esempio del tuo paese è un'opportunità perfetta per estrapolare parte della logica "database" centrale delle tue applicazioni in un semplice schema di un servizio web. Penso che la tua reazione istintiva all'idea che la stessa tabella esista in ogni schema spenga correttamente l'avviso DRY - stai letteralmente ripetendo te stesso non solo in termini di schema dati, creazione, manutenzione ecc. Del livello dati (il minimo possibile be) ma anche in termini di logica di accesso ai dati.

Ci sono alcuni vantaggi significativi di questo approccio e alcuni svantaggi da considerare prima di prendere la decisione finale.

Svantaggi :

1. Microservizi e manutenzione: ovviamente il mantenimento delle implementazioni di produzione e messa in scena di un sistema basato sui servizi sarà diverso e probabilmente più costoso in un primo momento rispetto a quello che il vostro team ha già acquisito in termini di soluzioni incentrate sul database. Più c'è l'intero bit "versioning" :

   Once a microservice makes an endpoint public, subsequent development must pay the cost of either supporting multiple versions of services or the deployment of services in sync. Microservices, in this sense, increase the maintenance cost of a software system by increasing the number of published API endpoints.

2. L'articolo sopra riportato sottolinea anche correttamente che questo approccio specifico può introdurre la complessità dei sistemi distribuiti avanzati per le applicazioni in cui non esisteva nessuno precedentemente.

3. Avrai anche bisogno di introdurre il supporto per alcune ipotesi addizionali di connettività di rete nelle tue applicazioni che potrebbero avere solo un'assunzione integrata limitata di client-server (app + database) nelle loro attuali incarnazioni. Ciò presuppone anche la gestione della sincronizzazione temporale a un certo livello, almeno per quanto riguarda la distribuzione delle modifiche e il supporto di più versioni per la compatibilità all'indietro.

4. Anche le prestazioni sono un'altra preoccupazione. Sebbene in generale i microservizi più piccoli possano essere più facilmente ottimizzati, il meccanismo che impiegano per fornire i propri dati tramite i servizi Web è diverso dai meccanismi attualmente utilizzati per le app del server client e richiede un set di competenze e un insieme di tecniche diverse da ottimizzare. Può essere fatto, ma può aumentare la complessità o il tempo di consegna almeno alla prima iterazione .

vantaggi :

1. I microservizi sono qui per restare. I monoliti non vanno esattamente da nessuna parte, ma la tendenza è verso monoliti più piccoli, non più grandi. Potresti anche iniziare da qualche parte in modo facile sia per gli sviluppatori che per imparare e anche per il business assumere il minimo rischio con i premi più facili.

2. La scomposizione in Microservices rende l'applicazione più semplice da testare e mantenere nel tempo, anche se la complessità aumenta. Questa complessità è più facile da gestire tramite l'automazione rispetto ai monoliti: è un compromesso. Devi padroneggiare l'automazione, ma ci sono così tanti vantaggi a quel processo che a malapena sembra un negativo .

3. Parlando di automazione, anche le implementazioni diventano più semplici. Così fa mantenere più ambienti sincronizzati e ambienti di sviluppo / test / staging che sono repliche esatte della produzione. L'ulteriore vantaggio di non dover gestire il tipo di problema "funziona sul mio sistema" è un bel extra, ma lo è anche l'intera cultura DevOps che puoi iniziare a sviluppare all'interno e intorno al tuo sistema ora. Anche Martin Fowler è d'accordo !

4. Ho anche concordato con questo post che suggerisce che l'approccio del microservizio sia più strettamente allineato sia con gli obiettivi di business sia con le capacità oltre a ridurre la ridondanza a scapito di un po 'più di complessità. Tieni a mente che build, testing e deployment tenderanno a verificarsi più rapidamente con questo modello e le efficienze probabilmente inizieranno a pagare la complessità extra introdotta in pochissimo tempo.

5. Man mano che aumenta il numero di microservizi, aumenta anche la complessità e i costi di gestione complessivi della tua app. Questo è senza dubbio vero , ma in realtà è perfettamente buono giustificazione per l'avvio con un singolo microservizio, padroneggiando le competenze necessarie per sviluppare, integrare e mantenere uno nello stack e quindi espandersi da lì in opposizione a un vero motivo per rifiutare l'approccio.

Entrambi

Avere una tabella centrale controllata con:
ID int PK
Codice varchar

Quindi lascia che l'app abbia una tabella con:
ID PK FK a centrale
aggiungi tutte le colonne di flag che vuoi

In questo modo hai ancora una colonna per il codice

Un'altra opzione è una tabella app
countryID
FlagID
Valore

In questo modo le tue colonne diventano righe
Il problema che hai qui è riscrivere molte query