Progettazione di database per il monitoraggio dello stato di funzionalità delle applicazioni

Question

Sto creando il database per il monitoraggio dello stato di funzionalità delle applicazioni. La logica è la seguente:

Ogni applicazione ha una propria, specifica lista di funzionalità che sto monitoraggio. Ogni funzionalità appartiene ad una sola applicazione. C'è un tavolo funzionalità che ha chiave esterna per Application

Ogni applicazione funziona su una o più macchine. Ogni macchina può eseguire una o più applicazioni. Questo è il collegamento MTM, per cui v'è collegamento Tabella ApplicationInstance Applicazioni con Macchine.

Il monitoraggio reale è di circa l'interrogazione ApplicationInstance. Se c'è un problema, informazioni su di esso va a AppInstanceError tavolo, wich detiene chiave esterna ApplicationInstance. Se la query è successo, si ottiene un elenco degli stati di ogni funzionalità. Così abbiamo un tavolo FunctionalityStatus con chiavi esterne a ApplicationInstance e funzionalità.

Credo che questo è una specie di cattiva progettazione - perché dobbiamo multipla riferimento alla domanda? Che cosa garantisce che sia punterà alla stessa domanda? O c'è un modo per garantire questo?

Quindi, la mia proposta di correzione è quello di collegare FunctionalityStatus con chiavi esterne per macchine e funzionalità. Ma in questo caso essi definiscono ApplicationInstance quindi qual è la garanzia di avere ApplicationInstance per ogni coppia? Non dovrebbero essere collegati in qualche modo? Nel esiste la connessione mondo reale ed è evidente, così è OK non avere in banca dati?

C'è un "modo propper" di risolvere questo problema, o di garantire connessioni invisibili, dalla progettazione dei dati?

Per renderlo più chiaro ho preparato progettazione di DB che ho adesso:

L'unica cosa che manca è una connessione da FunctionalityStatus to Machine. Vedo due modi ow effettuare una tale connessione:

1. Aggiungi chiave esterna per ApplicationInstance - poi i miei dubbi sono:
   • Come assicurarsi che ApplicationId dalla funzionalità è la stessa che uno da ApplicationInstance?
   • Isn questa duplicazione dei dati davvero bisogno?
2. Aggiungi chiave esterna alla macchina - e dubbi:
   • Ci sarà un record propper ApplicationInstance per ogni record FunctionalityStatus?
   • Se c'è un collegamento evidente tra ApplicationInstance e FunctionalityStatus (menzionato nel primo dubbio) WHU non possiamo vederlo in database?
   • Anche in questo caso la ridondanza dei dati siccome tutti i record ApplicationInstance sono (o dovrebbero essere) visibile nella tabella FunctionalityStatus

O forse l'intero design è avvitato su e mi dovrebbe capire qualcosa di totalmente diverso?

Answer 1

Il tuo disegno sembra che vada bene a me. Vorrei andare per l'opzione 1, l'aggiunta di una chiave esterna da FunctionalStatus a ApplicationInstance.

Se si vuole garantire che FunctionalStatus e ApplicationStatus si riferiscono alla stessa applicazione, è possibile aggiungere un nuovo FunctionalStatus.ApplicationId colonna e rendere la chiave esterna da FunctionalStatus a ApplicationStatus includere ApplicationId. Allo stesso modo per la chiave esterna da FunctionalStatus a Functionality.

In altre parole, qualcosa come

CREATE TABLE application
    ( application_id          INT PRIMARY KEY
    /* Other columns omitted */
    );
CREATE TABLE application_instance
    ( application_instance_id INT PRIMARY KEY
    , application_id          INT REFERENCES application(application_id)
    , machine_id              INT REFERENCES machine(machine_id)
    /* Other columns omitted */
    );
CREATE TABLE functionality
    ( functionality_id        INT PRIMARY KEY
    , application_id          INT REFERENCES application(application_id)
    /* Other columns omitted */
    );
CREATE TABLE functionality_status
    ( functionality_status_id INT PRIMARY KEY
    , application_id          INT REFERENCES application(application_id)
    , functionality_id        INT /* Part of composite foreign key, see below */
    , application_instance_id INT /* Part of composite foreign key, see below */
    /* Other columns omitted */
    FOREIGN KEY (functionality_id, application_id) 
      REFERENCES functionality(functionality_id, application_id)
    FOREIGN KEY (application_instance_id, application_id) 
      REFERENCES application_instance(application_instance_id, application_id)
    );

Answer 2

Il problema più grande si potrebbe avere è che è sempre possibile avere lo stesso ID istanza per due diverse istanze della stessa applicazione sulla stessa macchina. La non può essere allo stesso tempo, gli ID di istanza vengono riutilizzati nel corso del tempo e c'è una piccola possibilità che la vostra applicazione otterrà di nuovo la stessa.

Quando faccio questo genere di cose, assegno ogni applicazione un GUID quando comincia che rende impossibile avere due applicazioni con lo stesso GUID e poi usare quella GUID per i rapporti. Non hanno nemmeno bisogno di avere le informazioni sulla macchina nel rapporto come ogni macchina non potrà mai fare lo stesso GUID come qualsiasi altra macchina.

Mi sono reso conto dopo aver risposto a questa che ho davvero non ho risposto la vostra vera domanda. Se stai cercando di vedere se alcune funzionalità sta lavorando in un certo modo, è meglio collegata alla macchina e l'applicazione in cui la funzionalità non sta andando nel modo desiderato o avete ritrovamento difficoltà a cui si sta lavorando a destra e che quella sbagliata.

Avere tre tavoli uno per le macchine, una per le applicazioni e uno per la funzionalità sarebbe la migliore progettazione di database. A seconda di cosa si sta facendo, potrebbe essere più facile e più veloce per il software di duplicare tutti i dati delle applicazioni e la macchina per ogni set di funzionalità di cui si sta lavorando, in particolare se le informazioni sulla macchina e l'applicazione è solo un campo comunque. Davvero non si vuole rallentare la funzionalità per la registrazione di queste informazioni se si può farne a meno, così si vuole farlo fare in fretta.

Answer 3

Se mi è stato questo è come lo farei:

1. Crea 5 tavoli, macchina, Applicazione, Funzionalità, ApplicationPool, e Log.
2. Mettere una colonna FK in termini di funzionalità, che è l'ID della domanda esiste la funzionalità per.
3. ApplicationPool avrebbe una macchina colonna ID, una colonna ID applicazione, Chiave primaria che risultano essere un GUID o Testa di serie un'identità, un ApplicationInstance ID che avrebbe essere il vostro ApplicationName + PK. Se è possibile questo è ciò che vorrei utilizzare per chiamare le vostre applicazioni vostre macchine.
4. Infine, vorrei fare la tabella di registro e dare una colonna FK che fa riferimento la PK di ApplicationPool. Poi ogni volta che ci si collega qualcosa che si potrebbe aggiungere alla tabella di log e tutte le informazioni circa l'applicazione sarebbe essere conservati separatamente.

Se questo non è vicino fatemi sapere perché potrei aver frainteso quello che stai cercando.