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

Question

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

#1 da (6 voti)
#2 da (4 voti)
#3 da (4 voti)
#4 da (1 voti)

12

Esistono strategie o schemi di progettazione comuni per la progettazione di applicazioni che hanno la possibilità di aggiungere campi personalizzati a oggetti di 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 del canale (Esempio) , o Come CMS come Like Wordpress hanno la possibilità di aggiungere campi a tipi di post personalizzati.

design-patterns database-design

posta GSto 14.05.2012 - 16:10

fonte

4 risposte

Leggi altre domande sui tag design-patterns database-design

Come si fa a capire che un manager è agile? In che modo il carattere escape \ "backslash" sfugge davvero?

score 6 · Answer 1

Martin Fowler ha fornito una bella descrizione di come modellare le proprietà dinamiche (che è essenzialmente ciò che si richiede) nel suo libro " Modelli di analisi ". La maggior parte del contenuto è disponibile online gratuitamente come articoli PDF, quello che stai cercando è questo:

link

score 4 · Answer 2

Il EAV modello viene normalmente utilizzato per schemi non strutturati come descrivi.

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

Altri approcci sono l'uso di un formato dinamico come XML o Json per conservare tali proprietà, possibilmente con uno spazio di archiviazione dedicato per ciascuna proprietà per facilitare la ricerca.

score 4 · Answer 3

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

Una terza possibilità consiste nell'aggiungere più colonne per i campi aggiunti dal cliente (Customerfield1, customerfield2, ecc.) e poi chiedere al cliente di definire cosa significano. Questo funziona solo per il numero di campi che puoi aggiungere al cliente, quindi va bene se ti aspetti che ne avranno bisogno due o tre ma non funzionerà affatto se avrai bisogno di centinaia.

score 1 · Answer 4

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

A seconda dell'RDBMS ( SQL Server offre questo ), potresti uscire dalla normalizzazione e avere un campo che contiene i dati in un formato XML o semplicemente testo. Dovrai fare affidamento sul codice per gestirlo.