Come al solito ...

Dipende

Hai un'entità di dominio usata in più di un luogo che supporta nativamente altrimenti richiederebbe un notevole sforzo e / o vincoli e comportamenti ridondanti ?

Se è così, domina. In caso contrario, non preoccuparti.

Ho trovato necessario creare un tipo definito dall'utente in SQL Server esattamente una volta, in base all'euristica precedente. Non ricordo nemmeno più cosa fosse - ma ha risparmiato più lavoro di quello che ha causato.

Come utente di SQL Server e C #, non ho usato Tipi definiti dall'utente nel database, dal momento che sono molto più potente dal lato delle applicazioni. Evento dopo ORM come LINQ a SQL e Entity Framework, il mio utilizzo delle funzionalità del server è stato ridotto molto.

Ad esempio, stavo utilizzando l'integrazione CLR per caricare alcune funzioni di conversione DateTime su SQL Server per trasferire i tempi di gregoriano in altri formati, in base al potere di globalizzazione di .NET. Ma ora, le cose sono diverse, e io non lo faccio più. Semplicemente carico i dati e faccio la trasformazione, direttamente nel mio livello di applicazione.

Quindi, dopo quasi 4 anni di programmazione e ispezione di tutti i team a cui riesco a pensare, non ho trovato esempi di utilizzo di Tipi definiti dall'utente. Inoltre, non l'ho visto in azione in molti blog .NET.

Questo non significa che le persone non utilizzino Dominio del database , ma sicuramente significa che almeno l'utilizzo di Dominio del database non è così comune.

Esistono già risposta dettagliata su Stack Overflow. Sono per lo più d'accordo, ma non con l'esempio dato, cito:

“For example, I define a "GenderType" (char(1), not nullable, holding "M" or "F") that ensures that only appropriate data is permitted in the Gender field.”

Personalmente, mi sento più a mio agio nell'impostazione di char(1) type e nella definizione di un vincolo sulla colonna. Quando il vincolo viene violato, so esattamente dove cercare per trovare ciò che ho fatto di sbagliato. È anche più noto dei tipi definiti dall'utente, quindi il database che utilizza solo i vincoli sarebbe più facile da capire per un principiante.

Naturalmente, è solo un'opinione personale. Altre persone direbbero che un vincolo in ('M', 'F') non è auto-documentante e potrebbe essere molto oscuro per un nuovo sviluppatore che scopre il database.

IMO, usa tipi definiti dall'utente per tipi più complicati e vincoli per qualcosa di base. Inoltre, quando non riesci a trovare facilmente un nome esplicito per un tipo, esiste la possibilità che un vincolo si adatti meglio.

Quando dici "non tutti i database supportano questo", penso che un modo migliore di metterlo sia il seguente:

Tutti i principali database supportano questo, poiché supportano i trigger, le funzioni e altre funzionalità avanzate in modo esteso.

Questo ci porta alla conclusione che questo fa parte di SQL avanzato e ha senso a un certo punto.

Do people actually use domains in their database designs?

Meno è possibile, a causa della vasta copertura richiesta (considerando operatori, indici, ecc.)

If so to what extent?

Ancora una volta, per quanto limitato possa essere, se un tipo esistente combinato con una piccola logica aggiuntiva (ad esempio, controlli ecc.) può fare il trucco, perché andare così lontano?

How useful are they?

Un sacco. Consideriamo per un secondo un DBMS non-così-buono come MySQL, che ho scelto per questo esempio per una ragione: manca un buon supporto per il tipo inet (indirizzo IP).

Ora vuoi scrivere un'applicazione che si concentra principalmente su dati IP come gli intervalli e tutto ciò, e sei bloccato con il tipo predefinito e le sue funzionalità limitate, o scrivi funzioni e operatori aggiuntivi (come quelli supportati in modo nativo in PostgreSQL per esempio) o scrivere query molto più complesse per ogni funzionalità di cui hai bisogno.

Questo è un caso in cui puoi facilmente giustificare il tempo impiegato per definire le tue funzioni (inet > > inet in PostgreSQL: range contenuto nel range operator).

A quel punto, hai già giustificato l'estensione del supporto datatype, c'è solo un altro passaggio per definire un nuovo tipo di dati.

Ora torna a PostgreSQL che ha un supporto di tipo veramente bello ma senza int unsigned .. di cui hai bisogno, perché sei davvero preoccupato per lo storage / le prestazioni (chissà ...), beh dovrai aggiungerlo come così come gli operatori, anche se ovviamente questo deriva principalmente dagli operatori int esistenti.

What pitfalls have you encountered?

Non ci gioco perché finora non ho avuto un progetto che richiedesse e giustificasse il tempo richiesto per questo.

I maggiori problemi che posso vedere sono reinventare la ruota, introdurre bug nel livello "sicuro" (db), supporto di tipo incompleto che ti renderai conto solo mesi dopo quando il tuo CONCAT (cast * AS varchar) fallisce perché non hai definito un cast (newtype come varchar), ecc.

Ci sono risposte che parlano di "non comuni" ecc. Sicuramente queste sono e dovrebbero essere non comuni (altrimenti vuol dire che i dbms mancano di molti tipi importanti), ma d'altra parte, si dovrebbe ricordare che un (buono) db è ACID compatibile (a differenza di un'applicazione) e qualsiasi cosa relativa alla coerenza è meglio conservata lì dentro.

Ci sono molti casi in cui la logica aziendale viene gestita nel livello software e potrebbe essere eseguita in SQL, dove è più sicuro. Gli sviluppatori di app tendono a sentirsi più a proprio agio all'interno del livello applicativo e spesso a evitare soluzioni migliori implementate in SQL, questo non dovrebbe essere considerato una buona pratica.

Gli UDT possono essere una buona soluzione per l'ottimizzazione, un buon esempio è dato in un'altra risposta sul tipo m / f usando char (1). Se fosse stato un UDT potrebbe invece essere un booleano (a meno che non vogliamo offrire la terza e la quarta opzione). Naturalmente sappiamo tutti che questa non è veramente ottimizzazione a causa del sovraccarico della colonna, ma c'è la possibilità.

Sulla carta, gli UDT sono un grande concetto. Ti permettono di normalizzare veramente il tuo DB (ad es. Quando hai due colonne che dipendono l'una dall'altra) e anche di incapsulare qualsiasi logica relativa al tuo nuovo tipo.

In pratica, il prezzo che si paga (oggi) è troppo alto. Ovviamente c'è il sovraccarico di sviluppo, ma a parte questo si perde il supporto da una varietà di ORM e strumenti di reporting, e si aumenta un po 'la complessità complessiva della soluzione. Non ci sono molti sviluppatori là fuori che hanno familiarità con gli UDT e non ho mai visto gli UDT gestiti usati al di fuori degli esempi.

Uno dei migliori esempi di un tipo che è meglio fare come UDT (se non esistesse già) dovrebbe essere hierarchyid ( link MSDN ). Per rimanere efficiente, memorizza il suo valore in un formato binario (al contrario delle solite implementazioni personalizzate di varchar), che sarebbe ingombrante da mantenere senza le funzioni del tipo. I circa 10 metodi forniti dal tipo sono anche forniti come parte del tipo, al contrario delle funzioni esterne. Prenderò in considerazione l'utilizzo di UDT gestito in modo personalizzato in casi come questo - dove c'è un guadagno significativo, fornendo un'implementazione efficiente e pulita come un tipo separato.

Una domanda / risposta più pratica. La tua azienda ti permette di usarlo?

La tua azienda lavora con diversi D.B. S.Q.L. marchi che gestiscono diversi DDL (s)?

Ogni marchio di database può offrire buone funzionalità aggiuntive, come i Tipi definiti dall'utente, ma, se la tua azienda utilizza diversi D.B., potresti avere problemi con le funzionalità non standard.

Se l'azienda è solo tu o puoi decidere quali database & funzionalità che hai intenzione di utilizzare, quindi puoi utilizzare D.D.L.

Ho lavorato con diversi progetti in cui un tipo definito dall'utente potrebbe essere utile, ma, dovrei attenermi ad altre funzionalità standard, dato che dovevamo gestire diversi DB. (S).