dr.dimitri

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

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

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

Es muss ja nicht gleich MQSeries sein. Es gibt auch schlankere Alternativen. 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. Das brauchst Du auch, wenn du die Daten per FTP etc. überträgst. Dim

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

Ohne Worte. :old

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

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

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

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?

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

Für eine echte Java-CPU ist Bytecode der native Code. Oder hab ich das falsch verstanden? 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

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

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

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

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

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

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. Unbedingt. Ansonsten kommt da nicht mehr zu prüfender Freitext rein, der nicht mehr vernünftig anzeigbar und selektierbar ist. Was soll denn in dieses Feld rein? Eine Zimmernummer? Freitext? Dim

Grundsätzlich ist der Ansatz richtig, wenn die DB '' wirklich als Leerstring - also einen String mit der Länge 0 Byte ansieht. Für Oracle z.B. ist ein '' aber NULL. Damit würde im SQL stehen NULL = NULL Da NULL immer ein undefinierter Wert ist, ist der Vergleich immer false - es wird also kein einziger Wert zurückgeliefert :cool: Kleines Beispiel: SQL> select count(*) from all_objects where ''=''; COUNT(*) ---------- 0 SQL> select count(*) from all_objects where 1=1; COUNT(*) ---------- 55677 SQL> select count(*) from all_objects where NULL IS NULL; COUNT(*) ---------- 55677 SQL> Dim

Die OR Bedingung ist nicht richtig. Je nach DB wird nach einem Leerstring gesucht oder nach NULL. Da NULL nie gleich einem bestimmten Wert ist, hilft das hier nicht weiter. Die einfachste Möglichkeit ist, die WHERE Bedingung wegzulassen. Sprich bei einem fehlenden Parameter ein zweites, passendes SQL aufzurufen. Dim

Hi, Wissen, sofern es korrekt ist, schadet nie. Insofern würde ich dir empfehlen, installier dir auf deinem PC die Oracle 11 XE Datenbank Oracle Database Express Edition 11g Release 2 bezüglich ADF findest Du hier einen guten Einstieg: Oracle Application Development Framework - Oracle ADF Bezüglich der Oracledatenbank selbst sind die Bücher von Tom Kyte sehr lesenswert. Da zu sitzen und auf die Schulung zu warten ist eine Möglichkeit, selbst Wissen anzusammeln (besonders wenn es sich um so ein Interessantes Thema handelt) ist besser. Dim