Stavo discutendo con il mio collega su come implementare una funzione dashboard in un sito web. Supponiamo che un utente possa creare una dashboard, che contiene più gadget nel sito web. Abbiamo pianificato di aggiungere altri gadget in un secondo momento e consentire agli utenti di personalizzare di più su ciascun gadget, ad esempio la formula per calcolare i dati del grafico a torta, se la funzionalità del dashboard ha avuto esito positivo.

La mia domanda è: quale approccio è migliore per la mia situazione e perché (oltre ai motivi che ho già fornito)?

Il mio approccio al collega

Il mio collega propone di memorizzare i dati nello schema seguente.

CREATE TABLE dashboards (
    id INT NOT NULL PRIMARY KEY,
    name VARCHAR(50) NOT NULL
);


CREATE TABLE gadgets (
    id INT NOT NULL PRIMARY KEY,
    parent_id INT NULL,
    dashboard_id INT NULL,
    category VARCHAR(10) NOT NULL,
    title VARCHAR(100) NULL,
    db_view_name VARCHAR(50) NULL,
    -- More columns omitted...
);

Quando il sito web ha 3 tipi di gadget e gli utenti hanno già creato 2 dashboard con 2 gadget in ogni dashboard, il database memorizzerà le seguenti informazioni.

-------------------------
| Table dashboards      |
-------------------------
| id | name             |
-------------------------
|  1 | Dashboard Gender |
|  2 | Dashboard Score  |
-------------------------

------------------------------------------------------------------------------------------
| Table gadgets                                                                          |
------------------------------------------------------------------------------------------
| id | dashboard_id | parent_id | title             | category | db_view_name      | ... |
------------------------------------------------------------------------------------------
|  1 |       (null) |    (null) | Pie Chart Gadget  | CHART    | vw_student_gender | ... |
|  2 |       (null) |    (null) | Line Chart Gadget | CHART    | vw_student_score  | ... |
|  3 |       (null) |    (null) | Welcome Gadget    | HTML     | (null)            | ... |
|  4 |            1 |         1 | My Pie Chart      | CHART    | vw_student_gender | ... |
|  5 |            1 |         3 | My Welcome Text   | HTML     | (null)            | ... |
|  6 |            2 |         3 | My Welcome Text   | HTML     | (null)            | ... |
|  7 |            2 |         2 | My Line Chart     | CHART    | vw_student_score  | ... |
------------------------------------------------------------------------------------------

Il mio collega la pensa così:

1. Quando si aggiunge un nuovo gadget della categoria CHART, solo lo sviluppatore è necessario inserire un record nel database, creare una vista tabella e tutto viene generato automaticamente senza alcuna modifica del codice e riavvio del server Web, solo modifica laterale del database. L'elenco dei gadget visualizzati dall'utente per la selezione è semplice quanto la query SQL con WHERE parent_id IS NULL .
2. Richiede solo l'aggiornamento del campo del database per modificare il valore predefinito di titolo del gadget o qualsiasi altro parametro come SQL utilizzato recupera i dati dalla vista tabella.
3. Consenti agli utenti di personalizzare in molti dettagli in futuro, perché quasi tutto ciò che riguarda un gadget è memorizzato nel database, non abbiamo bisogno di modifiche nello schema del database per supportare la personalizzazione.

Il mio approccio

Per me, penso che lo schema dovrebbe essere così:

CREATE TABLE dashboards (
    id INT NOT NULL PRIMARY KEY,
    name VARCHAR(50) NOT NULL
);

CREATE TABLE gadgets (
    id INT NOT NULL PRIMARY KEY,
    dashboard_id INT NOT NULL,
    title VARCHAR(100) NULL,
    -- More columns omitted...
);

Quando il sito web ha 3 tipi di gadget e gli utenti hanno già creato 2 dashboard con 2 gadget in ogni dashboard, il database memorizzerà le seguenti informazioni.

-------------------------
| Table dashboards      |
-------------------------
| id | name             |
-------------------------
|  1 | Dashboard Gender |
|  2 | Dashboard Score  |
-------------------------

---------------------------------------------
| Table gadgets                             |
---------------------------------------------
| id | dashboard_id | title           | ... |
---------------------------------------------
|  4 |            1 | My Pie Chart    | ... |
|  5 |            1 | My Welcome Text | ... |
|  6 |            2 | My Welcome Text | ... |
|  7 |            2 | My Line Chart   | ... |
---------------------------------------------

Penso che le informazioni come il titolo del gadget predefinito, la vista tabella e SQL che vengono utilizzate per recuperare i dati di origine dovrebbero essere inserite nel codice sorgente. Probabilmente in diverse classi con ereditarietà come class Gadget , class Chart , class PieChart . In tal modo:

1. Possiamo evitare molto% valore diNULL, dati incoerenti e dati duplicati nel database.
2. La modifica delle tracce è più semplice perché le informazioni sono memorizzate nel codice sorgente con controllo della versione.
3. La funzionalità del gadget può essere più flessibile perché non è vincolata dalle categorie e dai campi del database predefiniti utilizzati nell'approccio del mio collega.