Erstellt benutzerdefinierte Typen anstelle von Best Practices für vorhandene Typen? In meiner Preview Workplace wurden alle Grundtypen vordefiniert, ist es Best Practice? Welche Vorteile und welchen Nachteil hat es?
Vielen Dank!erstellt db benutzerdefinierte Datentypen Best Practice?
In MS SQL Server - die Idee ist großartig. Jedoch gibt es eine große aber zu ihnen: Sie können sie nicht ändern, sobald sie in Gebrauch sind, da es keine ALTER TYPE .... Aussage gibt. Dies kann ein großer Aufwand sein.
Betrachten Sie dies: Sie haben eine Buchhandlung App, die einen benutzerdefinierten Typ hat ISBN = VARCHAR (10) - funktioniert wie ein Charme. Jetzt hat das internationale Komitee beschlossen, das ISBN-Feld auf 13 Zeichen zu erhöhen - leider gibt es keine ALTER TYPE ISBNType....., so dass Ihre einzige Wahl darin besteht, alle Spalten dieses Typs in Ihrer gesamten Datenbank zu löschen und dann den Typ in seiner neuen Form neu zu erstellen. und erstellen Sie alle diese Spalten erneut.
Die Idee ist großartig und ich würde sie gerne benutzen - aber in ihrem jetzigen Zustand ist sie meiner Meinung nach unbrauchbar, was unglücklich ist.
Marc
How cool are User Defined Data Types in MS SQL Server?
Ich persönlich benutze sie nicht, aber ich habe sie gesehen. Ein Problem ist, dass der Client-Code nur den Basistyp IIRC für MS SQL Server erkennt. Und Portabilität/Verhalten über Versionen hinweg.
Ein bisschen spät, aber .. meine 2 cts.
Die benutzerdefinierten Typen erfüllen die Rolle einer Domäne in den konzeptionellen und logischen Modellen. Wenn Sie also Ihr logisches Datenmodell in der physischen Datenbank implementieren möchten, ist die Verwendung von benutzerdefinierten Typen die engste Annäherung. Dies bietet Vorteile wie die Verwendung eines grafischen Modells, das automatisch auf eine Implementierung übertragen werden kann, besser als es ohne Verwendung von UDTs möglich wäre.
Mithilfe von Domänen können Sie Versuche erkennen, eine Postleitzahl in einem SSN-Feld zu speichern und sie zur Laufzeit (oder sogar während der Kompilierzeit) von der Datenbank abfangen zu lassen. Auf diese Weise können unternehmensweite Geschäftsregeln durchgesetzt werden, wo sie durchgesetzt werden sollen: an dem Punkt, an dem die Daten den Speicher erreichen. Überall sonst ist eine Höflichkeit für den Benutzer, aber hier müssen sie unbedingt durchgesetzt werden, um sicherzustellen, dass niemand sie umgeht.
Auch UDTs wie in ANSI SQL: 1999 eingekapselten Methoden, und können Subtyp werden. Das bedeutet, dass bestimmte Änderungen in Geschäftsregeln, die sich mit Einschränkungen befassen, in der Datenbank geändert werden können, ohne dass eine Implementierung berührt werden muss.
Allerdings ... wie derzeit implementiert UDTs viel zu wünschen übrig. Ich bin mir nicht einmal sicher, ob SQL Server den Standard wie beschrieben implementiert, noch weniger sicher über Oracle. Und selbst wenn sie dies tun, werden die Nachteile der Verwendung von UDTs sofort offensichtlich, wenn Sie BI-Tools, ETL-Tools oder andere eher einfältige Tools verwenden: Sie verstehen UDTs normalerweise nicht und selbst wenn sie dies tun, werden sie es nicht sein in der Lage, sie zu verwenden, da die Mehrheit sich auf Grundtypen (int, char und date/time) stützt.
Betrachten wir als Berichtstools einen UDT mit einer Kombination von Feldern. Wie könnte nun ein datenbankunabhängiges ETL-Tool den Typ verstehen? Es müsste in der Lage sein, die Struktur zu verstehen, um sie anzuzeigen oder für Berechnungen zu verwenden. Und das für jede unterstützte Datenbank - eine schwierige Aufgabe. Und da niemand UDTs verwendet, werden sie dies nicht tun. Es ist ein Teufelskreis, aber wir müssen immer noch damit leben.
Abgesehen davon ist UDT-Unterstützung in den meisten Datenbanken auch nicht so heiß. Wechselnde Typen können ziemlich schwierig sein. Während die Syntax überall gleich sein sollte, ist ihre Administration in SQL: 1999 undefiniert und daher überall anders. Versuchen Sie, den Eigentümer eines UDT auf dem SQL-Server für ein Beispiel zu ändern. Früher war das ziemlich schwierig - ich bin mir bezüglich SQL Server 2016 nicht sicher, aber da UDTs nicht wie ein Fokusbereich aussehen, erwarte ich keine größeren Verbesserungen in diesem Bereich.
Schließlich, wenn Sie wirklich komplexen Code zu UDTs hinzufügen, stoßen Sie auf das alte Problem, das Sie in einer Umgebung programmieren, die gute Debugging-Optionen fehlt. Das hilft auch nicht.
Also: Wenn Sie die volle Kontrolle über Ihre Datenbank haben und alle Interaktionen durch Ihre Software gehen, können UDTs sehr hilfreich sein. Wenn nicht, können sie eine große Schmerzen im Nacken sein. Welches ist der Fall in Ihrem Szenario, ist etwas, was Sie nur sagen können.