Connect failed: Connection timed out

[GastForen Programmierung/Entwicklung PHP und MySQL Einfache Fragen: Zentrale User-Datenbank

  • Suche
  • Hilfe
  • Lesezeichen
  • Benutzerliste
Themen
Beiträge
Moderatoren
Letzter Beitrag

Einfache Fragen: Zentrale User-Datenbank

Felix
Beiträge gesamt: 16

9. Aug 2004, 15:26
Beitrag # 1 von 9
Bewertung:
(2976 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
Kann mir jemand vielleicht folgende grundlegende Fragen zu mySQL beantworten:

Ich habe einen Webserver (dedicated) auf dem mySQL und mehrere verschiedene Datenbanken zu verschiedenen Zwecken laufen (eine enthält die Daten aus unserem Webshop, eine enthält die Support-Daten, etc.).

Nun möchte ich gerne eine zentrale User-Datenbank aufsetzen, der einfach Daten hinzugefügt werden können, z. B. durch ein Web-Formular (wenn jemand bspw. den Newsletter abonnieren möchte), zu der aber auch regelmässig und automatisch bestimmte Daten von den anderen Datenbanken "dazukopiert", bzw. synchronisiert werden können.

Die anderen Datenbanken wurden automatisch vom Shop, bzw. dem Support-System (von unterschiedlichen Herstellern) generiert, das Ziel ist es, eine Datenbank zu haben die sämtliche Informationen zu jedem Benutzer enthält (Name, Email, Newsletter-Abo ja/nein, registriertes Produkt ja/nein, hatte einen Support-Fall ja/nein, usw., usw.).
Dabei soll es natürlich möglichst vermieden werden, dass jemand mehrfach registriert wird (z. B. einmal beim Kauf eines Produktes im Shop und dann ein zweites mal bei einer Support-Anfrage.

Ist das grundsätzlich möglich (vor allem ein forlaufendes, bzw. regelmässiges "spiegeln" in meine eigene DB und das eigentliche Zusammenführen der Daten; die Email-Addresse kann ja z. B. in der einen DB als "email" gespeichert sein und in der anderen als "e-mail"...)?
Wenn ja, ist es sehr schwierig? Kann es, mit ein wenig Mühe von einem Nicht-mySQL-Profi wie mir gemacht werden, oder müsste ich auf jeden Fall jemanden für so einen Job finden und bezahlen, wenn ich selbst nicht erfahren bin mit mySQL?
X

Einfache Fragen: Zentrale User-Datenbank

oesi50
  
Beiträge gesamt: 2315

9. Aug 2004, 17:28
Beitrag # 2 von 9
Beitrag ID: #101865
Bewertung:
(2976 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
Sollen die Daten wechselseitig gespiegelt werden?

Fred registriert sich in Anwendung A
Paul registriert sich in Anwendung B

A-Fred --> B
B-Paul --> A

A-Fred,Paul
B-Fred,Paul

Oder gibt es eine zentrale Anmeldung, die in die einzelnen Anwendungen gespiegel werden soll?


Grüße Oesi
Ich weiß, dass ich nichts weiß... (Sokrates)


als Antwort auf: [#101826]
(Dieser Beitrag wurde von oesi50 am 9. Aug 2004, 17:28 geändert)

Einfache Fragen: Zentrale User-Datenbank

Felix
Beiträge gesamt: 16

9. Aug 2004, 17:46
Beitrag # 3 von 9
Beitrag ID: #101871
Bewertung:
(2976 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
Nennen wir die Shop-Datenbank A, die Support-Datenbank B und die zentrale User-Datebank C.
Es müssen weder Daten direkt zwischen A und B ausgetauscht werden, noch müssen Daten von C nach A oder B gespiegelt werden.

Es sollen lediglich alle Benutzer-Daten aus A und B nach C gespiegelt werden. C soll aber ausserdem auch unabhängig von A und B editierbar sein.

Es geht also darum, eine zentrale User-Datenbank zu haben, die einerseits forlaufend von Daten aus den beiden anderen Datenbanken gespeist wird, der andererseits aber auch Daten über, sagen wir ein einfaches PHP-Formular, hinzugefügt werden können.

So sollte am Schluss ein Pool an Daten entstehen der sämtliche Personen enthält, mit denen die Website je "zu tun" hatte.


als Antwort auf: [#101826]

Einfache Fragen: Zentrale User-Datenbank

Miro Dietiker
Beiträge gesamt: 699

9. Aug 2004, 17:51
Beitrag # 4 von 9
Beitrag ID: #101874
Bewertung:
(2976 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
Ich denke ganz grundlegend:
Synchronisationen sind meist mit mehr verbunden, als man sich das
zu Beginn vorstellt. Oesis Frage ist eine erste die dann meist immer
längere Diskussionen mit sich zieht.

Grundlegend: Mit jedem weiteren Zusatzfeld und Unterscheidung der
einzelner Tabellen wird es schwieriger. Um eine Synchronisation
zu machen, muss man immer das gesamte System im Griff haben und
genau wissen wer wie was wo vorgegeben hat. Ursprünglich als
"eindeutige" Felder (bsp. Mailadresse) sind dann plötzlich nicht
mehr so eindeutig und man kann zwischen den einzelnen Tabellen
nichtmehr saubere Zuordnungen machen.
Solche Prozesse enden dann häufig in einem Chaos und man hätte es
besser komplett getrennt gelassen.

Meiner Meinung nach heisst Synchronisation meist:
- Alle Quellen im Detail analysieren und auf
Synchronisierbarkeit prüfen
- Zentrale ausgeklügelte Tabelle mit Statusspalten und
Hintergrundinformationsspalten definieren
- Einzelne Synch-scripts programmieren, welche recht viele
Umsetzungen machen müssen
- Schliesslich müssen aber häufig die ursprünglichen Module
häufig erweitert werden, damit der künftige Anschluss an
das zentrale System gewährt ist!
Häufig muss man die "Alten Daten" sprich initialsynchronisation
und die späteren dann anders angehen

Mit allen Fällen habe ich täglich zutun: Wir synchronisieren
grosse Produktdatenbanken zwischen 5 Datenquellen und optimieren
punkto Preis (auch versteckte zusatzkosten). Was zunächst als
einfaches zusammentragen aller Daten definiert war nach dem
Motto "In der resultierenden soll alles drin sein was in den
einzelnen definiert wird" resultierte schliesslich in einem
Regelnkrieg um die übereinstimmenden zu finden..

Vielleicht aber gestaltet es sich auch ganz einfach!

GrEeZ: Miro Dietiker


als Antwort auf: [#101826]

Einfache Fragen: Zentrale User-Datenbank

Miro Dietiker
Beiträge gesamt: 699

9. Aug 2004, 17:55
Beitrag # 5 von 9
Beitrag ID: #101878
Bewertung:
(2976 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
Aaaha... Dann ist es schon etwas anders:

Möchtest du denn einfach alles rübersynchronisieren und
allenfalls redundante datensätze zwischen A und B zweimal
in C haben oder hier eine Zusammengehörigkeit feststellen
und nur einmal resultierend haben?

einfache Lösung wäre:
Extraspalte in C, wo drinsteht, woher das Element herkommt
und oder zusätzlich noch Spalten woher du dir den alten
Primärschlüssel aus Tabelle A und B merkst!

TABLE C hat Spalten:
- id_c int(10) primary auto_increment
- source ENUM('A','B','C')
- id_a int(10)
- id_b int(10)
- Benutzerspalten

Somit hat man immer einen Bezug zum Original!

Das Script würde sich recht einfach gestalten...

GrEeZ: Miro Dietiker


als Antwort auf: [#101826]

Einfache Fragen: Zentrale User-Datenbank

oesi50
  
Beiträge gesamt: 2315

9. Aug 2004, 18:01
Beitrag # 6 von 9
Beitrag ID: #101882
Bewertung:
(2976 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
Ja, das sehe ich auch so, eine gegenseitige Replikation führt, besonders wenn die einzelnen Anwendung noch Zusatzinformationen benutzen, fast immer ins Chaos.
Hier in diesem Fall wäre es wohl besser, Datenbank C nur als eine Art Logdatei aufzufassen, in der alle Nutzer zusammengefasst werden, ohne dass mit den Daten eine Authentifizierung dürchgeführt wird. Sozusagen 'write only'.


Grüße Oesi
Ich weiß, dass ich nichts weiß... (Sokrates)


als Antwort auf: [#101826]

Einfache Fragen: Zentrale User-Datenbank

Felix
Beiträge gesamt: 16

9. Aug 2004, 18:19
Beitrag # 7 von 9
Beitrag ID: #101886
Bewertung:
(2976 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
Exakt das ist die Idee, C soll nur Daten aus den anderen zusammen aufführen, wobei idealerweise natürlich doppelte Eintragungen vermieden werden sollten. Sprich, wenn z. B. die Email-Adresse und der Vorname bei zwei Eintragungen identisch sind, könnte man das doch theoretisch als die selbe Person identifizieren und die Daten mergen (nach dem Prinzip: wenn Feld "Nachname" in C bisher leer, übernehme "Nachname" aus neuen Daten aus A; wenn Feld "Nachname" nicht leer, übernehme "Nachname" aus Daten aus A, sofern Daten aus A neuer sind als Daten aus C).

Somit muss sich ein Besucher zwar bei verschiedenen Anwendungen einzeln anmelden, allerdings existiert er in unserer "Datenbank der existierenden Personen" immer nur ein einziges mal.

Liesse sich sowas mit einer Datenbank mit den entsprechenden Spalten und ein paar simplen Script-Zeilen realisieren, oder brauche ich dafür einen Spezialisten? Meine MySQL-Kenntnisse beschränken sich bisher auf die absoluten Basics, sprich, ich hab eine Vorstellung davon wie das ganze funktioniert und kann gerade mal via phpMyAdmin Tabellen generieren und dergleichen. Aber sofern sich die Aufgabe mit ein wenig Web-Knowledge relativ schnell lösen liesse, sollte ich das sicher hinbekommen, vorausgesetzt ich finde die richtigen Quellen...


als Antwort auf: [#101826]

Einfache Fragen: Zentrale User-Datenbank

Felix
Beiträge gesamt: 16

11. Aug 2004, 15:34
Beitrag # 8 von 9
Beitrag ID: #102308
Bewertung:
(2976 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
Hat jemand zu dem Thema noch Infos? Denkt ihr das geht, mit einem guten MySQL- / Perl- / PHP-Buch, auch wenn man so unerfahren ist wie ich, innerhalb von ein paar Tagen?

Oder sollte ich mich besser nach einem Spezialisten umsehen? Wenn ja, wo findet man den? In dem Job-Forum hier gibt's, glaube ich, nicht immer gerade sehr viel Response, oder?
Wonach müsste ich denn Ausschau halten? Nach jemandem der sich mit MySQL und Perl auskennt?

Wie gesagt, es geht eigentlich ja nur darum, die Datenbank C zu erstellen und Scripts (Perl...??) zu schreiben, die sich dann regelmässig bestimmte Daten aus den Datenbanken A und B holen und in bestimmter Form, bzw. unter bestimmten Bedingungen in die Datenbank C einfügen...

Bitte um Antwort, habe bestimmte Deadlines einzuhalten...

Danke!


als Antwort auf: [#101826]
(Dieser Beitrag wurde von Felix am 11. Aug 2004, 15:34 geändert)

Einfache Fragen: Zentrale User-Datenbank

Miro Dietiker
Beiträge gesamt: 699

12. Aug 2004, 12:27
Beitrag # 9 von 9
Beitrag ID: #102525
Bewertung:
(2976 mal gelesen)
URL zum Beitrag
Beitrag als Lesezeichen
Hi Felix!

Die Arbeit (wenn jemand weiss was er tut und du klar formulieren
kannst, was zusammengelegt werden soll) wird mit 1/2 Tag machbar
sein! Allenfalls muss man sich da 1 Tag kurzschliessen.

Das Jobforum hier ist vielbenutzt, die Antworten erfolgen meist
direkt an den Kunden - und nicht als Forendiskussion.

Es steht noch die Frage, in welchen Abständen dein Prozess/Abgleich
stattfinden soll! Ich würde hier ein script schreiben, welches
täglich automatisch von cron aufgerufen wird.. Vorausgesetzt du
kannst "cronjobs" ausführen auf deinem server..
Die Mittel die man hierzu benötigt sind genauso trivial wie du's
aus der Welt der Webausgabe kennst..
- SQL (SELECT)
- Schleifen
- SQL (INSERT)
Fertig!

Die Experten die du suchst, haben wohl eben mit dir gesprochen ;-)
Zumindest ich lebe von Datenbankanalysen und Umsetzungen...
Wenn du das effizient lösen willst, kannst du mich gerne
beauftragen - ich schreib dir den code dazu schon!

GrEeZ: Miro Dietiker


als Antwort auf: [#101826]
X