dr.dimitri

Zusätzlich ist die Toolunterstützung bei XML sehr gut, bei CSV gibt es keine Toolunterstützung.

Jedes ETL Tool beherrscht die Transformation von csv in irgendwas und umgekehrt.

Olymp und Seidensticker sind aber aus eigener Erfahrung spitze weil man die sogar als Mann super bügeln kann xD

Die musst Du überhaupt nicht bügeln wenn Du es richtig machst. Ohne schleudern einfach tropfnass auf einen Kleiderbügel und dann (z.B. in der Dusche) aushängen lassen bis sie trocken sind. Dauert ca. 7-8 Stunden, die kleinen Unebenheiten gehen dann beim Tragen mit der Körperwärme raus.

Ich arbeite bei einer Versicherung. Für die IT würde ich bei der Vorstellung zu sauberer Jeans, Businesshemd (Olymp, Seidensticker, Eterna, Eton etc.) und, falls vorhanden und man es persönlich auch möchte, noch ein passendes, sportlich-legeres Sakko raten.

Statt Jeans wäre natürlich auch eine Chino (dunkelblau, kamel, braun, schwarz) oder eine äquivalente Stoffhose möglich. Schwarze oder dunkelbraune Halbschuhe/Stiefel (je nach Wetterlage). Sneaker und Turnschuhe würde ich erstmal daheim lassen, bis ich einschätzen kann wie das ankommt.

Kein Sweatshirt, Kaputzenpulli, Oversizehose aber das muss ich einem Bankkaufmann eh nicht sagen

Kann man sich das irgendwie berechnen?

Sofern Du das verwendete Protokoll genau kennst ja. Ansonsten nein.

Ich kann zum Thema fachlich nicht viel beitragen, finde die Präsentation aber inhaltlich erstmal gut. Du verzichtest weitgehend auf nerviges "hereinfliegen" von Text und die Textdichte ist, bis auf ein paar Ausnahmen, angemessen.

Die dunkle Hintergrundfarbe könnte beim Ausdrucken zu lesbarkeitsproblemen führen. Schon mal getestet?

Die Netzabdeckungskarte von Vodafone kann man schon so drinnen lassen, wenn man z.B. den Schluss zieht, dass die Netzabdeckung momentan hauptsächlich die Ballungszentren betrifft.

Interfaces gibt es nicht. Ich würde es mir auch genau überlegen, die OO Erweiterungen von PL/SQL zu verwenden.

PL/SQL ist eine prozedurale Sprache und das merkt man den OO-Erweiterungen auch an.

Hi,

beide Lösungswege sind nicht sauber, da sie keine Multiuserzugriffe berücksichtigen. Es ist also nicht sichergestellt, dass plötzlich zwei Revisionen auf aktiv stehen.

Um das zu gewährleisten, gehst Du wie folgt vor:

- In der Entität Revision legst Du dein neues Feld active an, und definierst darauf einen CHECK-Constraint, der nur NULL oder 1

erlaubt.

- Auf das Feld, welches die Verbindung zum Dokument herstellt und dem Feld active legst Du einen Unique Index

Damit hast Du sichergestellt, dass nie zwei Dokumente den Wert 1 in dieses Feld bekommen, denn die DB würde das verhindern.

Möchte deine AW jetzt die aktive Revision ändern, so lockt sie zuerst die aktuelle und zukünftige Revision per SELECT ... FOR UPDATE dann setzt sie in der aktiven Revision das Feld active auf NULL und in der neuen Revision auf 1. Dann COMMIT.

Deine Anwendung muss des weiteren damit zurecht kommen, dass der SELECT ... FOR UPDATE fehlschlägt, weil eine andere AW schon darauf zugreift, bzw. dass eine Unique Constraint Violation auftritt (was bei korekter Implementierung eigentlich nicht der Fall sein sollte, aber welche Anwendung ist schon 100%ig fehlerfrei)

Dim

Wieso muss man denn bei einer solchen Datenübertragung gleich eine dicke Middelware auffahren?

Es muss ja nicht gleich MQSeries sein. Es gibt auch schlankere Alternativen.

Was ist an meine Queue besser als an einer Dateiübertragung mit anschließender Überprüfung auf Vollständigkeit?

Eine Queue ist asynchron, der Client kann die Daten abschicken und sich dann sicher sein, dass sie am Server angekommen sind. Aber natürlich sind auch andere Methoden möglich. Auf einen Queue kann ich z.B. auch einen lsitener setzen, kann die Reihenfolge der Abarbeitung einstellen etc. das müsste ich ansonsten noch selbst programmieren.

Um mit einer Queue reden zu können brauche ich auch wieder Client Bibliotheken wo ich mich mit Versionen rum schlagen muss.

Das brauchst Du auch, wenn du die Daten per FTP etc. überträgst.

Dim

Nun zur Frage, ist es sinnvoller eine direkte Verbindung zwischen Client und Datenbank aufzubauen oder einen zwischenschritt in dem nur die reinen Daten in das Firmennetz übertragen werden und nachdem die Daten separat in die Datenbank eingelesen werden. Es geht mir hierbau um die Geschwindigkeit. Der Client soll sich alle 4 Std. mit der Datenbank verbinden und schreiben oder die reinen Daten übertragen.

Das ist ein klassischer Anwendungsfall für eine Middleware sprich Queueing. Deine Anwendung packt die zu übertragenden Informationen, übertragt diese in die Queue und von dort aus werden sie asynchron von einem weiteren Programm abgeholt und abgearbeitet.

Deine dezentrale AW muss nicht warten, bis die Daten wirklich in der DB persistiert sind, sie kann aber davon ausgehen, dass die Pakete übertragen wurden, wenn der Vorgang fehlerfrei abgeschlossen wurde.

Dim

Wofür braucht man einen Webservice um die Daten zu validieren? Man kann mit Hilfe von Constraints, Trigger und Stored Procedures direkt auf der Datenbank dies machen. Ein Webservice ist durchaus ein Angriffspunkt, wenn er nicht entsprechend für die Datenmenge konzipiert ist.

Ohne Worte. :old

Das wird / wurde oft für row-versioning benutzt wie man das bei Datawarehouse und replications braucht (heute würde man da ROWVERSION benutzen, alles andere ist legacy code).

Nur, wenn man in einer perfekten Welt lebt, und davon ausgeht, dass man niemals den Server wechselt, niemals restoren muss, niemals die DB wechselt...

Legacy code...

Dim

Das verstehe ich nicht. Wenn da ein "SQL reverse proxy" auf der einzigen Strecke zur Datenbank eben kein "drop table" (z.B.) durchreicht, wie soll dann Schaden entstehen?

Ein Apache-basierter reverse proxy (für einen Webserver) kann ja einfach sagen dass Anfragen nach "/Nacktbilder_vom_Vorstand.jpg" einfach nach 404.html umgeleitet werden.

Ich bin aber schon längst nicht mehr auf dem Webserver. Der Apache interessiert mich nicht. Ich bin lokal auf dem Datenbankserver, Mitglied der ORADBA Gruppe und kann mich damit ohne Passwort als SYS an die Datenbank anmelden.

Wenn Du also befürchtest, dass jemand den unverschlüsselten Netzwerkverkehr innerhalb eures Netzes ausließt, dann schafft er es auch früher oder später sich das Passwort für einen root oder root ähnlichen Account für den Server seiner Wahl zu besorgen.

Aus diesem Grund muss das eben verhindert werden.

Dim

Genau DAS meinte ich in Beitrag #3 als ich schrieb "ein bösartiger Mensch der den Webserver kapert, _muss_ diese Nutzer aber nicht verwenden, oder?"

Richtig, aber da hilft dir auch keine Filterung vom webserver zur Datenbank, wenn ich mir einfach den sys Account für die DB selbst beschaffe. Da kannst Du DMLs filtern bis Du schwarz wirst

Im übrigend: Wieso besteht Panik vor dem Verändern der Daten? Mindestens genauso schlimm kann auch Datendiebstahl sein. Den läßt Du bei deinen bisherigen Szenarien aber ausser acht.

Flashpixx hat ja schon gute Ansätze genannt das zu verhindern.

Dim

Der mögliche Angreifer könnte ja einen Netzwerksniffer installieren und so an Username und Passwort kommen, egal in welchen Format die auf dem Anwendungsserver hinterlegt sind.

Also. Dein Angreifer hat Zugriff auf Dein Netzwerk und kann dort seelenruhig den Netzwerkverkehr untersuchen? Warum sollte er sich die Mühe machen diese ganzen Umwege zu gehen? Ich hol mir die Accounts von einem Sysadmin für einen der DB-Server und dann reicht ein sqlplus / as sysdba und das wars. Da geb ich mich doch nicht mit normalen Useraccounts ab.

Dim

Woher sollte der die Anmeldungen für entsprechend berechtigte User haben? Ihr habt die ja vermutlich nicht alle im Klartext auf dem server liegen oder?

Spezielle Hardware ist doch nur sinnvoll, wenn es die Problemstellung erfordert.

Z.B. eine Oracle Datenbank, die Java Stored Procedures verwendet. Ist ja durchaus verbreitet. Den PL/SQL Code kann ich bei Bedarf bereits jetzt nativ kompilieren, für Java bin ich noch auf die integrierte JVM angewiesen.

Dim

Warum soll ich dann einen "Umweg" über Java machen, wenn ich eben "perfekten Code für meine Architektur brauche" !?

Für eine echte Java-CPU ist Bytecode der native Code. Oder hab ich das falsch verstanden?

Ich muss eben mir nur vorher Gedanken darum machen und dann meinen Code passend organisieren.

Ja, aber deutlich mehr. 16 Bit, 32 Bit, 64 Bit? Ggf. Endianness, einbinden von Libs (DDL, .so ...), ich brauche für jedes System eine komplette Buildumgebung und wehe ich benutze OS spezifische Erweiterung (z.B. Windows Threads vs. Unix Prozesse).

Wir haben hier RedHat 64Bit in den Versionen 4 und 6, WinXP 32Bit und Win7 64 Bit, auf dem unsere Anwendung läuft. Da bin ich ganz froh drum, dass ich keine Compilerdirektiven mehr sehen muss

Ideal wäre natürlich eine CPU mit dedizierte Java Cores, die für den Bytecode zuständig sind und somit sowohl als auch kann.

Dim

Das ist richtig. Die Frage ist nur, würde irgendetwas den Einsatz eines solchen CPUs rechtfertigen. Meines Erachtens nicht, denn sowohl Java wie auch C/C++ sind bei richtiger Anwendung durchaus auf einem handelsüblichen CPU extrem performant. Performanceprobleme sind meist nicht auf der CPUbasis vorhanden, sondern liegen oft an anderer Stelle.

Davon ausgehend, dass handelsübliche PCs immer mehr von Tablets etc. verdrängt werden, ist nicht mehr die theoretisch verfügbare Rechenleistung das Limit, sondern andere Kriterien wie Akku, Abwärme, Größe und Gewicht.

Eine CPU, die speziell dafür ausgerichtet ist eine spezielle Sprache zu unterstützen, hat da natürlich Vorteile gegenüber eine konventionellen Hardware. Alleine der Overhead für die JVM wäre im Java Bereich schon eine erhebliche Einsparung.

Haben nicht z.B. BluRay Player einen speziellen Chip, in dem die JVM hartverdrahtet ist?

Dim

Das kommt auf das DBMS an und nicht das Tool, mit welchem man in diesem arbeitet.

In diesem Fall doch.

Schemabrowser-> Tabelle auswählen -> Auf der rechten Seite die Lasche Grants auswählen.

Das geht natürlich nur, wenn Du die Berechtigungen hast die entsprechenden Dictionary Views zu lesen.

Dim

Hi,

in diesem Fall würde ich mir eine temporär genutzte Zwischentabelle anlegen, in die jeweils eine Datei geladen wird.

Dann machst Du deinen Abgleich und ermittelst, welche Daten geändert bzw. eingefügt werden sollen und hältst dies über ein extra Kennezichen in besagter Tabelle fest.

Anschließend gibt es zwei SQLs bzw. Verarbeitungsschritte, welche die Daten entsprechend diesem Kennzeichen weitergeben.

Falls Deine DB den MERGE befehl kennt, kannst Du den INSERT/UPDATE Schritt evt. auch zusammenfassen.

Dim

Ob das jetzt inserts, merges, oder lösch alles und inserts sind, ist recht beiläufig imho.

Ja genau. Mal eben alles raus löschen :upps

Dim

Handelt es sich um Komplettlieferungen, die dazu führen, dass die alten, vorhandenen Daten entfernt werden, bekommst Du Aktualisierungen oder musst du anhand einer Komplettlieferung selbst herausfinden, was gelöscht, geändert oder neu hinzugefügt werden muss?

Dim

Sorry, dass ich nochmal drauf rumhacken muss!

Aber aus welcher fachlichen Literatur hast du diese Aussage (oder nur so ein Ding von: Ich mach das so!). Und vor allem mit welcher Begründung.

Wenn du eine Behauptung aufstellst, dann solltest du sie auch begründen!

Ich dachte, dass hätte ich schon in meinem ersten Post gemacht.

Also jetzt ausführlich:

Ausgangslage: Entwickler A verwendet, aus welchem Grund auch immer, fachliche Werte als PK.

Fall 1: Der fachliche Wert wird inhaltlich geändert.

Folgen: Alle abhängigen Werte müssen ebenfalls angepasst werden. Unterstützt die DB ON UPDATE CASCADE wird das zwar automatisch erledigt, benötigt aber auch Zeit (Performance). Bei hunderttausenden oder Millionen Datensätzen könnte da schon mal die ein oder anderen Nachfrage kommen...

Daten, die nicht per FK-Constraint am übergeordneten Satz hängen können, sind jetzt Leichen. Auch in diesem Fall dürfte das früher oder später jemandem auffallen.

Fall 2: Der Datentyp des PK ändert sich.

Sofern Entwickler A noch im Unternehmen tätig ist, hat er jetzt ein echtes Problem, denn ON UPDATE CASCADE hilft jetzt auch nichts mehr. Alle abhängigen Daten müssen per Hand migriert werden.

Fall 3: Der fachliche Wert alleine ist nicht mehr unique, weil sich fachliche Anforderungen/Prozesse geändert haben.

Folge: Uuuuuups -> Mal wieder Migration per Hand

Fall 4: Die Daten sollen mit Daten aus einem anderen System zusammengeführt werden.

Jetzt hat unser Entwickler A ein echtes Problem, denn Fall 1, 2 und 3 können jetzt gemeinsam auftreten. Er hat nun Gelegenheit nachzudenken, was er falsch gemacht hat, während er Migrationsskripte schreibt, die in allen möglichen Tabellen die PKs und FKs anpassen. Hätte er nur mal auf den alten Dim gehört, damals im Forum

Und ja: Ich mach das so, den ansonsten wären die Daten in "meiner" Datenbank (operatives System einer großen Versicherung, 3TB, ca. 2,5Mrd Datensätze, ca. 500 Tabellen) bald nur noch Kraut und Rüben.

Daher nochmal: Nie, nie, nie einen fachlichen Wert als PK verwenden. Immer einen rein technischen benutzen. Es kostet nichts, schadet nichts, der Nutzen ist unbezahlbar.

Immer im Auge behalten: Daten leben länger als man denkt.

Dim

Subjektive Meinung! -> ON UPDATE! Des weiteren steht dort überall Nummer.

Ich kann es nur wiederholen:

Niemals einen fachlichen Wert als PK verwenden. Spalten sind billig, ON UPDATE wird nicht von allen Datenbanken unterstützt, des weiteren können nicht immer alle Abhängigkeiten mit einem FK Constraint abgebildet werden.

Ob dort eine Nummer steht oder nicht ist vollkommen egal.

Dim

Fallen euch noch weitere Dinge ein?

Ja. Verwende niemals einen fachlichen Wert als Schlüssel. Ändert sich der Abteilungsname hast Du ein Problem, gleiches bei Mitarbeiternummer und SO Nummer. Verwende immer rein technische Werte, die von den fachlichen Werten unabhängig sind. Des weiteren macht es das Handling deutlich einfacher, wenn die PK-Spalte in allen Tabellen immer gleich heißt, z.B. ID.

Sollte man das Attribut Adresse in Strasse,Hausnummer,PLZ und Ort aufteilen?

Unbedingt. Ansonsten kommt da nicht mehr zu prüfender Freitext rein, der nicht mehr vernünftig anzeigbar und selektierbar ist.

Der Mitarbeiter hat das Attribut "Abteilung". Es gibt aber schon die Entität "Abteilung". Soll man dann nicht eher die Abteilung von dem Arbeitsplatz ableiten?

Dim