Modelli / strategie di progettazione per campi e tipi di dati personalizzati

12

Esistono strategie o schemi di progettazione comuni per la progettazione di applicazioni che hanno la possibilità di aggiungere campi personalizzati agli oggetti dati o di creare la propria definizione personalizzata di oggetti. Ad esempio, sto pensando a prodotti come SalesForce, in cui è possibile avere i propri tipi di informazioni, framework come Expression Engine e il modo in cui gestisce i canali e i gruppi di campi canale (esempio) o come CMS come Wordpress hanno la capacità di aggiungi campi a tipi di post personalizzati.

design-patterns database-design

— GSto
fonte

6

Potresti essere interessato a leggere alcune delle risposte a questa domanda sulla progettazione di un database per campi definiti dall'utente

— Rachel

Da notare: Oracle sta andando in giro facendo causa ai pantaloni di tutti coloro che lo implementano in un modo particolare (da quello che capisco, comune). Darei un'occhiata anche a quello.

— Steven Evers,

6

Martin Fowler ha dato una bella descrizione su come modellare le proprietà dinamiche (che è essenzialmente quello che stai chiedendo) nel suo libro "Schemi di analisi" . La maggior parte dei contenuti è disponibile online gratuitamente come articoli PDF, quello che stai cercando è questo:

http://martinfowler.com/apsupp/properties.pdf

— Doc Brown
fonte

4

Il EAVmodello viene normalmente utilizzato per schemi non strutturati come descritto.

Soffre in termini di prestazioni e capacità di interrogare tali proprietà dinamiche in un modo ad hoc ... e come tale è considerato da molti un anti-pattern.

Altri approcci consistono nell'utilizzare un formato dinamico come XML o Json per contenere tali proprietà, possibilmente con spazio di archiviazione dedicato per ciascuna proprietà per facilitare la ricerca.

— Oded
fonte

Ho anche sentito parlare di persone che utilizzano database orientati ai documenti come alternativa a EAV, ma non ho esperienze personali con un simile approccio.

— FrustratedWithFormsDesigner

@FrustratedWithFormsDesigner - Questo è ciò a cui stavo accennando, ma come te stesso, nessuna esperienza personale.

— Oded,

4

Oltre alla tabella EAV descritta da @Oded, le persone usano la base di dati nosql per questo tipo di informazioni. Ricordare che non vi è alcun motivo per cui l'applicazione non possa utilizzare un database relazionale per le parti che hanno senso con il modello relazionale e un database nosql per le informazioni che non lo fanno.

Una terza possibilità è quella di aggiungere diverse colonne per i campi aggiunti dal cliente (Customerfield1, customerfield2, ecc.) E quindi fare in modo che il cliente definisca cosa significano. Questo funziona solo per il numero di campi configurabili dal cliente che aggiungi, quindi va bene se ti aspetti che ne avranno bisogno solo due o tre ma non funzionerà affatto se ne avrai bisogno a centinaia.

— HLGEM
fonte

1

Non avresti la prima applicazione con una tabella con: UDF1, UDF2, UDF3 ... Gli altri suggerimenti (EVA o NoSQL) sono molto migliori.

A seconda del RDBMS ( SQL Server offre questo ), è possibile uscire dalla normalizzazione e disporre di un campo che contiene i dati in un formato XML o solo testo normale. Dovrai fare affidamento sul codice per gestirlo.

— Jeffo
fonte