Creazione di una struttura di menu usando DB - va bene?

Il tuo menu è essenzialmente un albero, quindi potrebbe essere memorizzato in una singola tabella del database:

ID (number, not null)
PARENT_ID (number, can be null)
DESCRIPTION (text)

dove PARENT_ID è null per le voci di menu di primo livello.

Potresti aver bisogno di una o più colonne aggiuntive per mantenere il comportamento che desideri associare agli elementi del menu (ad esempio, ID azione, nome comando o URL).

Tenere i dati di configurazione come questo esternamente al codice dell'applicazione è abbastanza comune. Poiché devi mantenere queste informazioni da qualche parte, un RDBMS è valido come ovunque, specialmente se l'applicazione utilizza già il DB per i dati "reali".

Avere cinque tavoli per i tuoi presunti cinque livelli di menu non è una buona idea. È inflessibile e puoi ragionevolmente aspettarti che questo cambi nella vita del sistema.

Esistono diversi modi per archiviare insiemi di dati collegati in una struttura relazionale. Ho trovato questo post dopo una breve ricerca. Discute diverse possibilità. Almeno ti darà il vocabolario per fare ricerche più approfondite. Quello che meglio si adatta alle tue circostanze dipenderà dal numero di righe che desideri memorizzare, dalla velocità con cui cambiano e dalle capacità di programmazione della tua squadra.

Generalmente il trattamento di voci di menu come dati è una grande idea. E, se gli utenti finali gestiscono il menu come in un CMS, puoi fare un ottimo argomento per archiviare i menu nel database. Ma se gli utenti finali non se ne stanno occupando, prenderemo seriamente in considerazione la possibilità di gestirli come dati ma in codice piuttosto che in un negozio esterno.

La meccanica di base qui - e non diventerò specifica dato che non abbiamo un'indicazione sulla piattaforma - sarebbe quella di definire una struttura dati per le voci di menu in base ai requisiti e quindi definire staticamente i dati di menu come globali variabile di un tipo appropriato. Questo in genere non è orribilmente difficile da modificare con i moderni ambienti di sviluppo e dovresti avere a disposizione un po 'di continui lavori per portarlo rapidamente nelle mani del cliente. Ottieni anche la tracciabilità delle modifiche dal controllo del codice sorgente.

Questo è tutto molto bello, ma il vantaggio maggiore è che non è necessario pagare la "tassa" del database se lo si desidera, soprattutto se i dati sono comunque definiti in modo statico dagli sviluppatori. L'imposta arriva elaborando come aggiornare il database con la versione corretta dei dati. Entra in possesso di un database in esecuzione per dare dei calci alle gomme e testare le cose. Si tratta del codice difensivo che scrivi perché le denunce della contabilità che hanno accesso al server DB possono ora modificare le cose nel menu in modi imprevedibili.

C'è molto meno overhead e molto meno coinvolto nell'utilizzo di un grafo di oggetti per la sua archiviazione nel DB. Inoltre, se hai bisogno di memorizzarlo nel DB (o in un'altra fonte esterna come un file di configurazione), devi solo modificare il modo in cui viene caricato nel grafico dell'oggetto - il codice client rimane lo stesso.

Non dovresti MAI mantenere queste cose nel DB. Esistono altri luoghi in cui è possibile memorizzare le informazioni. Estrarre i dati dal DB è costoso e la soluzione migliore sarebbe archiviarlo come XML o anche classe separata e includere quell'oggetto in altre classi. Quindi dovresti solo cambiare il codice su un posto E eviteresti di torturare il tuo DB.