SQL Table etc....

[mk]

Hi *ALL,

bei uns wird gerade eine Diskussion geführt:

Anlegen neuer Tabellen nur mit Create Table

Frage:
Ist es sinnvoll einen primary Key für die Tabellen anzulegen
oder pro Tabelle einen Create unique Index zu erstellen ?

Frage:
Sollte man auf jeden Fall einen Create View für die Tabelle erstellen ?

Frage:
Als Zeichensatz würde ich den Unicode die CCSID 13488 verwenden

Wie ist eure Meinung dazu

Gruß
Michael

Was ich noch vergessen hatte:
Frage: Sollten Schlüsselfelder mit Bezug auf andere Dateien den gleichen Feldnamen haben ?
z.B.


Datei Header Keyfeld HDORNR
Datei Detail Keyfeld DTORNR

oder
Datei Header Keyfeld HDORNR
Datei Detail Keyfeld HDORNR

[BenderD]

- immer einen primary key anlegen (wg. referential constraints)
- immer eine 1:1 view anlegen und nur in dieser view die table verwenden (Entkoppelung physical und logical layer und Entkoppelung application und database)
- für Alfa Keyfelder kein Unicode (das gibt Huddle mit gleich aussehenden Keys)

D*B

[Fuerchau]

Ein Primary Key ist auf jeden Fall immer sinnvoll.
Allerdings könnte man hier auf ID-Methoden (Single-Key) zugreifen, das ist dann bei Referenzen einfacher und diverse Frameworks (Java, .NET, u.ä.) kommen damit auf jeden Fall zurecht.
Unicode macht ebenso Sinn da damit alle modernen Sprachen auch zurechtkommen.
Views werden nur benötigt, wenn man den tatsächlich bestimmte Sichten (Berechnungen, Joins, usw.) benötigt.
Dies ergibt sich aber auf jeden Fall erst im Laufe des Projektes.
Ebenso auch zusätzliche Indizes ja nach Bedarf.

Viel wichtiger ist eigentlich die Journalisierung.
Der Create Table trägt diese automatisch ein, wenn in der Lib ein Journal vorhanden ist.
Dies wäre ebenso auch empfehlenswert.

Per CREATE SCHEMA / COLLECTION erhält man eine Lib, die sowohl ein Journal als auch diverse SYS-Views mit eingeschränkter Sicht auf die Lib enthält.
Damit sollte man dann auch anfangen.

[andreaspr@aon.at]

Viel wichtiger ist eigentlich die Journalisierung.
Der Create Table trägt diese automatisch ein, wenn in der Lib ein Journal vorhanden ist.

Der CREATE TABLE fügt eine Tabelle nur dann hinzu wenn das Journal den name QSQJRN hat.
Egal ob es automatisch mit dem Befehl CREATE SCHEMA oder manuel mit dem Command CRTJRN erstellt wurde.

Bei Unicode verwende ich die CCSID 1200.
Bzw. wird diese automatisch bei dem Datentyp NVARCHAR verwendet.
In der Firma wird jedoch die CCSID 13488.

lg Andreas

[B.Hauser]

@ Journal:
Wenn allerdings in der Datenbibliothek ein Datenbereich mit dem Namen QDFTJRN hinterlegt ist, der in Stelle 1-10 die Bibliothek in der sich das Journal befindet und in Stelle 11-21 den Journal-Namen und auf den folgende 10 Positionen *FILE und anschließend ab Stelle 31 entweder *ALLOPR oder *CREATE steht, werden alle Tabellen (und DDS beschriebene physische Dateien) beim Erstelln direkt in dem angegebenen Journal registriert.

@ Tabellen:
zur Abwechslung muss ich mal Dieter zustimmen (zumindest in den ersten beiden Punkten), d.h.
1. Immer Primary Key anlegen (für referentielle Integritäten - brauchen nicht zwansläufig sofort aktiviert werden)
2. Immer eine View, die 1:1 der Tabelle entspricht anlegen und alle abhängigen Views basieren auf dieser View stellen und alle Zugriffe auf die Tabelle nur über Views erstellen.
Diese Vorgehensweise erlaubt, u.a. auch ein zukünftiges Redesign der Datenbank (falls dies erforderlich ist), ohne die Programme anpacken zu müssen.
3. Für performante Zugriffe sind zumindest Indices oder (Unique/Primary Key Constraints) über die Key-Felder. Andere notwendige Zugriffswege ergeben sich aus den (SQL) Abfragen, die auf die Tabelle/Views ausgeführt werden.

Birgitta

[Fuerchau]

CCSID 1200 ist UTF-8 und wird native ohne Umwandlungsfunktion von keiner Sprache unterstützt.
CCSID 13488 ist UCS2 und wird standardmäßig von Java, .NET, VB6 als String verwendet.
COBOL kennt das als "National" und ILERPG als Feldtyp "C".
1200 muss daher immer intern in UCS2 gewandelt werden.
Dies gilt auch für die Anzeige/das Drucken. Es gibt zwar UCS2-Schriften aber keine UTF-8-Schriften.

Meine Tests bezüglich Schlüsseln mit UTF8 haben keine Probleme bereitet, mit UCS2 schon gar nicht.
Sogar Substring funktioniert, da intern immer über UCS2 gegangen wird.

N(var)Char wird tatsächlich leider als UTF8 verwendert. Besser ist auf jeden Fall immer UCS2.

Was die Grundsatz-View angeht, so benötigt man die erst, wenn man denn an der Table veränderungen macht. Dann benenne ich die Table um erstelle ich eine View die wie die Table aussieht.
So habe ich das mal als SQL-DB-Designer gelernt und diese Meinung vertrete ich auch.

[BenderD]

... es gibt Argumente, warum ich das anders mache:
- der rename Table wird Dialekt abhängig unterschiedlich gemacht
- nach einem rename einer table
-- muss man die Skripte für die Indexe anpassen
-- muss man Programme anpassen, die während Bulk Operationen Journalisierung beenden
-- es soll auch noch Leute geben, die an Rekord Löffel Ekzem leiden, die reagieren da mit vermehrtem Ausschlag, wenn aus einer Table eine View wird...

D*B

[Fuerchau]

Ok, das ist nachvollziehbar.
Aber wenn schon Table, dann doch native SQL und kein RLA!

[AG1965_2]

CCSID 1200 ist UTF-8 und wird native ohne Umwandlungsfunktion von keiner Sprache unterstützt.

ganz kleine Korrektur: 1200 ist UTF-16BE. Früher war es angeblich mal UCS-2.
@Andreas:
Die Default CCSID für *UCS2 ist 13488, nicht 1200. Siehe RPG-Handbuch V7R1 TR-7 Seite 2-31 und 4-51 und 4-62.
Ich halte daher 13488 für den aktuelleren Wert. Es scheint auch ziemlich synonym zu sein; tw. sind diese Diskussionen rein philosophischer Art.
Woanders, die Quelle habe ich leider nicht, steht sinngemäß, dass 13488 die Lieblings-Unicode-CCSID des System i ist.
Das war schon wohlüberlegt damals. :-)

[Fuerchau]

Stimmt, 1200 ist UTF16, 1208 ist UTF8.

UCS2 war schon immer 13488.
Leider ist die Übersetzung für N(VAR)CHAR nicht UCS2 sondern wohl UTF16, einfach blöd.
Bei Oracle entspricht N(VAR)CHAR übrigens UTF8 und die Länge wird immer in Bytes angegeben.
Also NVARCHAR(1), was leider auch vorkommt, kann real kein UTF8 aufnehmen.

[andreaspr@aon.at]

@Andreas:
Die Default CCSID für *UCS2 ist 13488, nicht 1200. Siehe RPG-Handbuch V7R1 TR-7 Seite 2-31 und 4-51 und 4-62.

Keine Ahnung was du mir damit sagen willst??
Habe nichts davon geschrieben dass UCS2 die CCSID 1200 hat. Siehe meinen Post

[AG1965_2]

Ich bezog mich auf diesen Abschnitt deines Posts, den ich natürlich gelesen habe.
Dir war anscheinend nicht klar, warum wir 13488 genommen haben.[QUOTE=andreaspr@aon.at;87584]
Bei Unicode verwende ich die CCSID 1200.
Bzw. wird diese automatisch bei dem Datentyp NVARCHAR verwendet.
In der Firma wird jedoch die CCSID 13488.
[/QUOTE]