Ci sono degli schemi che sembrano sensati quando si progetta un dominio orientato agli oggetti, ma non si traducono piacevolmente in uno schema di database relazionale? Se sì, ci sono schemi standard che possono essere usati al posto?
Domini con entità in cui il numero di attributi (proprietà, parametri) che possono essere utilizzati per descriverli è potenzialmente vasto, ma il numero che verrà effettivamente applicato a una data entità è relativamente modesto.
Un esempio di tale dominio sarebbe una pratica medica, in cui vi è un vasto numero di possibili sintomi, ma il numero di sintomi che ogni paziente potrebbe avere in un dato momento è relativamente piccolo.
Questi tipi di domini sono tipicamente rappresentati utilizzando un modello Entity-Attribute-Value (EAV) . Questa rappresentazione dei dati è analoga ai metodi di archiviazione spazio di una matrice sparsa, in cui sono memorizzati solo valori non vuoti.
Nel caso di un dominio medico, lo spazio dei problemi è complicato dal fatto che qualsiasi dato sintomo o test medico può avere un proprio insieme di attributi personalizzati, proprio come i prodotti venduti in un negozio online possono avere specifiche personalizzate.
In effetti, i negozi online devono affrontare anche questo problema. Un libro ha una specifica "numero di pagine", mentre un modulo di memoria ha una specifica "numero di byte" e i due attributi non sono affatto correlati.
Quindi una serie di attributi appropriati per ogni prodotto è scelta da una tabella di attributi.
La tabella Attributi potrebbe essere simile a questa:
AttributeID
AttributeDescription
UnitsID --> FK to Units table
La tabella ProductAttributes potrebbe essere simile a questa:
ProductAttributeID
ProductID
AttributeID --> FK to Attributes table
Value
Si noti che Numero di byte e Numero di pagine non sono caratteristiche dello schema del database. Invece, sono codificati in modo soft nei tavoli. Quindi non c'è modo di rappresentare queste funzionalità come parte del design del dominio.
Riferimenti a dati che possono cambiare, in un record che non dovrebbe.
Ho visto un certo numero di implementazioni che avevano qualcosa di simile:
Order
Id : int
OrderDate : DateTime
OrderProduct
Id : int
OrderId : FK of Order
ProductId : FK of Product
Quantity : int
Cost : Decimal
Product
Id : int
Description : string
Il codice finisce per sembrare qualcosa del tipo:
class Order
{
int Id;
DateTime OrderDate;
List<OrderProduct> OrderLines;
AddProduct(Product p, int quantity)
{
this.OrderLines.Add(new OrderProduct(this, p, q));
}
}
class OrderProduct
{
int Id;
Product Product;
Order Order;
int Quantity;
Decimal Cost;
OrderProduct(Order o, Product p, int quantity)
{
this.Order = o;
this.Product = p;
this.Quantity = q;
this.Cost = p.Cost * quantity * applicableTax;
}
}
class Product
{
int Id;
string Description;
}
Sembra corretto a prima vista, il codice funziona correttamente e i dati finiscono per essere ben normalizzati e puoi creare e leggere gli ordini correttamente.
Tranne che se vendi un ordine oggi e ricevi informazioni da un fornitore domani che la descrizione di qualcosa sul prodotto è cambiata, questi sistemi di solito aggiornano il prodotto con la modifica. Ora se dovessi riprodurre quell'ordine entro 2 giorni il contenuto dell'ordine sarà cambiato, e non ne sarai più saggio.
Ci sono alcuni semplici modi per risolvere questo problema, ma l'ho visto un certo numero di volte con vari gradi di gravità.
Leggi altre domande sui tag object-oriented rdbms design-patterns domain-model orm