Progettare una singola entità di ricerca

Per implementare questo approccio, devi avere le seguenti colonne:

1. TableID (o una colonna di categorizzazione)

2. Codice

3. Descrizione

4. IsActive (per evitare l'eliminazione)

Assegnerai tableID = 1 per il livello di istruzione, tableID = 2 per il tipo di laurea, ecc.

Problemi:

0 - I valori di ricerca non saranno facilmente condivisibili tra i progetti.

1 - È necessario creare una chiave primaria sulle colonne composte di (TableID e Codice) per garantire l'univocità o avere il codice per colonna generata sequenzialmente. Ciò porterebbe a un FK composito che non è molto bello. In alternativa, puoi aggiungere una colonna artificiale come PK (sequenza automatica per ex.).

2 - Ogni SELECT avrà un ID tabella hard-coded. Questo potrebbe portare a brutti bug.

3 - Be ware per non perdere le relazioni tra le voci. Ad esempio, il livello di istruzione è correlato al tipo di laurea.

4 - Il tuo modello di dati (se ti interessa) non avrà relazioni significative con questa tabella di ricerca poiché alcune voci non saranno applicabili.

Maggiori informazioni sono disponibili in: Perché utilizzare una tabella di ricerca comune per limitare lo stato di entità errata?

In sintesi, se hai una piccola applicazione, questo può essere tollerabile, ma se stai sviluppando un'applicazione di grandi dimensioni, non è corretto avere diverse ricerche in 1 grande tabella di ricerca, almeno concettualmente.

Sembra una situazione di tipo "Attribute Type" "Attribute Value". Con questo scenario sai sempre il "Tipo di Attributo" in anticipo perché sarai molto vicino ai tuoi dati. Il vantaggio consente di aggiungere "valori attributi" quando è necessario.

Ecco un paio di cose da tenere a mente ...

1. I valori degli attributi obsoleti probabilmente devono rimanere nel database indefinitamente
2. Devi accettare le condizioni "Nessuna" e "Altro"
3. Un campo "Ordinamento" separato al livello "Valore attributo" è una bella funzionalità

Li tengo separati dall'app, archiviati nel database, una tabella per tipo di ricerca.

Prenderò in considerazione anche dei modi per filtrarli dall'interfaccia utente, ad esempio un flag "Abilitato" (in modo che un elemento di ricerca possa essere attivato o disattivato), o forse anche un live da / per data.

In questo modo è possibile apportare modifiche ai dati senza dover ridistribuire l'intera applicazione.

Trovo che ogni volta che ho molti modi di accedere alle entità, tendo a creare un metodo di query generale che utilizza parametri generici e li utilizza per accedere ai dati. Questo metodo rimane nascosto e altri metodi pubblici lo accedono correttamente in base a ciò che viene passato.

In altre parole, per cercare un'entità per id, creo un metodo getById(id) che quindi richiama semplicemente un metodo interno get che accetta un array di parametri che vorrei passare alla query.

Se devi eseguire i controlli delle relazioni incrociate, farei che il database faccia il maggior lavoro possibile prima di gestirlo nel mio programma. Questo è sia per ragioni di efficienza che di semplicità nel codice. Se ti permetti di gestire le relazioni, scoprirai che starai riscrivendo la logica del database, con tutte le complicazioni che ne derivano e nessuna efficienza.

Non sono sicuro di cosa intendi per entità, ma la mia definizione di entità è come l'equivalente dell'oggetto di una tabella di database. Le relazioni tra entità possono richiedere una tabella di database (molti a molti), ma non dovrebbero avere la propria entità.

Non è chiaro per me cosa stai chiedendo, ma modellerei le cose come il tipo di istruzione e il livello di istruzione semplicemente come enumerazioni (non come entità che devi caricare dal database o persino da un'istanza). In molte lingue puoi aumentare le tue enumerazioni con ulteriori campi di identità e descrizione.