Der Umgang mit der Objektart: DOMAIN

Forum für neue Firebird-Anwender.

Moderator: thorben.braun

Gerd
Beiträge: 162
Registriert: Di 1. Okt 2019, 17:13

Fr 3. Apr 2020, 12:43

Hallo

In der Firbird Dokumentation ist u.a. folgendes zu lesen:
"Sobald es in der Datenbank definiert wurde, kann es wiederholt verwendet werden, um Tabellenspalten, PSQL-Argumente und lokale PSQL-Variablen zu definieren."

Die Ausgangssituation:
Ich habe mich mit dem ISQL Tool zu einer lokalen Firebird Datenbank adressen.fdb als SYSDBA verbunden.

Code: Alles auswählen

gerd@gerd-MS-7641:~$ isql -z
ISQL Version: LI-T4.0.0.1436 Firebird 4.0 Beta 1
Use CONNECT or CREATE DATABASE to specify a database
SQL> connect '/home/gerd/Firebird/Datenbanken/adressen.fdb' user 'sysdba' password 'geheimes_sysdba_passwort';
Server version:
LI-T4.0.0.1436 Firebird 4.0 Beta 1
Database: '/home/gerd/Firebird/Datenbanken/adressen.fdb', User: SYSDBA
SQL> SHOW TABLE anschrift;
ID                              INTEGER Not Null Identity (by default)
VORNAME                         VARCHAR(50) Nullable 
NAME                            VARCHAR(100) Nullable 
STRASSE                         VARCHAR(50) Nullable 
PLZ                             VARCHAR(5) Nullable 
CONSTRAINT INTEG_1:
  Primary key (ID)
SQL> CREATE DOMAIN D_DATE AS
CON> DATE DEFAULT CURRENT_DATE
CON> NOT NULL;
SQL> 
SHOW TABLE anschrift zeigt den einfachen Aufbau der einzigen Tabelle in der Datenbank.
Dann habe ich wohl eine DOMAIN erzeugt.

Und bitte wie verwende ich das jetzt beispielhaft in der Datenbank adressen.fdb ?

Danke für weiterführende Hinweise.


Viele Grüße
Gerd
Linux Mint 20 Ulyana Cinnamon 4.6.7
Firebird 4.0 Beta 2, Superserver - ISQL: LI-T4.0.0.1963
Lazarus 2.0.10 - FPC 3.2.0
bfuerchau
Beiträge: 189
Registriert: Mo 7. Mai 2018, 18:09

Fr 3. Apr 2020, 13:02

DU hast keine Domain erstellt sondern das macht die DB in diesem Fall automatisch.
In der RDB$RELATION_FIELDS kann man sich das anschauen.
RDB$FIELD_NAME ist dein gewählter Name, RDB$FIELD_SORCE verweist auf die DOMAIN, wo dann erst der Typ festgelegt wird.
https://firebirdsql.org/file/documentat ... mn-de.html

Im Create Table wird dann nur noch "Feldname Domainname" verwendet.
Gerd
Beiträge: 162
Registriert: Di 1. Okt 2019, 17:13

Fr 3. Apr 2020, 13:31

bfuerchau hat geschrieben:
Fr 3. Apr 2020, 13:02
...
In der RDB$RELATION_FIELDS kann man sich das anschauen.
RDB$FIELD_NAME ist dein gewählter Name, RDB$FIELD_SORCE verweist auf die DOMAIN, wo dann erst der Typ festgelegt wird.
...

Im Create Table wird dann nur noch "Feldname Domainname" verwendet.
Schaue ich mir übers Wochenende gerne und detailliert an. Danke. :)


Viele Grüße
Gerd
Linux Mint 20 Ulyana Cinnamon 4.6.7
Firebird 4.0 Beta 2, Superserver - ISQL: LI-T4.0.0.1963
Lazarus 2.0.10 - FPC 3.2.0
Gerd
Beiträge: 162
Registriert: Di 1. Okt 2019, 17:13

Fr 3. Apr 2020, 17:43

Hallo bfuerchau.

So, ich denke, dass ich es jetzt Verstanden habe.
Eine wirklich tolle Angelegenheit die Sache Mit den DOMAINS. Sie hilft Zeit sparen - die Datenbank wird einheitlich.

Hier mein erster kleiner Erfolg bei der Anwendung einer DOMAIN mit den von mir vergebenen Namen D_DATE:

Code: Alles auswählen

gerd@gerd-MS-7641:~$ isql adressen.fdb
Database: adressen.fdb, User: GERD
SQL> ALTER TABLE ANSCHRIFT ADD ZUGRIFF D_DATE;
SQL> SHOW TABLE anschrift;
ID                              INTEGER Not Null Identity (by default)
VORNAME                         VARCHAR(50) Nullable 
NAME                            VARCHAR(100) Nullable 
STRASSE                         VARCHAR(50) Nullable 
PLZ                             VARCHAR(5) Nullable 
ZUGRIFF                         (D_DATE) DATE Not Null DEFAULT CURRENT_DATE
CONSTRAINT INTEG_1:
  Primary key (ID)
SQL> 
Ich habe der Tabelle anschrift das Feld ZUGRIFF hinzugefügt und als Datentyp die DOMAIN D_DATE zugewiesen. (Sagt man das so?)

Sehr schöner Hinweis von Dir. Danke. :)


Viele Grüße
Gerd
Linux Mint 20 Ulyana Cinnamon 4.6.7
Firebird 4.0 Beta 2, Superserver - ISQL: LI-T4.0.0.1963
Lazarus 2.0.10 - FPC 3.2.0
bfuerchau
Beiträge: 189
Registriert: Mo 7. Mai 2018, 18:09

Sa 4. Apr 2020, 07:54

Den "Not Null DEFAULT CURRENT_DATE" kannst du dir auch sparen, wenn du den bereits in der Domain definiert hast.
Somit kannst du noch ein paar mehr Änderungen an einer Tabelle durchführen, solange es nur Domain-Ämderungen betrifft.
Gerd
Beiträge: 162
Registriert: Di 1. Okt 2019, 17:13

Sa 4. Apr 2020, 11:49

bfuerchau hat geschrieben:
Sa 4. Apr 2020, 07:54
... wenn du den bereits in der Domain definiert hast. ...
Hallo bfuerchau.

Ja, den hatte ich in der DOMAIEN 'D_DATE' mit hinterlegt. :)

Ich verinnerliche mir eine mit CREATE DOMAIN D_NAME AS erstellte Firbird Datenbank DOMAIN wie folgt:

Bestimmt jeder kennt bei einer Textbearbeitung die Möglichkeit z. B. einer Überschrift der Ebene 1 die dafür zuvor erstellte Format-Vorlage Überschrift1 zuzuweisen.
Das Ergebnis ist, dass diese Überschrift alle Einstellungen dieser Format-Vorlage annimmt.
Macht es sich erforderlich, dass im Dokument diese Überschrift eine andere Ebene (z.B. Ebene 2) erhalten soll, dann wird ihr eine zuvor erstellte Format-Vorlage der Ebene 2 zugewiesen.
Bekanntlich ist das tolle daran, dass alle Überschriften der Ebene 1 im Dokument, nach Zuweisung, automatisch als Überschriften der Ebene 2 dargestellt werden.

Nun noch das Ganze auf eine Firebird Datenbank umgemünzt:
Mittels einer DOMAINE hinterlegt man einmalig die Eigenschaften (z.B. DATENTYP, sogar auch CHECK-Einschränkungen, ...), die ein DB-Feld haben soll (--> erstellte Format-Vorlage) und benennt sie aussagekräftig.
Diese DOMAINE (--> Format-Vorlage) kommt jedes mal dann zum Einsatz (CREATE TABLE, ALTER TABLE), wenn prädestinierte Datenbankfelder in einer oder mehreren Tabellen der Datenbank deren Zuweisung erhalten sollen (--> Überschrift Ebene 1).
Man spart Zeit und es ist eine Unterstützung bei der Entwicklung und auch Überarbeitung der Datenbank.

In Firebird wurde das Konzept "benutzerdefinierter Datentypen" in Form von Domains implementiert. Mehr ...

Aber, was ich bisher nicht feststellen konnte ist, ab wann Firebird CREATE DOMAIN / ALTER DOMAIN / DROP DOMAIN kann.

Und abschließend: Für jede DOMAIN sollte stets ein aussagekräftiger Name benutzt werden.



Danke @bfuerchau


Viele Grüße
Gerd
Linux Mint 20 Ulyana Cinnamon 4.6.7
Firebird 4.0 Beta 2, Superserver - ISQL: LI-T4.0.0.1963
Lazarus 2.0.10 - FPC 3.2.0
bfuerchau
Beiträge: 189
Registriert: Mo 7. Mai 2018, 18:09

So 5. Apr 2020, 13:20

Domains gibt es schon lange, allerdings gibts den "Alter Domain" glaube ich, erst seit 2.5.
Voher musst man den Typ direkt in der Domainstable anpassen.
Aber wer benutzt schon nochdie älteren Versionen :) .

Im Gegensatz zu Officevorlagen (... basiert auf ...) gibt es keine Vererbung bei Domains.
Machst du also beim Create Table den Verweis auf eine Domain mit Ergänzung, wird sicherlich eine neue Domain erstellt (kannst du ja mal verifizieren).
Das Anpassen also der Basisdomain wird dann keine Auswirkung auf die Kopie haben.
Ein Vergleich mit einer Office Formatvorlage ist daher nicht möglich!
Beispiel: Überschrift 2 unterscheidet sich von Überschrift 1 nur in der Schriftgröße.
Änderst du nun die Schriftart in Überschrift 1, ändert diese sich automatisch in Überschrift 2. Es geht sogar noch weiter, da letztlich alle Formatvorlagen auf "Standard" basieren. Somit lässt sich die Schrift in "Standard" ändern und alle Formatvorlagen passen sich an.
Das Ganze hat allerdings einen Haken:
Die Formatvorlagen liegen i.d.R. alle in der "normal.dot/.dotx". Jedes Gerät/User hat aber hier seine eigene Version. Kopiert man die Vorlagen nicht ins Dokument selber (Formatvorlagen organisieren), sieht dann jeder ein anderes Layout.

Was sind schon sprechende Namen:
Das Konzept kennt man, also ich, z.B. von der DB2/400 (AS/400, IBM i) mit sogenannten "Reference Tables". Hier wird nun jeder Typ, Kundenummer, Auftragsnummer, ..., aufgeführt und kann somit in jeder neuen Tabelle nur beim Erstellen referenziert werden.
Nun kann man auch eigene Typen erstellen, die allerding nicht unerhebliche Laufzeitprobleme darstellen, da es für jeden Type eine Getter/Setter-Function gibt um auf die Basistypen der DB zu casten.
Übrigens würde ich das "D_" weglassen, da sich aus der Syntax ergibt, dass es eine Domain sein muss.

Dies ist bei der Firebird gottseidank anders, da von jeher mit Domains gearbeitet wird.
Somit sind zusätzliche Cast-Funktionen nicht erforderlich, da ein Feld "Kundennummer" sich u.U. von Decimal(8, 0) generell nicht unterscheidet. Somit sind Vergleiche (where, Join) von Kundennummer auf Auftragskunde nicht performancerelelvant da der Basistyp ansich vergleichbar ist.

Arbeitet man allerdings bei .Net o.ä. mit Frameworks, die einem ein Datenbankmodell selbstständig generieren, kann man das Konzept Domain gleich wieder vergessen, da im Framework der Typ als Eigenschaft/Klasse definiert wird und Richtung Datenbank die Standardtypen verwendet werden.
Gerd
Beiträge: 162
Registriert: Di 1. Okt 2019, 17:13

So 5. Apr 2020, 18:32

Hallo bfuerchau.

Danke für Deine Hinweise und weiterreichenden Informationen zum Thema. :)

Hier steht geschrieben:
"Domain ist eine Objektart innerhalb einer relationalen Datenbank. Eine Domain wird als ein bestimmter Datentyp mit einigen Attributen erstellt. Sobald es in der Datenbank definiert wurde, kann es wiederholt verwendet werden, um Tabellenspalten, PSQL-Argumente und lokale PSQL-Variablen zu definieren. Diese Objekte erben alle Attribute der Domain Einige Attribute können bei Bedarf überschrieben werden, wenn das neue Objekt definiert ist."

Wissende nutzen die von Firebird bereitgestellte Funktion DOMAIN und reizen sie sicherlich für ihre Zwecke aus.

Anfänger/Einsteiger lesen das oben zitierte - und gehen wohl eher weiter.
Deshalb dachte ich, dass es gut sei, hier mitzuteilen, was man damit anfangen könnte - und wie man sich das vorstellen könnte, damit man zu diesen Datenbank-Vorgängen eine innere Verbindung aufbauen kann. Ich finde den 'Vergleich' (der eigentlich keiner soll) durchaus nachvollziehbar. Diese Beschreibung soll erst einmal helfen das Interesse zu wecken. Das fachlich-korrekt gehaltene, aber meiner Meinung nach 'tiefgekühlte' Zitat, hilft einem erst später die Möglichkeiten zu erkennen und sie fehlerfrei anzuwenden. Zumindest ging es mir so. Ich bin ab Version 3.0 eingestiegen. Das Thema DOMAIN hatte ich irgendwann mal auf den Bildschirm - und zack, da war es auch schon wieder weg.

Ich möchte nur jeden empfehlen nach einer Einarbeitungszeit sich auch einmal damit auseinander zu setzen. Für MICH jedenfalls war es die Entdeckung des Monats - oder so ... :)


Viele Grüße
Gerd
Linux Mint 20 Ulyana Cinnamon 4.6.7
Firebird 4.0 Beta 2, Superserver - ISQL: LI-T4.0.0.1963
Lazarus 2.0.10 - FPC 3.2.0
bfuerchau
Beiträge: 189
Registriert: Mo 7. Mai 2018, 18:09

So 5. Apr 2020, 21:55

Herzlichen Glückwunsch. :lol: :lol: :lol:

Der Create Table mit Domains geht durchaus um Faktor 100 schneller als ohne Domains und ist daher weniger belastend.
Dies ist aber nur relevant, wenn man wie ich in wenigen Sekunden durchaus 30 - 50 Tabellen erstellt und durchschnittlich in 0,010 Sekunden 1 Tabelle gelöscht werden kann.
Das Problem mit den automatischen Domains ist, dass diese nicht gelöscht werden, wenn sie verwaist sind, also nicht mehr benötigt werden.
Dies ist aber nicht performancerelevant.
Gerd
Beiträge: 162
Registriert: Di 1. Okt 2019, 17:13

Mo 6. Apr 2020, 08:27

Guten Morgen bfuerchau.
bfuerchau hat geschrieben:
So 5. Apr 2020, 21:55
... Der Create Table mit Domains geht durchaus um Faktor 100 schneller als ohne Domains und ist daher weniger belastend. ...
Ja, insbesondere auch dann, wenn mit Firebirds Tool ISQL gearbeitet wird.
bfuerchau hat geschrieben:
So 5. Apr 2020, 21:55
... Dies ist aber nur relevant, wenn man wie ich in wenigen Sekunden durchaus 30 - 50 Tabellen erstellt und ...
Wie bitte soll denn das in / mit Firebird gehen? Hättest Du da mal so 1 - 3 Stichwörter? Danke.
bfuerchau hat geschrieben:
So 5. Apr 2020, 21:55
... Das Problem mit den automatischen Domains ist, dass diese nicht gelöscht werden, wenn sie verwaist sind, also nicht mehr benötigt werden. ...
Stimmt - das ist tatsächlich so!
Da formuliere ich doch gleich einmal einen Feature-Wunsch bezogen auf das Firebird Tool GFIX. Das scheint mir dafür geeignet zu sein. Wäre hilfreich wenn das käme.



Viele Grüße
Gerd
Linux Mint 20 Ulyana Cinnamon 4.6.7
Firebird 4.0 Beta 2, Superserver - ISQL: LI-T4.0.0.1963
Lazarus 2.0.10 - FPC 3.2.0
Antworten