ID database predefiniti;valori del sistema e dell'utente

Question

Nell'ambito del nostro attuale lavoro sui database, stiamo esaminando la gestione del processo di aggiornamento dei database.

Un punto che è stato sollevato ripetutamente è quello del confronto tra sistema e sistema.valori dell'utente;nel nostro progetto le valori utente e di sistema sono archiviate insieme.Per esempio...

Abbiamo un elenco di modelli.

1, <system template>

2, <system template>

3, <system template>

Questi sono mappati nell'app su un enum (1, 2, 3)

Poi arriva un utente e aggiunge...

4, <user template>

...E...

5, <user template>

Poi..rilasciamo un aggiornamento..e inseriscilo come parte dei nostri script di aggiornamento...

<new id> [6], <new system template>

POI!!...troviamo un bug nel nuovo modello di sistema e dobbiamo aggiornarlo...Il problema è come?Non possiamo aggiornare il record utilizzando ID6 (poiché potremmo averlo inserito come 9 o 999, quindi dobbiamo identificare il record utilizzando qualche altro meccanismo)

Quindi, siamo arrivati ​​a due possibili soluzioni per questo.

Nell'angolo rosso (velocità)....

Iniziamo semplicemente gli ID utente da 5000 (o qualche altro valore) e testiamo i dati da 10000 (o qualche altro valore).Ciò ci consentirebbe di apportare modifiche ai valori di sistema e di testarli fino al limite inferiore dell'intervallo ID successivo.

Vantaggio... Veloce e facile da implementare,

Svantaggio...potremmo esaurire i valori se non scegliamo un intervallo abbastanza ampio!

Nell'angolo blu (scalabilità)...

Archiviamo i dati del sistema e dell'utente separatamente, utilizziamo i GUID come ID e uniamo i due elenchi utilizzando una vista.

Vantaggio...Scalabile...Nessun limite per quanto riguarda la dimensione del DB.

Svantaggio..Più complicato da implementare.(viste aggiornabili da molte a una ecc.)

---

Io scelgo decisamente la prima opzione, ma sto cercando delle munizioni per sostenermi!

Qualcuno ha qualche idea su questi approcci, o anche su uno o più che ci siamo persi?

Answer 1

Non ho mai avuto problemi (prestazioni o sviluppo - TDD e test unitari inclusi) utilizzando i GUID come ID per i miei database e ho lavorato su alcuni piuttosto grandi.Dare un'occhiata Qui, Qui E Qui se vuoi saperne di più sull'utilizzo dei GUID (e sui potenziali GOTCHAS coinvolti) come chiavi primarie, ma non posso raccomandarlo vivamente poiché spostare i dati in modo sicuro e la sincronizzazione del DB diventa facile come lavarsi i denti al mattino: -)

Per la tua domanda sopra, consiglierei una terza colonna (se possibile) che indichi se il modello è o meno basato sull'utente o sul sistema, oppure puoi almeno generare GUID per i modelli di sistema mentre li inserisci e mantenere un elenco di quelli a portata di mano, in modo che se è necessario aggiornare il modello, è possibile semplicemente indirizzare lo stesso GUID nei database DEV, UAT e/o PRODUZIONE senza timore di sovrascrivere altri modelli.La terza colonna sarebbe utile per selezionare tutti i modelli di sistema o utente a piacimento, senza la necessità di separarli in due tabelle (questo è eccessivo IMHO).

Spero che aiuti,

RobG

Answer 2

Consiglio di utilizzare il secondo con la modifica di memorizzare i valori di sistema e utente in un'unica tabella.GUID è abbastanza affidabile in questo modo.

Un'altra idea:utilizzare qualsiasi ID basato su testo (non necessario GUID), fornito per i valori di sistema e generato da una stringa casuale o da una stringa basata su un tipo di logica personalizzata per i valori utente.

Un'altra idea:usa il primo approccio, ma estendi la tabella con un flag che mostra se un valore è di sistema o utente.Forse questo è il più semplice.Ok, devi scrivere una sorta di meccanismo per aggiornare il valore di sistema corretto, ma può essere fatto facilmente.

Answer 3

+1 per l'ID basato su testo di Biri: definisci una colonna basata su testo "template_mnemonic" e rendila la chiave primaria.Questo sarà un valore noto quando lo inserirai come te, gli sviluppatori lo avranno deciso (o lo genereranno automaticamente) e sarai sempre in grado di fare riferimento a un modello tramite il suo mnemonico indipendentemente dal numero di modelli specificati dall'utente che esistono.Consente inoltre agli utenti di avere una convenzione di denominazione significativa per i propri modelli.

Answer 4

Forse non ho capito, ma non potresti utilizzare i GUID come ID e avere comunque insieme i dati utente e di sistema?Quindi è possibile accedere ai dati di sistema tramite i GUID (non modificabili).

Answer 5

Non penso che il GUID dovrebbe creare problemi.

Se vuoi evitarlo, usa un flag:

ID int

modello qualunque

flag enum/int/bool

Il flag mostra se il valore effettivo è un valore di sistema o un valore utente.

Se desideri aggiornare un valore di sistema, chiedi solo i valori di sistema ordinati per ID e ti mostrerà l'effettivo ordine di inserimento (dovresti avere un bigint o qualcosa per l'ID per assicurarti che non si riempia e non ripristina il funzionamento degli ID eliminati).Con questo elenco il x.il record è x.valore di sistema inserito.

Answer 6

Penso che ci sia una terza soluzione migliore.Mi colpisce che stai memorizzando due cose diverse nella stessa tabella e che potrebbe essere meglio creare 2 tabelle separate una per i modelli utente e una per i modelli di sistema.Potresti quindi essere in grado di creare una vista sulle due tabelle per farle apparire come un singolo oggetto nella tua applicazione.Ovviamente non ho una conoscenza completa della tua applicazione e questo potrebbe essere impossibile per te per una serie di motivi, ma penso che sia una soluzione più accurata dei GUID e molto più sicura degli intervalli di ID (sul serio, non fare intervalli di ID, lo farà morderti un giorno)