[SQL Server] User defined types: what's the point ?

[whoami]

Ik vraag me eigenlijk af wat het nut is van user defined types in SQL Server.

Het concept is mooi: je kan een 'custom' type maken; stom voorbeeld: een type 'naam' dat van het type varchar is, en 50 lang is:

code:

sp_addtype naam, 'varchar(50)'

Nu kan je dus, iedere keer je een naam wilt opslaan het type 'naam' gebruiken, ipv iedere keer 'varchar(50) te moeten specifieren. Op die manier kan je dus consistent werken. Mooi, niet ?

Maar nu de klucht: wat voor zin heeft zo'n user defined type als ik niet eens de definitie ervan kan veranderen ? Stel nu dat ik na een paar maanden vind dat een lengte van 50 te weinig is voor een naam. Dan zou je denken: goed, ik verander de definitie van m'n user defined type, maar dat lukt dus gewoon niet.
Het enige wat je hebt, is een sp_addtype SP en een sp_droptype SP. Ik vind geen enkele mogelijkheid om het type gewoon te alteren (behalve misschien als ik zelf in systypes ga zitten peuteren). Ik kan het type naam ook niet droppen als het al ergens in gebruik is.
IMHO is dit gewoon een serieuze 'flaw' in Sql Server 2000.

Tenzij ik natuurlijk ergens over kijk, en het toch mogelijk is om de definitie van m'n type te veranderen, maar ik zou niet weten hoe. Dus, als er iemand is die me dat kan zeggen, zou ik dat best vinden.

[beany]

Het heeft natuurlijk nogal wat gevolgen als je het type van een user defined data type gaat veranderen. Ik vind het eigenlijk wel logisch dat je em niet kan wijzigen...

[Cyphax]

beany schreef op vrijdag 28 oktober 2005 @ 09:44:
Het heeft natuurlijk nogal wat gevolgen als je het type van een user defined data type gaat veranderen. Ik vind het eigenlijk wel logisch dat je em niet kan wijzigen...

Dat is toch je eigen verantwoordelijkheid dan (je database droppen heeft ook grote gevolgen, maar het mag wel, evenals het datatype van een kolom in een gevulde tabel wijzigen... dan kan het ineens wel!). Het punt van whoami (en dat is mij ook al opgevallen op school ooit) is: wat heb je er nog echt aan dan? Het is misschien handig dat je niet steeds varchar(n) hoeft op te geven maar wat is daarop tegen? En hoe handig is het dat je in de beschrijving van je tabellen ziet dat een kolom van een of ander custom type is, dat zegt niet zoveel. Als ik kolom "naam" wil invullen en het datatype is dt_naam, dan weet ik dus niet hoeveel ik erin kwijt kan.

[ Voor 11% gewijzigd door Cyphax op 28-10-2005 09:49 ]

[GX]

In zekere zin is he tlogisch dat je het niet kan veranderen. Besluit je ineens van float naar int te gaan ben je een hele meuk data kwijt.

Diezelfde reden maakt het in mijn ogen ook gewoon een feature welke hoog op de onnozel en overbodig lijst staat.

[whoami]

GX schreef op vrijdag 28 oktober 2005 @ 09:51:
In zekere zin is he tlogisch dat je het niet kan veranderen. Besluit je ineens van float naar int te gaan ben je een hele meuk data kwijt.

Das gewoon jouw verantwoordelijkheid toch....
Als jij een TRUNCATE TABLE beslist te doen, tja....

Diezelfde reden maakt het in mijn ogen ook gewoon een feature welke hoog op de onnozel en overbodig lijst staat.

Dus, what's the point

[beany]

Een user defined data type is gelijk aan elke andere data type in sql server. Het enige wat je er aan hebt is dat het je datastructuur min of meer documenteerd(lichtjes dan). Ik zie er niet heel veel voordeel in, en gebruik het daarom ook niet. Ik zou alle user defined data types droppen en lekker de standaard data types blijven gebruiken

[GX]

whoami schreef op vrijdag 28 oktober 2005 @ 09:53:
[...]

Das gewoon jouw verantwoordelijkheid toch....
Als jij een TRUNCATE TABLE beslist te doen, tja....

Ja, dat is ook dom ja. Maar soms is gebruikers beschermen voor zichzelf slim, soms niet.

Dus, what's the point

Dat ik je gelijk geef

[whoami]

GX schreef op vrijdag 28 oktober 2005 @ 10:40:
[...]

Ja, dat is ook dom ja. Maar soms is gebruikers beschermen voor zichzelf slim, soms niet.

Ja, ik zie een gebruiker ook geen udt aanmaken.
Van een programmeur / ontwikkelaar wordt er veronderstelt dat hij weet wat hij doet en waar hij mee bezig is, dus dat zou gewoon mogelijk moeten zijn.

[beany]

whoami schreef op vrijdag 28 oktober 2005 @ 11:07:
[...]
Van een programmeur / ontwikkelaar wordt er veronderstelt dat hij weet wat hij doet en waar hij mee bezig is

[rml][ alg] slechtste prog voorbeelden.[/rml]

weet je het zeker?

[mulder]

Ik mocht laatst werken aan een project waar bijna elke property een udt was... compleet onhandig.. echt bad, de redenatie was een dat bv Achternaam overal even lang zou zijn.... Als je door OO-bril kijkt slaat het dus nergens op, want dan heb je heeft alleen Persoon een Achternaam en dat is maar 1 plek

[Annie]

Don Facundo schreef op vrijdag 28 oktober 2005 @ 11:25:
Als je door OO-bril kijkt slaat het dus nergens op, want dan heb je heeft alleen Persoon een Achternaam en dat is maar 1 plek

Als je door een SQL bril kijkt, dan slaat je OO-applicatie nergens op; appels en peren. Dus ik snap je punt niet.


De reden dat je udt's niet zomaar kan wijzigen heeft te maken met het wel of niet impliciet kunnen casten van het oude type naar het nieuwe type; dat is niet altijd mogelijk. Als je een column type via ALTER TABLE wil uitvoeren dan is dit ook niet altijd mogelijk. Is dat dan een flaw in ALTER TABLE? Vind ik niet.
Je kan het type natuurlijk wel wijzigen, maar dan alleen via een omweg (nieuw type, omzetten, oude droppen, oid.). Maar als je daar 1 keer een template voor maakt, dan kan je deze daarna blijven gebruiken.

Verder zijn udt's wat mij betreft alleen handig als je niet alleen een type, maar ook meteen een rule er op plaatst. En dan ook nog maar in echt specifieke gevallen. Om eerlijk te zijn, heb ik ze nog nooit gebruikt.

[ Voor 3% gewijzigd door Annie op 28-10-2005 11:50 ]

[mulder]

Als je door een SQL bril kijkt, dan slaat je OO-applicatie nergens op; appels en peren. Dus ik snap je punt niet.

Je slaat het veld achternaam alleen op bij tabel persoon. Er is maar 1 achternaam veld in de database, dus waarom een udt. Voor het argument dat Achternaam overal even lang zou moeten zijn.

[Annie]

Don Facundo schreef op vrijdag 28 oktober 2005 @ 12:07:
[...]

Je slaat het veld achternaam alleen op bij tabel persoon. Er is maar 1 achternaam veld in de database, dus waarom een udt. Voor het argument dat Achternaam overal even lang zou moeten zijn.

Maar mijn punt is dat de entiteiten in de database niet altijd 1-op-1 mappen met de objecten in je applicatie (ook al is deze OO). Het zou dus best zo kunnen zijn dat er meerdere achternaam-velden bestaan in de database.

[mulder]

Ik bedoelde het dus ook dat in een 'ideale situatie' zo'n udt geen zin heeft. Maar in niet-ideale dus eigenlijk ook niet.

[MrBucket]

Een mogelijk voordeel van user defined types is dat je er constraints aan kan hangen. Je kan bijvoorbeeld een UDT 'Regio' maken, en daaraan een check hangen die controleert dat alleen de waarden 'Noord', 'Zuid', 'Oost' en 'West' toegestaan zijn in dat veld. Of een UDT telefoonnummer, die controleert dat de data alleen uit cijfers bestaat.

Door in je tabellen nu deze UDTs te gebruiken krijg je de juiste constraints cadeau, in plaats van ze voor elke kolom opnieuw te moeten specificeren. Dit helpt ook om het principe van 'single point of definition' af te dwingen.

[ACM]

Met het voorbeeld van Postgresql over complex typen is het alweer minder loos om een udt te hebben. Ik heb de info over udt's van SQL Server niet opgezocht, maar jouw voorbeeld suggerereert dat het meer overeenkomt met (Postgre)SQL's DOMAIN.
Domweg als alias voor een bepaalde variant van een basis type lijkt het me niet zo heel zinvol, maar de constraint-optie maakt het wel interessant natuurlijk.

Overigens ben ik met je eens dat een type verandert zou moeten kunnen worden, maar dat zal nogal complex worden als je dus iets minder triviale types definieert. En dat betekent dan dat je sowieso moet testen of het een compatible wijziging is (varchar(50) naar char(60) is tenslotte ook toegestaan) en dan zou je nog op zoek moeten naar alle tabellen die het ding gebruiken en die wijzigen.
Postgres laat voor het domain (de constraints wel, het type ervan niet) en type (eigenlijk niks, allen de owner) ook maar weinig verandering toe.

[jochemd]

whoami schreef op vrijdag 28 oktober 2005 @ 09:22:
Ik vraag me eigenlijk af wat het nut is van user defined types in SQL Server.

Het concept is mooi: je kan een 'custom' type maken; stom voorbeeld: een type 'naam' dat van het type varchar is, en 50 lang is:

code:

sp_addtype naam, 'varchar(50)'

Nu kan je dus, iedere keer je een naam wilt opslaan het type 'naam' gebruiken, ipv iedere keer 'varchar(50) te moeten specifieren. Op die manier kan je dus consistent werken. Mooi, niet ?

Maar nu de klucht: wat voor zin heeft zo'n user defined type als ik niet eens de definitie ervan kan veranderen ?

Voor de logica moeten we daarnaast het DOMAIN er bij pakken.

Zowel een TYPE als een DOMAIN zijn datatypes die door de DBA gemaakt kunnen worden in SQL. Een TYPE is een volledig en echt datatype met alles wat daar bij hoort. Een TYPE heeft geen impliciete casts naar andere datatypes. Om verschillende instances van een TYPE met elkaar te vergelijken zal je zelf een eigen operator moeten definieren.
Een DOMAIN is een lichtgewicht extensie op een bestaand datatype. Je kan een naampje geven, een lengte en nog wat meer constraints en dat is het. Alle impliciete casts die het basis datatype heeft blijven gewoon intact, indexeermethodes werken etc.

Als je het op die manier bekijkt is het vrij logisch dat een TYPE niet te wijzigen valt in SQL. Hoe moet de database weten hoe het oude TYPE naar het nieuwe TYPE gecast kan worden? Een DOMAIN aan de andere kant valt wel te wijzigen. Daar weet een database wel hoe het moet.

Het voorbeeld dat jij gebruikt is typisch iets waar je in SQL een DOMAIN zou gebruiken in plaats van een TYPE. Een TYPE gebruik je bijvoorbeeld als je een MAC datatype wil hebben met een representatie als een '00:11:22:33:44:55:66' string die toch al 6 byte data wordt opgeslagen. Of als je een IP-adres datatype wil hebben waar je de string '10.0.0.1' in in kan voeren maar die intern wel als een 32 bit getal wordt gehanteerd.

En als MS SQL Server dat niet ondersteunt dan is dat een omissie in die implementatie

[EfBe]

UDTs zijn voor mensen die alles fijn in de db doen, dus alles platslaan en 1 dikke tier bouwen van stored procedure crud, met dal en bl ineens (whoohoo wat een onderhoudbaarheid ineens, het groepje DBA's groeit ineens als kool).

doe je veel buiten de db dan is het niet altijd nuttig, temeer omdat typen in de db niet of niet altijd bruikbaar zijn buiten de db (bv oracle's UDTs geschreven in java, niet bruikbaar in een .net app)

[Gé Brander]

EfBe schreef op vrijdag 28 oktober 2005 @ 14:33:
UDTs zijn voor mensen die alles fijn in de db doen, dus alles platslaan en 1 dikke tier bouwen van stored procedure crud, met dal en bl ineens (whoohoo wat een onderhoudbaarheid ineens, het groepje DBA's groeit ineens als kool).

Denk je niet dat deze opmerking wat al te zwart wit gesteld is?
Het hele probleem met ontwikkelaars/beheerders is voornamelijk dat beide niet open staan voor elkaars argumenten en niet willen veranderen, of volledig van mening zijn dat zij wel willen veranderen maar die andere niet.

doe je veel buiten de db dan is het niet altijd nuttig, temeer omdat typen in de db niet of niet altijd bruikbaar zijn buiten de db (bv oracle's UDTs geschreven in java, niet bruikbaar in een .net app)

[ Voor 6% gewijzigd door Gé Brander op 28-10-2005 14:40 ]