è la creazione di tipi di dati definiti dall'utente db buone pratiche?

Question

è la creazione di tipi definiti dall'utente invece di utilizzare i tipi esistenti migliori pratiche? Nei miei anteprime luoghi di lavoro di tutti i tipi di base sono stati predefiniti, è meglio pratica? quali sono i vantaggi e quali svantaggi ha.
Grazie mille!

Answer 1

In MS SQL Server - l'idea è grande. Tuttavia, c'è una grande ma a loro: non si può cambiare una volta che sono in uso, dal momento che non c'è alcuna dichiarazione ALTER TYPE ..... Questo può essere una grande seccatura.

Considerate questo: si dispone di un'applicazione libreria, che ha un tipo definito dall'utente ISBN = VARCHAR (10) - funziona come un fascino. Ora il comitato internazionale ha deciso di increato campo ISBN a 13 caratteri - purtroppo, non c'è ALTER TYPE ISBNType..... così l'unica scelta è quella di eliminare praticamente tutte le colonne di questo tipo in tutta la vostra base di dati, quindi ricreare il tipo nella sua nuova forma, e ricreare di nuovo tutte quelle colonne.

L'idea è grande e mi piacerebbe usarlo - ma nel suo stato attuale, è vicino al inutilizzabile, a mio parere, che è un peccato

.

Marc

Answer 2

Un po 'in ritardo, ma .. i miei 2 cts.

tipi definiti dall'utente Il svolgere il ruolo di un dominio nei modelli concettuali e logici, quindi se si desidera implementare il tuo datamodel logico nel database fisico, l'uso di tipi definiti dall'utente sarebbero l'approssimazione più vicina. Ciò fornirà benefici come l'utilizzo di un modello grafico che può essere trasferito ad un'implementazione automaticamente, meglio di quanto potrebbe essere fatto senza utilizzare UDT.

Utilizzando domini consente di rilevare i tentativi di memorizzare un codice postale in un campo SSN e li hanno catturati dal database in fase di esecuzione (o anche tempo di compilazione). Questo vi permetterà di far rispettare a livello aziendale le regole di business dove dovrebbero essere applicate: nel punto in cui i dati colpisce l'archiviazione. In nessun altro posto è una cortesia per l'utente, ma è qui che assolutamente devono essere applicate per assicurarsi che nessuno va in giro per loro.

Inoltre, UDT come definiti nella ANSI SQL: 1999 metodi incapsulare, e può essere sottotipizzati. Ciò significa che alcuni cambiamenti nelle regole di business che si occupano di vincoli possono essere modificati nel database, senza mai dover toccare un'implementazione.

Comunque ... UDT come attualmente implementati lasciano molto a desiderare. Io non sono nemmeno sicuro di SQL Server implementa lo standard come descritto, ancora meno sicuro di Oracle. E anche se lo fanno, gli svantaggi di usare UDT diventerà evidente fin da subito come si usa utensili BI, ETL utensili o altri strumenti piuttosto semplici di mente: di solito non capiscono gli UDT e anche se lo fanno, non saranno in grado di usarle perché la maggior parte si basano su tipi di base (int, char e data / ora).

Per quanto riguarda gli strumenti di reporting, prendiamo in considerazione un UDT che ha una combinazione di campi. Ora, come sarebbe un ETL-strumento di database agnostico essere in grado di capire il tipo? Dovrebbe essere in grado di comprendere la struttura per visualizzarlo o utilizzarlo per i calcoli. E che per ogni database supportato - un compito difficile. E dal momento che nessuno utilizza UDT, non lo farà. E 'un circolo vizioso, ma dobbiamo ancora vivere con esso.

Oltre a questo, il supporto UDT nella maggior parte dei database non è poi così caldo sia. Cambiare i tipi può essere molto difficile. Mentre la sintassi dovrebbe essere la stessa in tutto il mondo, la loro amministrazione non è definito in SQL: 1999 e quindi diverso ovunque. Prova a cambiare il proprietario di un UDT in SQL Server per un esempio. Quello usato per essere piuttosto difficile -. Non sono sicuro su SQL Server 2016, ma dato che UDT non sembrano una zona di messa a fuoco, non mi aspetto grandi miglioramenti in quella zona

Infine, se si aggiunge il codice molto complesso per UDT, si esegue nel vecchio problema che si sta programmando in un ambiente che ha una mancanza di buone opzioni di debug. Ciò non aiuta.

Quindi: se avete il pieno controllo del database e tutte le interazioni passa attraverso il software, UDT possono essere estremamente utili. In caso contrario, possono essere un dolore enorme al collo. Quale è il caso nel vostro scenario, è qualcosa che solo si può dire.

Answer 3

Come fresco sono definiti dall'utente tipi di dati in MS SQL Server?

Personalmente, io non li uso, ma li ho visti. Un problema è che il codice client riconosce il tipo di base unica, IIRC, per MS SQL Server, almeno. E la portabilità / comportamenti attraverso le versioni.