SQL und Feldreferenz

[mk]

Hallo zusammen,

bei den DDS beschriebenen Dateien ist die Definition über eine
Feldreferenzdatei ja eine feine Sache.

Gibt es im SQL eigentlich eine ähnliche Funktionalität ?
Gruß
Michael

[Fuerchau]

Ja, aber nur seeeehr ähnlich:
Per "create type" kannst du dir für jede Art von Feldtyp einen Basistyp definieren, der alle Eigenschaften aufweist, die du brauchst.
Überall wo du dann einen Typ angeben musst, kannst du dann auch diesen Typ angeben.

Create Type ArtikelNrType as char(20) with comparisions

Create Mytable (ArtikelNr as ArtikelNrType not null with default, ....)

Wie du siehst, eben nur fast.
Bestimmte Attribute wie "not null", "with default", Columntext usw. sind leider tabellenspezifisch und müssen dann da trotzdem werden.
Eine spätere Änderung des Types kann dann diverse Konsequenzen haben.
Zusätzlich werden jeweils 2 Konvertierungsfunktionien generiert, die automatisch zwischen deinem Typ und dem skalaren Typ casten müssen.

Wie das zur Laufzeit ausieht, wie der Optimizer damit zurechtkommt, wenn Indizes auf UserTypes gelegt werden usw. usf., darüber gibt die Doku leider nichts her.

[BenderD]

... das Pendant zu der Referenzierung ist:

create table blabla as(
select refFeld1 neuerName, refFeldy nochEinName...
from MyReftable
) with no data

ob das mit der Feldreferenz auch auf den zweiten Blick eine gute Idee ist, sei dahingestellt...

@Baldur: das mit den Types ist was anderes, sowas kann DDS überhaupt nicht. Am Rande sei hier noch vermerkt, dass UDTs casts benötigen, die in Key Beziehungen in den Keller führen. Zusätzlich sei noch angemerkt, daß ein Typ ein Typ und somit nicht änderbar ist und das auch gut so ist.

D*B

[B.Hauser]

SQL-Tabellen können basierend auf anderen Dateien (also auch Feld-Referenz-Dateien) erstellt werden.
CREATE TABLE
as (SELECT Fld1 as XYFLD, Fld2 as XYFLDA, ...
From FldRef)
With No Data;

Bis zum aktuellen Technologie Refresh sind die Referenz-Felder jedoch nirgends ersichtlich.
Mit TR7 werden die Feld-Referenz-Informationen gesichert und können z.B. über die entsprechenden Catalog-Views angezeigt/ermittelt werden.

Von UDT (User Defined Types) würde ich die Finger lassen. Ein UDT kann nicht geändert werden, solange noch irgend ein Objekt einen Bezug zu diesem UDT hat.
Außerdem können UDTs nicht direkt verglichen werden, z.B. wenn die Artikel-Nr. 9,0 definiert ist, kann sie nicht direkt mit 123 verglichen werden, sondern muss in Dezimal (oder 123 muss in den UDT)
konvertiert.

... und mit native I/O könnte es zusätzlich Probleme geben, da kein entsprechender native Datentyp in RPG vorhanden sein wird.

Birgitta

[camouflage]

@Birgitta, gefällt mir - den "Like" Button hättest Du dir verdient!

[BenderD]

Außerdem können UDTs nicht direkt verglichen werden, z.B. wenn die Artikel-Nr. 9,0 definiert ist, kann sie nicht direkt mit 123 verglichen werden, sondern muss in Dezimal (oder 123 muss in den UDT)
konvertiert.

... das ist ja gerade Sinn des Ganzen!
Ein UDT EURO ist mit einem UDT DOLLAR erst nach einem CAST vergleichbar und der Typ APFEL läss sich nicht nach BIRNE casten, weil Äpfel was anderes als Birnen sind!

D*B

[Fuerchau]

"with comparisions" erstellt automatische casts, die dann eben "ArtikelNr = 123" erlauben.
Außerdem unterscheidet die DB noch zwischen UDT's und skalaren UDT's, die also auf bekannten Feldtypen basieren.
Klar ist, dass der Optimizer das ggf. nicht beherrscht, wobei eben skalare UDT's beherrschbar wären.
Bleibt halt mal auszuprobieren.

[mk]

Hi,

irre. Das Wissen ist ja fast unheimlich