Werden benutzerdefinierte SQL-Datentypen häufig verwendet?[geschlossen]

Question

Mein DBA sagte mir, ich solle einen benutzerdefinierten SQL-Datentyp zur Darstellung von Adressen verwenden und dann eine einzelne Spalte dieses neuen Typs in unserer Benutzertabelle anstelle mehrerer Adressspalten verwenden.Ich habe das noch nie zuvor gemacht und frage mich, ob dies ein üblicher Ansatz ist.

Und wo kann man sich am besten darüber informieren – sind diese produktspezifisch?

Answer 1

Es gibt eine Reihe anderer Fragen zu ALSO Über die Darstellung von Adressen in einer Datenbank. AFAICR, keiner von ihnen schlägt einen benutzerdefinierten Typ zu diesem Zweck vor. Ich würde es nicht als gemeinsamen Ansatz betrachten; Das heißt nicht, dass es kein vernünftiger Ansatz ist. Die Hauptschwierigkeiten liegen bei der Entscheidung, welche Methoden zur Manipulation der Adressdaten bereitgestellt werden sollen - diejenigen, die zur Formatierung der Daten verwendet werden, die in einem Umschlag angezeigt werden, oder an bestimmten Stellen in einem gedruckten Formular oder um Felder zu aktualisieren, sich um die vielen Auswirkungen internationaler Adressen zu kümmern , usw.

Das Definieren von benutzerdefinierten Typen ist sehr produktspezifisch. Die Art und Weise, wie Sie es in Informix tun, unterscheiden sich von der Art und Weise, wie es beispielsweise in DB2 und Oracle geschieht.

Answer 2

Soweit ich das beurteilen kann, werden UDT zumindest in der SQL Server -Welt nicht viel verwendet.

Das Problem mit UDT ist die Tatsache, dass Sie sie nicht einfach aktualisieren können. Einmal in Datenbanken erstellt und verwendet, sind sie fast wie in Stein gemeißelt.

Es gibt keinen Befehl "erstellen oder altern (udt)" :-( Um etwas zu ändern -Erstellen Sie es mit der neuen Struktur und wenden Sie die Daten und alles erneut an.

Das ist einfach zu viel Ärger - und du weißt: da Wille Veränderung sein!

Im Moment sind UDT in SQL Server Land einfach eine nette Idee - aber wirklich schlecht implementiert. Ich würde nicht empfehlen, sie ausgiebig zu verwenden.

Marc

Answer 3

Ich würde auch eher vermeiden, benutzerdefinierte Datentypen zu verwenden, da ihre Defination und Benutzerfreundlichkeit Ihren Code von einer bestimmten Datenbank abhängt.

Erstellen Sie stattdessen, wenn Sie eine objektorientierte Sprache verwenden, eine Kompositionsbeziehung, um Adressen für einen Mitarbeiter (z. B.) zu definieren und die Adressen in einer separaten Tabelle zu speichern.

Z.B. Mitarbeiter Tabelle und Mitarbeiter -Tabelle. Ein Mitarbeiter kann mehrere Adressen haben.

Answer 4

Benutzerdefinierter SQL-Datentyp zur Darstellung von Adressen

Benutzerdefinierte Typen können sehr nützlich sein, aber eine Postanschrift gehört (zumindest für mich) nicht dazu.Was ist für Sie eine Postanschrift?Ist es etwas, das man auf einen Umschlag druckt, um ihn per Post an jemanden zu verschicken?Wenn ja, ist der Text so gut wie möglich.Wenn Sie aus rechtlichen Gründen wissen müssen, in welchem ​​Zustand sich jemand befindet, speichern Sie dies separat und das ist kein Problem.

Andere Beiträge hier haben UDTs kritisiert, aber ich denke, dass sie einige erstaunliche Verwendungsmöglichkeiten haben.PostgreSQL verfügte schon lange über die Volltextsuche als Plugin auf Basis von UDTs, bevor die Volltextsuche tatsächlich in das Kernprodukt integriert wurde.Derzeit ist PostGIS ein sehr erfolgreiches GIS-Produkt, das vollständig ein auf UDTs basierendes Plugin ist (es verfügt über eine GPL-Lizenz und wird daher nie in den Kern integriert).