Wie ist der richtige Ablauf der Erstellung einer Datenbank auf der AS/400

[watchdogg]

Hallo,


ich habe schon einige Datenbanken auf anderen DBMS (SqlServer, MySql) erstellt und möchte nun gerne mal eine auf unserer AS/400 DB2 bauen. Die Gründe dafür sind Ausfallsicherheit und die Ausnutzung der Ressourcen und der Leistung auf dieser Maschine.
Warum soll man den Mercedes nicht auch fahren, wenn man schonmal einen da hat :-) ?

Da ich aus der Windows-Ecke komme, bin ich etwas unsicher, wie ich dazu richtig vorgehen sollte und möchte gerne eure Vorschläge dazu erfragen.

Ich habe mir schon in einer separaten Bibliothek, anhand eines Tutorials, eine physische Datendatei (Tabelle) per SEU erstellt. Dazu erhielt ich eine logische Datei zu der physischen Datei.
Eine andere Tabelle habe ich direkt in STRSQL mit reinem SQL (CREATE TABLE ...) erzeugt. Auch das hat funktioniert. Allerdings habe ich hierfür keine Logische Datei erhalten und es kam eine Meldung, dass sinngemäß das Journal die Datei nicht erfasst hat (oder so ähnlich?).

Jetzt bin ich verunsichert, was der richtige Weg ist eine Datenbank auf der AS/400 aufzubauen. Aus dem Bauch heraus würde ich eine separate Bibliothek erstellen (Datenbank) und darin physische Dateien (Tabellen) mit SQL erstellen, weil ich das von anderen DBMS so kenne. Ich bin aber ziemlich unsicher, ob das der richtige Weg ist.
Deshalb möchte ich gerne eure fachkundigen Meinungen vorher einholen.

Was machen diese logischen Dateien? Sind das so eine Art Index-Dateien für die physischen Dateien? Was ist der Vorteil oder auch der Nachteil von der Erstellung per SQL-Befehlen?



Gruß, watchdog

[BenderD]

... am Besten fängt man an mit create schema, das erstellt eine Bibliothek mit allem, was gebraucht wird (Journale, Data Dictionary etc.). Anschließend kannst Du dieselben Scripte, die Du für andere Datenbanken verwendest auf der AS/400 mit RUNSQLSTM (Parameter naming muss auf *SQL stehen) abfeuern und das wars. Intern werden dann views und indexe zu LFs, das braucht Dich aber nicht zu interessieren, wenn Du ausschließlich mit SQL auf die Daten los gehst.

D*B

[B.Hauser]

Zunächst einmal vergiss DDS, SEU und STRSQL. Das hat alles ausgedient.
Lade Dir Access Client Solutions (ACS)runter und installiere das.
Unter Datenbanken hast Du einiges an Auswahlmöglichkeiten, u.a. kanns Du da auch dein Schema, deine Tabellen, Views und andere Datenbanken Objekte über Wizards generieren. Man kann natürlich auch unter "Run SQL Script" ein SQL Skript erstellen oder ein vorhandenes SQL-Skript ausführen.

Ansonsten unterscheidet sich eine (mit SQL beschriebene) Datenbank nicht viel von anderen mit SQL beschriebenen Datenbanken, da ja alles auf dem SQL Standard beruht.
Es gibt vielleicht einige kleine Abweichungen, z.B. dass wir auf der IBM i (und bitte verwende nicht mehr den Begriff AS/400 - das war 1988!!!) keine Table Spaces und/oder Buffers kennen. aber die Unterschiede sind marginal.

Ansonsten solltest Du Dir die SQL-Referenz der Db2 for i Database Db2 for i - SQL Reference daneben legen, da sind sämtliche Befehle und Ausprägungen beschrieben.

Was leider in ACS fehlt (und auch sonst in den gängigen IBM i Tools nicht enthalten ist) ist ein vernünftiges Tool um eine Datenbank zu modellieren.

Birgitta

[Fuerchau]

Wobei SQL-Standard nicht auf allen DB's derselbe ist.
Beim Microsoft SQL-Server und auch bei Oracle gibt es doch erhebliche Unterschiede ins besonders in der Verfügbarkeit von Feldtypen, DDL-Syntax, scalaren Funktionen und sogar im Ablauf (z.B. Satzversioning bei Snapshot-Transaction).
Man muss da leider doch auf einige nicht unerheblich Änderungen und Verhalten aufpassen.
Spätestens aber bei Triggern und Prozeduren ist die AS/400 massiv im Vorteil.

[BenderD]

... vielleicht sollte ich da noch ergänzen:
- am Besten hält man sich eng an den SQL Standard, damit kommt man durchaus aus und das geht dann auf allen Datenbanken, nicht nur auf der AS/400 (unter dem Namen ist die Maschine immer noch am bekanntesten). Die ANSI SQL Doku ist leider kostenpflichtig, recht gut dargestellt wird der Standard in der PostgreSQL Referenz.
- arbeitet man mit mehreren Datenbanken, empfiehlt sich SQuirreL (oder ein ähnliches Tool) als Frontend, das ist besser als alle Datenbank spezifischen Tools, die immer versuchen einen an das lokale Dialekt zu nageln.
- die Erstellungsskripte kann man zwar von jedem Frontend abfeuern, macht man das auf dem Server selber, muss man zwar mit dem etwas hölzernen RUNSQLSTM vorlieb nehmen, kriegt aber eine durchgängige, zuverlässige Referenz zwischen Skript und Tabellen.
- ob die AS/400 wirklich mit Triggern und Procedures etc. im Vorteil ist, da mache ich mal ein dickes Fragezeichen dran, da habe ich durchaus andere Erfahrungen gemacht.

D*B

[watchdogg]

Danke euch allen.

Das mit dem Create Schema habe ich gemacht.
Anschließend mit i Access - Client Solutions die Tabellen erstellt.
Die äußerst umfangreiche Referenz habe ich mir auch runtergeladen - es gibt da scheinbar schon einige spezielle SQL-Statements gegenüber anderen DBMS.
Aber alles machbar.

Meine erste ASP.NET Anwendung läuft bereits mit der neuen Datenbank (immerhin 2 Tabellen :-) ).
Gemappt habe ich die Tabellen mit dem OpenSource ORM Dapper - welches ich .NET Programmierern sehr ans Herz legen möchte.
Gerade in Sachen Datenbindung (@B.Hauser) System i (AS/400) ein guter EntityFramework-Ersatz!

Auf jeden Fall habt ihr mir sehr weitergeholfen, sodass ich in der Richtung jetzt weiterkomme. Ich möchte nämlich eine Art GUI für Windows bauen, um Daten besser aus dem PPS auf unserer Maschine auszulesen.

Viele hier arbeiten noch mit der 5250-Emu - das macht vor allem neuen Mitarbeitern stark zu schaffen!


Gruß, watchdogg

[BenderD]

Die äußerst umfangreiche Referenz habe ich mir auch runtergeladen - es gibt da scheinbar schon einige spezielle SQL-Statements gegenüber anderen DBMS.
Gruß, watchdogg

... die man möglichst nicht verwenden sollte!!!

D*B

[watchdogg]

create table schema.person (
id integer not null GENERATED ALWAYS AS IDENTITY
(START WITH 1 INCREMENT BY 1),
anrede varchar(20),
vname varchar(40),
nname varchar(40),
geburt date,
strasse varchar(40),
PRIMARY KEY (id))

Das AUTO_INCREMENT habe ich z.B. nur mit dem Befehl hinbekommen.

[Fuerchau]

Wenn ich DDL-Statements von Oracle oder Microsoft adaptieren muss, gibt es kein einziges Script, dass nicht manuell überarbeitet werden muss.
Problematisch ist dabei immer der Datentyp DateTime, da es den so auf der AS/400 nicht gibt.
Den muss man als Timestamp ersetzen, darf ihn aber so nicht mit dem SQL-Server austauschen.

Was die .Net-Integration angeht, so bin ich eigentlich mit der VisualStudio-Unterstützung äußerst zufrieden was die Erstellung von streng typisierten Datasets, Queryabfragen und generierten DBAdaptern angeht sowie den dazugehörigen Datenbindungen.

[watchdogg]

Du hast aber sicher einen kostenpflichtigen Datenprovider von IBM mit Visual Studio Integration Tools, oder?

[BenderD]

create table schema.person (
id integer not null GENERATED ALWAYS AS IDENTITY
(START WITH 1 INCREMENT BY 1),
anrede varchar(20),
vname varchar(40),
nname varchar(40),
geburt date,
strasse varchar(40),
PRIMARY KEY (id))

Das AUTO_INCREMENT habe ich z.B. nur mit dem Befehl hinbekommen.

... das ist ANSI SQL 2003, wenn Du was anderes kennst, dann solltest Du überprüfen, ob die andere Datenbank die ANSI Formulierung auch kennt.
Je näher man sich am Standard hält, umso weniger Probleme hat man beim portieren. Das gilt auch für Oracle, MySQL, MS SQL Server, da werden oft nicht Standard Konstrukte verwendet, auch das sollte man sich tunlichst abgewöhnen.

D*B

PS: da gibt es auch ein schönes Tool: http://www.sqlines.com/online

[Fuerchau]

Der VS-Datenprovider wird von CA doch mitgebracht (ODBC/OLEDB/native .Net-Treiber).
So wie eigentlich jede Datenbank.