Endlich geschafft

Der erste Anlauf war ja mehr oder weniger von Anfang an …… völlig zum scheitern verurteilt. So wunderte es mich *eigentlich* nicht, das ich den ersten Anlauf vor ca. 3 Wochen nicht geschafft hatte. Es war zwar sehr ärgerlich, dass mir genau ein Punkt gefehlt hatte …. aber was nicht sein sollte – das soll halt nicht sein.
Ganz im Gegenteil: Diese Erdung in Bezug auf meinem Arbeitgeber, der sich wieder mal „nicht an die Absprachen gehalten hat“ – war sehr sehr sehr wichtig. Damit steht dem Kurswechsel nichts mehr im Wege ….. aber dazu dann an anderer Stelle mehr !
Wie gesagt, der erste Versuch war ein Reinfall – heute habe ich die Wiederholung gemacht und siehe da: Bestanden !
Nun bin ich also in Sachen Java wieder up2date und bin nun SCJP for Java6 – sofern das ganze noch unter dem SCJP-Label geführt wird und nicht mit den restlichen Oracle-Zertifikaten unter dem „OCP“-Dach geführt wird.
Erstmal bin ich erleichtert das ich nun wieder etwas aktueller mit meinem Zertifikaten bin. Die nächste Baustelle wird dann Oracle bzw. Solaris sein … schauen wir mal, wann es da weiter geht.

Never never ever ….

so oder ähnlich würde der Satz anfangen, wenn Tom Kyte die Datenbank gesehen hätte, die ich am Donnerstag abfragen durfte.
Ich durfte für eine „Behörde“ eine Datenbank-Abfrage entwerfen, damit eine Teilmenge der Daten zu einem TAPI-Server kopiert werden können.
Der Auftrag schien mehr als Trivial: Seitens des Software-Herstellers (welcher für die besagte Datenbank zuständig ist), gab es eine fertige SQL-Abfrage mit auf dem Weg. Im Idealfall wäre diese nur anzupassen.
Tja was soll ich sagen, es kam natürlich anders: Selbst der Hersteller scheint keine wirkliche Ahnung von seiner Datenbank (bzw. dessen Schema) zu haben.
Es fing schon mal damit an, dass der zu nutzende SQL-User keine Select-Rechte auf die entsprechenden Tabellen hatte …..
Aber was ich dann zu sehen bekam, war dann der Hammer:
– In der Datenbank gibt es keine Beziehungen zwischen den Tabellen, diese kennt nur die Anwendung.
– Leere Felder sich nicht mit „null“ belegt, sondern mit einem „Leerstring“; sind aber in der Datenbank „nullable“.
– Nachschlagefelder sind mit fixen Konstanten belegt (1=Herr, 2 =Frau..)
– Unique-Constraints wurden auch keine verwendet.
– Und die Dokumentation der Tabellen (vom Hersteller zur Verfügung gestellt) ist auch fehlerhaft.

Wie gesagt, der Hersteller hatte wohl auch keine Ahnung von dem Schema – anders war es nicht zu erklären, dass er auch „Unique“ ausging – wo diese nicht gegeben war … und mit „is not null“ gearbeitet hat – wo doch len(isnull(feld,“)) > 0 besser geeignet ist.

Hätte nie gedacht, so eine Datenbank bei einem Kunden dieser Größenordnung vorzufinden. Zumal diese Datenbank noch eine gewisse Größe hatte. Und dann noch der Hersteller der Software: Keine kleine Krauterfirma ….

Hier lautet meine Empfehlung: Diese Buch lesen und anwenden.