Realisierung einer DB in Combi mit Java

Javandroid

Mitglied
Hallo zusammen,

das mit den Datenbanke ist doch nicht so einfach wie so manch einer denkt 🙂.

Ich bitte euch um Rat, bin neu auf diesem Gebiet.

Mein Vorhaben:

Ich möchte mit Java ein Programm schreiben aus dem Ich - zu jedem Kunde- folgende Daten bzw. 3 MySQL DB's erhalten werde:

DATABASE Customers: (soll letztlich alle Kunden beinhalten)

MySQL DB 1:
LoginTable:
ID, LoginName, Passwort (Für den Login)
.....

MySQL DB 2:
KundeTable:
ID, KundenNummer, AnmeldeDatum, Anschrift
.....
MySQL DB 3:
WarenkorbTable:
ID, Produkt 1, Produkt 2
.....

Ein Kunde und nur der Kunde kann die Daten editieren, 2 weitere Personen können die Daten einsehen, jedoch nur lesend.

Meine Fragen:

Ist so etwas möglich und ein guter Weg die DB's in eine "globale" DB zuschreiben?

Muss jeder Kunde in allen drei DB's die gleiche ID bekommen, damit Ich mir später alle Infos zum jeweiligen Kunden zusammen fügen kann?

Wie kann man es realisieren, dass bei Änderung einer Eingabe bspw. der Anschrift alle Auslesenden über die Änderung informiert werden. Wie wird so etwas angetriggert, setzt man ein Flag?

Wie kann Ich in einer Datenbank oder in einem Java-Code festlegen wer die Daten von welchem Kunden auslesen darf (es sind ja alle Kunden in einer DB)?

Ich hoffe man kann meine Fragen verstehen und hoffe jemand kann mir helfen bzw. Tipps zum Vorgehen geben.

Vielen Dank vorab.
 
Ist so etwas möglich und ein guter Weg die DB's in eine "globale" DB zuschreiben?
Grundsätzlich verstehe ich nicht, warum du drei Datenbanken benötigst?
Was du beschreibst kann in EINER Datenbank abgebildet werden, in der sich mindestens die drei Tabellen LoginTable, KundeTable und WarenkorbTable befinden. Also besteht eine Datenbank-Instanz aus beliebig vielen Tabellen. Jede Tabelle hat ihre eigene Struktur und legt fest welche Art von Daten in ihr gespeichert werden können.

Muss jeder Kunde in allen drei DB's die gleiche ID bekommen, damit Ich mir später alle Infos zum jeweiligen Kunden zusammen fügen kann?
Da du "nur" eine DB hast, stellt sich diese Frage nicht.

Wie kann man es realisieren, dass bei Änderung einer Eingabe bspw. der Anschrift alle Auslesenden über die Änderung informiert werden. Wie wird so etwas angetriggert, setzt man ein Flag?
Häufig wird eine DB in einer sogenannten Client/Server-Umgebung eingesetzt. Der Server-Teil enthält dabei die "Business"-Logik, verbindet sich mit der DB und pflegt/manipuliert die Daten in der DB. Der Client-Teil repräsentiert die View auf die Daten. Hier werden Aktionen angestoßen (beispielsweise neuer Kunde anlegen), die dann in der Business-Logik ausgeführt und in die DB geschrieben werden. Somit macht es Sinn, Änderungen in der DB vom Client abfragen zu lassen, statt die DB alle anderen Teile (Server und Clients) zu informieren.

Wie kann Ich in einer Datenbank oder in einem Java-Code festlegen wer die Daten von welchem Kunden auslesen darf (es sind ja alle Kunden in einer DB)?
Dies ist Aufgabe der DB. Mit der hier geschilderten Client/Server-Architektur nennt man die Datenschicht normalerweise das Backend. Und hier kann sehr feingranular festgelegt werden, wer, was in der DB machen darf. Das SQl-Kommando, mit dies möglich ist, heisst GRANT und hier findest du mehr Infos dazu.
 
Grundsätzlich verstehe ich nicht, warum du drei Datenbanken benötigst?
Was du beschreibst kann in EINER Datenbank abgebildet werden, in der sich mindestens die drei Tabellen LoginTable, KundeTable und WarenkorbTable befinden. Also besteht eine Datenbank-Instanz aus beliebig vielen Tabellen. Jede Tabelle hat ihre eigene Struktur und legt fest welche Art von Daten in ihr gespeichert werden können.


Da du "nur" eine DB hast, stellt sich diese Frage nicht.

Vielen Dank für die Antwort. Obenstehend wollte Ich durch "...." andeuten, dass dort die Daten von anderen Kunden eingefügt werden. Meine Idee ist also eine "globale" DataBase mit drei weiteren DB's in der die Daten zu jedem Kunden gespeichtert werden.



Wie kann man es realisieren, dass bei Änderung einer Eingabe bspw. der Anschrift alle Auslesenden über die Änderung informiert werden. Wie wird so etwas angetriggert, setzt man ein Flag?


Häufig wird eine DB in einer sogenannten Client/Server-Umgebung eingesetzt. Der Server-Teil enthält dabei die "Business"-Logik, verbindet sich mit der DB und pflegt/manipuliert die Daten in der DB. Der Client-Teil repräsentiert die View auf die Daten. Hier werden Aktionen angestoßen (beispielsweise neuer Kunde anlegen), die dann in der Business-Logik ausgeführt und in die DB geschrieben werden. Somit macht es Sinn, Änderungen in der DB vom Client abfragen zu lassen, statt die DB alle anderen Teile (Server und Clients) zu informieren.

Server ist also der Kunde? Dieser lädt die Eingaben in die DB und die Clients fragen diese Daten ab, ist das so richtig?
Der Client bekommt Änderungen also nur durch zyklische Abfrage mit? Kann man eine Änderung nicht direkt weiterleiten?

Wie kann Ich in einer Datenbank oder in einem Java-Code festlegen wer die Daten von welchem Kunden auslesen darf (es sind ja alle Kunden in einer DB)?


Dies ist Aufgabe der DB. Mit der hier geschilderten Client/Server-Architektur nennt man die Datenschicht normalerweise das Backend. Und hier kann sehr feingranular festgelegt werden, wer, was in der DB machen darf. Das SQl-Kommando, mit dies möglich ist, heisst GRANT und hier findest du mehr Infos dazu.

Kann Ich diese Einstellungen zur Laufzeit einstellen oder muss Ich dies zwingend vorab?

Vielen Dank für Ihre Hilfe
 
Ja, aber du KANNST ja eine Tabelle für jeden Kunden machen, wenn dir danach ist.

Der Server hat nichts bzw. wenig mit der Datenbank zu tun.

Wie ich sagte, ist hier die Business-Logik gemeint. Nehmen wir an Kunde X möchte einen neuen Eintrag in die Warenkorbtabelle machen. Also schickt er die notwendigen Daten Produkt 1,Preis, Anzahl,... von seinem Client-Arbeitsplatz zum Server, ruft dort die Funktion insertNewWarenkorb(..) auf und diese Business-Funktion fügt den Eintrag in die DB ein. Wenn alles klappte, bekommt der Client zurück das der neue Warenkorb angelegt wurde. Vielleicht gibt er auch eine Liste aller bekannten Warenkörbe dieses Kunden aus.

Das ein Client automatisch informiert wird, wenn sich die DB geändert hat, ist sehr DB-spezifisch und könnte, je nach DB, durch Trigger gelöst werden. Das führt aber zu weiteren Problemen, da ja nicht gewährleistet ist, das ein Client zu jedem Zeitpunkt eine Änderung der DB "verkraften" kann. Nehmen wir als Beispiel das ein Client gerade dabei ist, die Daten für Warenkorb anzupassen, während ein anderer Client gerade genau diesen Warenkorb löscht.

Das GRANTEN/REVOKEN von Rechten KANN man auch dynamisch, also zur Laufzeit machen. Häufiger ist dies aber recht aufwändig und man macht dieses oft noch nicht einmal mit Java-Mitteln, sondern verwendet Tools der Datenbank um solche Administrations-Sachen zu pflegen.
 
Du meinst also eine DB welche alle drei Tabellen inkludiert für jeden Kunden?

In Business-Logik werde Ich mich einlesen. Gibt es hierzu gute Tutorials für Beginner?

Würde dies dann auch später evtl gerne in einer App umsetzen in der Ich dann aus dem Büro via App Informationen (die oben genannten) an einen Mitarbeiter im Lager senden kann.

Würde dann die Daten in eine Oberfläche der App eintragen -> in die DB laden, und der Mitarbeiter im Lager kann diese dann "auf der anderen Seite" der App automatisch auslesen bzw. wird automatisch und immer unmittelbar angezeigt. Wobei auch hier dann die Frage bleibt wie die sofortige Übermittlung/Anzeige ins Lager realisiert werden kann.
 
Du meinst also eine DB welche alle drei Tabellen inkludiert für jeden Kunden?

In Business-Logik werde Ich mich einlesen. Gibt es hierzu gute Tutorials für Beginner?

Würde dies dann auch später evtl gerne in einer App umsetzen in der Ich dann aus dem Büro via App Informationen (die oben genannten) an einen Mitarbeiter im Lager senden kann.

Würde dann die Daten in eine Oberfläche der App eintragen -> in die DB laden, und der Mitarbeiter im Lager kann diese dann "auf der anderen Seite" der App automatisch auslesen bzw. wird automatisch und immer unmittelbar angezeigt. Wobei auch hier dann die Frage bleibt wie die sofortige Übermittlung/Anzeige ins Lager realisiert werden kann.

Ja, eine Datenbank für deine Applikation, die drei Tabellen hat. Alles andere ist sinnlos.

Wenn du etwas zu diesem Bereich erfahren möchtest, ist 3-Tier-Architektur ein guter Ausgangspunkt. Da beginnt das Ganze. Allgemein ist BI jedoch ein Konzeptwort, das keine "konkreten Codebeispiele" oder so bereithält. Es geht hier nur um die Teile, die eben Geschäftslogik verrichten und nichts mit Datenspeicherung oder Darstellung zu tun haben.

Eine automatische Aktualisierung kannst du auf verschiedene Wege erreichen.
- auslesen im Intervall
- Information über einen Socket, UDP-Packet an Lager ("Hey, aktualisier dich...")
- RMI, falls es umfangreicher werden soll
- ...
Das hängt auch von deiner Netzwerktopologie ab.
 
Zuletzt bearbeitet:
Das heißt also, dass Ich mittels dieser 3-Tier-Architektur in eine UI (bspw. via App) die Daten eingeben kann, diese werden dann "in die Hände" der Business-Logik übergeben.
Die Business-Logik organisiert hierbei wo die Daten landen und wer, auf welche Datenbereiche in der Datenbank zugreifen darf?
Auch wenn in bei 3-Tier-Architektur die Teilaufgaben "Presentation der Daten", "Business-Logik" und "Datenhaltung/Datenspeicherung" getrennt betrachtet werden, werden all diese Aufgaben über bspw. Java implementiert. Die Speicherung der Daten in die DB wird natürlich noch mit Hilfe von PHP und SQL realisiert. Ist das so richtig?

Die Daten sollen über UI des Kunden editierbar sein, aber nur dort. der oder die Anderen sollen es nur lesen können.
Ist das hierfür die beste Lösung?
 
Zuletzt bearbeitet:
Ja, du hast das schon sehr gut verstanden. Idealerweise erstellst du einen zentralen Server, der die Business Logik beinhaltet (mittels RMI ist das ziemlich einfach). Dieser Server ist der einzige, der Zugriff auf die Datenbank hat (die nicht auf dem gleichen Gerät sein muss).

Dann hast du ein Front-End, dass am Schluss nur Informationen sammelt, an den BI-Server sendet oder Informationen vom BI-Server abfragt und geeignet darstellt. Deine gewünschte Authentifizierung kannst du auch mittels eines Logins gewährleisten.

Damit hast du schon eine sehr flexible und erweiterbare Struktur.
 
Ok, super, werde mir auch RMI mal anschauen.
Ist dieser Ansatz später dann auch "einfach" erweiterbar, so dass Ich nach einer Authentifizierung via Login eine Gruppe mit weiteren Usern meiner Application erstellen kann und diese dann eine Gruppe bilden.
In der Gruppe kann man dann für die bevorstehenden Spielergebnisse seinen eigenen Ergebnisstipp eingeben, welche auch bei allen anderen Gruppenteilnehmern angezeigt wird. Somit kann jeder User dann die Spielergebnistipps aller Gruppenuser einsehen. Wie könnte eine solche Gruppierung angegangen werden?

Wird der Server nur in php programmiert?
 
Zuletzt bearbeitet:
Stimmt,hierbei geht es auch um eine andere Sache, habe mich im Tab geirrt. Aber die gleiche Frage stellt sich mit für die Lager-App.

Ist dieser Ansatz später dann auch "einfach" erweiterbar, so dass Ich nach einer Authentifizierung via Login eine Gruppe mit weiteren Usern meiner Application erstellen kann und diese dann eine Gruppe bilden.
Wie könnte eine solche Gruppierung von Seiten der Datenbank angegangen werden?

Wird der Server nur in php programmiert?
 
Insofern du RMI verwendest bist du fixiert auf Java. Falls du auch PHP möchtest, empfehle ich eine REST-API, das wird in Java jedoch etwas komplizierter.

Insofern du Rechte umsetzen möchtest empfehle ich beispielsweise eine ACL. Dazu findet man sehr viele Tutoriale bei Google & co.

Und ja, insofern du das richtig unsetzt, ist das ziemlich einfach zum Umsetzen.
 
Zuletzt bearbeitet:
Werde mich mal mit ACL auseinandersetzten und Tutorials durcharbeiten.
Ist eine Gruppierung mehrerer User mit ACL möglich?
Wird ACL via Java implementiert?
viele Dank für den Support.
 
Ja, du kannst mittels ACL Gruppen erstellen.

ACL ist ein Konzept, wie du das implementierst (oder ob du ein bestehendes Framework nimmst) bleibt alleine dir überlassen.
 

Zurück
Oben