Hibernate und DAO und Reports

[mjustin]

Zitat:

Zitat von BörmtDieBuse (Beitrag 1301180)

Deswegen leg ich auch so den Benutzer fest.

Code:

<property name="hibernate.connection.username">qqrhldb</property>

Auf http://java.dzone.com/articles/hiber...settings-derby (und auf https://karussell.wordpress.com/2009...oracle-and-h2/) ist schön zu sehen dass Benutzer und Schemaname in der Hibernate-Konfiguration für den Oracle thin Treiber gleich sind:

Code:

<property name="hibernate.connection.username">YOURSCHEMA</property>
<property name="hibernate.connection.password">YOURPASSWORD</property>
<property name="hibernate.default_schema">YOURSCHEMA</property>

Dann sollte das hier auch funktionieren:

Code:

<property name="hibernate.connection.username">qqrhldb</property>
<roperty name="hibernate.connection.password">...</property>
<property name="hibernate.default_schema">qqrhldb</property>

Ich tippe, der Verbindungsname 'Umweltlabor' ist nur der frei wählbare Anzeigename in der IDE und hat keinen Einfluss.

[BörmtDieBuse]

Ich hab gerade herausgefunden, das wenn ich mit Hibernate auf die DB zugreif und eine Tabelle hinzufüge.
Dann wird es automatisch auf beiden "DB" Namen hinzugefügt. Also in "Test" und in "Umweltlabor".

Ich darf wahrscheinlich "Test" und Umweltlabor" nicht als DBs betrachten.
Die eigentliche DB ist "qqrhldb" und es gibt keine Möglichkeit zwischen den Verbindungsnamen durchzuwechseln.

[jobo]

Zitat:

Zitat von BörmtDieBuse (Beitrag 1301210)

Ich darf wahrscheinlich "Test" und Umweltlabor" nicht als DBs betrachten.
Die eigentliche DB ist "qqrhldb" und es gibt keine Möglichkeit zwischen den Verbindungsnamen durchzuwechseln.

Also bei Oracle ist es so, dass mehrere User (Schemata) in einer DB liegen können und es auch von Anfang tun, wenn man eine neue erzeugt (per default), also eine Hand voll Standarduser, dann noch die, die man selber anlegt.

Jeder Benutzer/Schema hat eigene Objekte, Datenmodell, Tabellen und Zugriffsrechte. Eine DB hat viele Nutzer, eine Installation kann viele DB haben, ein Rechner kann viele Installationen (also unterschiedliche Oracle Versionen oder Konfigurationen) haben.

Ich hab keine Ahnung von Hibernate, aber
in Deinem Fall ist laut Bild http://www.delphipraxis.net/attachme...rts-schema.png
der Nutzer qqrhldb, der Verbindungsname Umweltlabor oder Test ist eine Hibernatesache, die beliebig vergeben werden kann und nichts mit einer Oracle DB zu tun hat. Kann heißen wie es will und alles auf verschiedene oder die gleiche DB gehen und
auf den gleichen Nutzer!
So sieht es zumindest bei Dir (soweit man das auf dem Bild erkennen kann) so aus und das ergibt scheinbar den Effekt, dass es auf "beiden" Systemen "eingespielt" wird.

[BörmtDieBuse]

Zitat:

Zitat von jobo (Beitrag 1301219)

Also bei Oracle ist es so, dass mehrere User (Schemata) in einer DB liegen können und es auch von Anfang tun, wenn man eine neue erzeugt (per default), also eine Hand voll Standarduser, dann noch die, die man selber anlegt.

Jeder Benutzer/Schema hat eigene Objekte, Datenmodell, Tabellen und Zugriffsrechte. Eine DB hat viele Nutzer, eine Installation kann viele DB haben, ein Rechner kann viele Installationen (also unterschiedliche Oracle Versionen oder Konfigurationen) haben.

Ich hab keine Ahnung von Hibernate, aber
in Deinem Fall ist laut Bild http://www.delphipraxis.net/attachme...rts-schema.png
der Nutzer qqrhldb, der Verbindungsname Umweltlabor oder Test ist eine Hibernatesache, die beliebig vergeben werden kann und nichts mit einer Oracle DB zu tun hat. Kann heißen wie es will und alles auf verschiedene oder die gleiche DB gehen und
auf den gleichen Nutzer!
So sieht es zumindest bei Dir (soweit man das auf dem Bild erkennen kann) so aus und das ergibt scheinbar den Effekt, dass es auf "beiden" Systemen "eingespielt" wird.

Ok, ich begnüg mich jetzt einfach damit, das ich nicht zwischen den Verbindungsnamen wechseln kann.
Ich habe Test und Umweltlabor selber angelegt um meine Programmierung bei "Test" testen zu können bevor ich final auf Umweltlabor zugreif, deswegen wollte ich seperat zugreifen können.


Ich hätte aber noch eine andere Frage wegen Redundanzen.
Ich habe mehrere Tabellen mit einer Spalte Barcodes. Die Spalte Barcodes hat bei jeder Tabelle ein verändertes Format.
Natürlich hab ich aber bei jeder Tabelle auch eine Spalte ID. So ein Barcode setzt sich aber zusammen aus einem Präfix und der ID, z.B. PV_1.
Präfix = PV, ID = 1

Da ID und Barcode in ein und der selben Tabelle sind, wird ja die Redundanz verletzt. Gibt Oracle bei sowas eine Fehlermeldung aus?
Ich würde ungern die Spalte Barcode wegnehmen, da ich den kompletten Barcode in meiner Datenbank haben möchte und die ID wegzulassen kommt mir ihrgenwie falsch vor.
Sorry wenn das eine dumme Frage sein sollte, aber ich habe keine Erfahrung in Datenbanken.
Schonmal Danke im Vorraus.

[jobo]

Zitat:

Zitat von BörmtDieBuse (Beitrag 1301321)

Ich hätte aber noch eine andere Frage wegen Redundanzen.
Ich habe mehrere Tabellen mit einer Spalte Barcodes. Die Spalte Barcodes hat bei jeder Tabelle ein verändertes Format.
Natürlich hab ich aber bei jeder Tabelle auch eine Spalte ID. So ein Barcode setzt sich aber zusammen aus einem Präfix und der ID, z.B. PV_1.
Präfix = PV, ID = 1

Da ID und Barcode in ein und der selben Tabelle sind, wird ja die Redundanz verletzt. Gibt Oracle bei sowas eine Fehlermeldung aus?
Ich würde ungern die Spalte Barcode wegnehmen, da ich den kompletten Barcode in meiner Datenbank haben möchte und die ID wegzulassen kommt mir ihrgenwie falsch vor.

Ich glaub, ich hab die Frage nicht verstanden.
Wenn 2 Spalten gemeinsam ein eindeutiger Schlüssel sein sollen, kannst Du einen unique constraint definieren, am besten mit dem entsprechenden unique index.
Welche Redundanz wird wann verletzt? Meinst Du vielleicht die Eindeutigkeit wird verletzt?
Möchtest Du beide Spalten zu einer zusammenfassen?

[BörmtDieBuse]

Zitat:

Zitat von jobo (Beitrag 1301332)

Ich glaub, ich hab die Frage nicht verstanden.
Wenn 2 Spalten gemeinsam ein eindeutiger Schlüssel sein sollen, kannst Du einen unique constraint definieren, am besten mit dem entsprechenden unique index.
Welche Redundanz wird wann verletzt? Meinst Du vielleicht die Eindeutigkeit wird verletzt?
Möchtest Du beide Spalten zu einer zusammenfassen?

Mir hat ein Informatiker mal gesagt, das man keine Primärschlüssel machen soll, die aus 2 Spalten bestehen.
Ja ich denke es wird die Eindeutigkeit verletzt, da die ID und der Barcode gleich sind, außer das der Barcode noch diese Präfix "PV_" davor hat. PV_1
Ich möchte die Spalte Barcode behalten, damit ich den Barcode komplett in meiner Datenbank hab. Dann muss der Datentyp aber String sein. Der Barcode lässt sich aber nicht autoamtisch inkrementieren, weil er halt ein String ist. Deswegen lasse ich die Spalte ID drin, die wird dann inkrementiert.

[jobo]

Zitat:

Zitat von BörmtDieBuse (Beitrag 1301335)

Mir hat ein Informatiker mal gesagt, das man keine Primärschlüssel machen soll, die aus 2 Spalten bestehen.
Ja ich denke es wird die Eindeutigkeit verletzt, da die ID und der Barcode gleich sind, außer das der Barcode noch diese Präfix "PV_" davor hat. PV_1
Ich möchte die Spalte Barcode behalten, damit ich den Barcode komplett in meiner Datenbank hab. Dann muss der Datentyp aber String sein. Der Barcode lässt sich aber nicht autoamtisch inkrementieren, weil er halt ein String ist. Deswegen lasse ich die Spalte ID drin, die wird dann inkrementiert.

Mehrspaltige Primärschlüssel sind glaub ich höchstens ein Problem der Handhabung, also in dem Sinne, dass dort mehr Sorgfalt geboten ist, sind aber nicht verboten.
Ist der Präfix konstant, also immer PV?
Du kannst eine virtuelle Barcodespalte bauen, die ID und konstanten Präfix zusammenfasst oder ID und variablen Präfix. Das würde man mit einem View machen.
Redundanz an sich ist auch kein Nogo, man muss nur (tot)sicherstellen, dass alles synchron bleibt. Da ist dann die Frage, wieviel Aufwand man dafür treibt und warum. Macht man z.B: aus Performancegründen.
Ich würde aber immer erstmal den Weg gehen, redundanzfrei zu bleiben und die Darstellung zu ändern (also View, virtuelle, zusammengesetzte Spalte anlegen). Auch das muss aber durchdacht sein, damit immer der konsistente Zugriff auf den View und die Editierbarkeit-sofern nötig- gegeben ist.