Quanto sono interessanti i tipi di dati definiti dall'utente in SQL Server? [chiuso]

Question

I tipi di dati definiti dall'utente in SQL Server sono qualcosa che un utente SQL intermedio dovrebbe conoscere e utilizzare?

Che cosa sono i pro e i contro dell'utilizzo degli UDT?

Answer 1

Non usarli mai è il mio consiglio. Sei in un mondo ferito se mai dovessi cambiare la definizione. Forse questo è migliorato da SQL Server 2000 e qualcuno con più familiarità con le versioni più recenti può dirti se ora è sicuro entrare in acqua, ma fino a quando non avessi avuto la conferma di questo e lo avessi verificato da solo con un test, non avrei non metterlo sul mio sistema di produzione.

Dai un'occhiata a questa domanda per i dettagli: Come modificare il tipo di base di un UDT in SQL Server 2005?

Answer 2

Non non uso UDT basati su codice perché non credo che la complessità aggiuntiva meriti i vantaggi. faccio uso gli UDT T-SQL perché c'è pochissima complessità in più per cui i vantaggi valgono lo sforzo. (Grazie a Marc_s per aver sottolineato che il mio post originale era incompleto!)

Riguardo agli UDT basati su codice

Pensaci in questo modo: se il tuo progetto ha un componente di codice gestito (la tua app) e un componente di database (SQL Server) quale vantaggio reale ottieni dalla definizione del codice gestito nel database? Nella mia esperienza? Nessuno.

La distribuzione è più difficile perché dovrai aggiungere assembly alla tua distribuzione DB e modificarli, aggiungere file, ecc. in SQL Server. Dovrai anche attivare il CLR in SQL Server (non è un grosso problema ma nessuno mi ha dimostrato che questo non avrà una penalità di prestazioni / memoria). Alla fine, avrai esattamente quello che avresti avuto se tu avessi semplicemente progettato questo nel codice della tua applicazione. Potrebbe esserci qualche miglioramento delle prestazioni, ma mi sembra davvero un caso di ottimizzazione prematura - soprattutto perché non so se le prestazioni complessive soffrono a causa del CLR attivo o negativo.

Nota: suppongo che useresti il ??CLR di SQL Server per definire i tuoi tipi. HLGEM parla di SQL Server 2000 ma non ho familiarità con il 2000 e ho pensato che avesse solo UDF e non UDT in DLL definite esternamente (ma non citarmi ... davvero non ne ho familiarità!).

Riguardo agli UDT T-SQL

Gli UDT T_SQL possono essere definiti solo in SQL (vai a " Programmabilità | Tipi | Tipi di dati definiti dall'utente " in SQL Server Management Studio). Per gli UDT standard io raccomanderei di fatto di dominarli. Sono abbastanza facili e possono rendere il tuo DDL più auto-documentante e possono imporre vincoli di integrità. Ad esempio, definisco un " GenderType " (carattere (1), non nullable, trattenendo "M" o "F") che garantisce che siano consentiti solo dati appropriati nel campo Sesso.

Gli UDT sono abbastanza facili nel complesso ma questo articolo fornisce un buon esempio di come portarlo al livello successivo definendo una Regola per limitare i dati consentiti nel tuo UDT.

Quando originariamente ho risposto a questa domanda, mi sono fissato sull'idea di tipi complessi e definiti dal codice ( ha un palmo sulla fronte ). Quindi ... grazie Marc.

Answer 3

Il pro dei tipi definiti dall'utente è indirizzato abbastanza bene di Alex Papadimoulis. I contro sono stati ben indicati qui.

Vorrei anche sottolineare che la funzione sp_bindrule è stata deprecata, come notato dal post di Alex. Non sono sicuro di quando sia stato deprecato ma lo è ora. In effetti, le regole sono deprecate nel loro insieme.

Se volessi creare un tipo con una limitazione, prenderei in considerazione l'uso di un tipo di tabella definito dall'utente con un vincolo di controllo sulle colonne appropriate. Questo mi dà anche un modo per costruire un tipo di dati complesso.

Answer 4

Non posso davvero raccomandare l'uso di funzionalità specifiche di implementazione sql che lo rendono più difficile quando si esce da mssql e si sta migrando verso un altro dbms. Per il nostro dwh dbs abbiamo iniziato su mssql, siamo emigrati in Oracle e dall'anno scorso ci siamo laureati in hp vertica.