db benutzerdefinierte Datentypen am besten Praxis schafft?

Question

Ist die Erstellung benutzerdefinierte Typen statt vorhandene Typen mit Best Practice? In meinen Vorschauen arbeiten Ort alle Grundtypen waren vorgegeben, ist es am beste Praxis? welche Vorteile und welche Nachteile es hat.
Vielen Dank!

Answer 1

In MS SQL Server - die Idee ist groß. Allerdings ist es ein großer und zu ihnen: Sie nicht ändern können, wenn sie in Gebrauch sind, da es keine ALTER TYPE .... Aussage ist. Dies kann ein großer Aufwand sein.

Bedenken Sie: Sie eine Buchhandlung App haben, die einen benutzerdefinierten Typ ISBN hat = VARCHAR (10) - wirkt wie ein Zauber. Nun ist das internationale Komitee beschlossen, das ISBN-Feld zu 13 Zeichen increate - leider gibt es keine ALTER TYPE ISBNType..... so Ihre einzige Wahl im Grunde ist, um alle Spalten dieser Art in alles Ihrer Datenbank zu löschen, erstellen Sie dann den Typen in seiner neuen Form, und erstellen alle diese Spalten wieder.

Die Idee ist großartig und ich würde gerne, es zu benutzen - aber in seinem aktuellen Zustand, dann ist es neben unbrauchbar, meiner Meinung nach, die unglücklich ist,

.

Marc

Answer 2

Ein bisschen spät, aber .. meine 2 cts.

Die benutzerdefinierten Typen erfüllen die Rolle einer Domain in den konzeptionellen und logischen Modellen, also wenn Sie Ihr logisches Datenmodell in der physischen Datenbank implementieren mögen, die Verwendung von benutzerdefinierten Typen die beste Annäherung sein würden. Dies wird Vorteile bieten wie ein grafisches Modell, das automatisch auf eine Implementierung übertragen werden kann, besser, als es ohne die Verwendung von UDTs getan werden könnte.

Domains macht es möglich, Versuche zu erfassen, um eine Postleitzahl in einem SSN-Feld zu speichern und haben sie von der Datenbank zur Laufzeit gefangen (oder sogar Zeit kompilieren). Dies ermöglicht es Ihnen unternehmensweite Geschäftsregeln erzwingen, wo sie durchgesetzt werden soll: an der Stelle, wo die Daten der Speicher trifft. Überall sonst ist eine Höflichkeit für den Benutzer, aber das ist, wo sie unbedingt haben durchgesetzt werden, um sicherzustellen, niemand geht um sie herum.

Auch UDTs wie in ANSI SQL definiert: 1999 encapsulate Methoden und kann subtyped werden. Das bedeutet, dass bestimmte Änderungen in den Geschäftsregeln, die mit Einschränkungen umgehen können in der Datenbank geändert werden, ohne dass jemals eine Implementierung zu berühren.

Allerdings ... wie sie derzeit umgesetzt UDTs lassen viel zu wünschen übrig. Ich bin nicht einmal sicher, dass SQL Server den Standard, wie beschrieben, noch weniger sicher Oracle implementiert. Und selbst wenn sie es tun, die Nachteile UDTs der Verwendung wird sofort offensichtlich werden, wie Sie BI Werkzeuge, ETL Werkzeuge oder andere eher einfältig Tools verwenden: sie in der Regel nicht UDTs verstehen und selbst wenn sie es tun, werden sie nicht sein der Lage, sie zu benutzen, weil die Mehrheit sich auf Grundtypen (int, char und Datum / Uhrzeit) stützen.

Wie für Reporting-Tools, lassen Sie uns einen UDT betrachten, die eine Kombination von Feldern hat. Nun, wie wäre eine Datenbank-agnostisch ETL-Tool in der Lage sein, die Art zu verstehen? Es müßte in der Lage sein, die Struktur zu verstehen, um es anzuzeigen, oder es für Berechnungen zu verwenden. Und das für jede unterstützte Datenbank - eine schwierige Aufgabe. Und da niemand UDT verwendet, werden sie dies nicht tun. Es ist ein Teufelskreis, aber wir haben immer noch mit ihm zu leben.

Abgesehen davon UDT Unterstützung in den meisten Datenbanken ist nicht alles entweder so heiß. Ändern Typen kann sehr schwierig sein. Während die Syntax überall gleich sein soll, ist ihre Verwaltung in SQL undefined: 1999 und somit überall anders. Versuchen Sie, den Besitzer eines UDT in SQL Server für ein Beispiel zu ändern. Das war früher ziemlich schwierig sein -. Nicht sicher SQL Server 2016, aber da UDTs nicht wie ein Fokusbereich schauen Sie, ich erwarte keine großen Verbesserungen in diesem Bereich

Schließlich, wenn Sie wirklich komplexen Code zu UDTs hinzuzufügen, führen Sie in das alte Problem, dass Sie in einer Umgebung programmieren, die einen Mangel an guten Debugging-Optionen haben. Das hilft auch nicht.

Also: Wenn Sie die volle Kontrolle über Ihre Datenbank und alle Interaktion geht über die Software, UDTs kann sehr hilfreich sein. Wenn nicht, können sie den Hals ein großer Schmerz sein. Welches ist der Fall in Ihrem Szenario ist etwas, das nur Sie sagen können.

Answer 3

Wie cool sind benutzerdefinierte Datentypen in MS SQL Server?

Ich persönlich benutze sie nicht, aber ich habe sie gesehen. Ein Problem ist, dass Client-Code erkennt den Basistyp nur, IIRC, für MS SQL Server zumindest. Und Portabilität / Verhaltensweisen über Versionen.