zentrale Datenbank für unterschiedliche Orte?

Wie würdet Ihr folgendes am besten lösen?

Benötige Datenbank, auf die intern von 2 örtlich getrennten Büros
zugegriffen wird
und auf die extern in eingeschränktem Umfang zugegriffen wird.

Prinzipiell ist dazu zu sagen, dass ich es für unvorteilhaft halte,
alles über einen Server, bzw. eine Datenbank (in diesem Fall, diese
beim Webhosting-Provider) laufen zu lassen, da wir dann immer von einer
guten Online-Verbindung (was in der Vergangenheit nicht immer der Fall
war) abhängig wären.

Ich denke das Ideale wäre "örtlich installierte Datenbanken" (oder
wie nennt man das?),
die sich dann mit den anderen synchronisieren, oder?
Die Frage wäre in diesem Fall, welche Software die Synchronisation
vornehmen würde?
Oder gehe ich das ganze falsch an?

Beispiel:

1 Webserver in Büro Nr. 1 in Stadt X
------------------------------------------------------------ ----------------
Darauf läuft Apache-Webserver mit MySQL-Datenbank
und ein PHP basiertes CMS zur Verwaltung der Kundendaten,
welche in der MySQL-DB abgelegt werden.
Das ganze ist nach aussen per Firewall abgeriegelt.
Es soll nur Intern damit gearbeitet werden.
Software X synchronisiert das ganze mit den anderen Datenbanken.

1 Webserver in Büro Nr. 2 in Stadt Y
------------------------------------------------------------ ----------------
Darauf läuft Apache-Webserver mit MySQL-Datenbank
und ein PHP basiertes CMS zur Verwaltung der Kundendaten,
welche in der MySQL-DB abgelegt werden.
Das ganze ist nach aussen per Firewall abgeriegelt.
Es soll nur Intern damit gearbeitet werden.
Software X synchronisiert das ganze mit den anderen Datenbanken.

1 Webserver bei Webhosting-Provider in Stadt Z
------------------------------------------------------------ ----------------
Darauf läuft Apache-Webserver mit MySQL-Datenbank
und ein PHP basiertes CMS mit eingeschränktem Zugriff für die Kunden.
Das ganze ist von aussen per Login erreichbar.
Software X synchronisiert das ganze mit den anderen Datenbanken.

Re: zentrale Datenbank für unterschiedliche Orte?

Rainer Schmidt wrote:

> Wie würdet Ihr folgendes am besten lösen?
>
> Benötige Datenbank, auf die intern von 2 örtlich getrennten Büros
> zugegriffen wird
> und auf die extern in eingeschränktem Umfang zugegriffen wird.
Was heist extern? Aussendienstler mit Laptop vom Kunden oder von zu
Hause aus?
>
> Prinzipiell ist dazu zu sagen, dass ich es für unvorteilhaft halte,
> alles über einen Server, bzw. eine Datenbank (in diesem Fall, diese
> beim Webhosting-Provider) laufen zu lassen, da wir dann immer von einer
> guten Online-Verbindung (was in der Vergangenheit nicht immer der Fall
> war) abhängig wären.
>
Riesenproblem dabei, neben Sicherheit.. , wo und wie mache ich das
Backup? Auch Provider-Festplatten geben mal den Geist auf...

> Ich denke das Ideale wäre "örtlich installierte Datenbanken" (oder
> wie nennt man das?),
lokale Datenbank?
> die sich dann mit den anderen synchronisieren, oder?

> Die Frage wäre in diesem Fall, welche Software die Synchronisation
> vornehmen würde?
> Oder gehe ich das ganze falsch an?
>

> Beispiel:
....
Anderer Ansatz:
Baue zwischen den Standorten eine VPN-Verbindung auf. (Das hört sich
schwieriger an als es ist..gebe auch gern dazu noch ein paar Tips aber
dann bitte per Mail, das sprengt sonst diese Gruppe..)

Einen Server aufsetzten, der bei Dir in der Nähe ist, dafür mit
vernünftigen Backup etc...
Eine Applikation (egal wie und womit) aufsetzen mit durchdachtem
Rechtesystem..
Außenstellen greifen per VPN auf diese GEMEINSAME Datenhaltung zu. Keine
Synch.Probleme, kein ID-Match, Lagerbestand des Hauptlagers ist IMMER
aktuell etc.

Das Ganze hängt davon auch ab, wieviele Daten durchs Netz müssen ...
Das spart nämlich Fahrkosten zwischen den Standorten, Pflege und
Programmieraufwand etc.

Dietmar

Re: zentrale Datenbank für unterschiedliche Orte?

Dietmar Staritz schrieb:

> Rainer Schmidt wrote:
> > Benötige Datenbank, auf die intern von 2 örtlich getrennten Büros
> > zugegriffen wird
> > und auf die extern in eingeschränktem Umfang zugegriffen wird.

> Was heist extern? Aussendienstler mit Laptop vom Kunden oder von zu
> Hause aus?

Ok, extern ist der falsche Ausdruck. Damit sind beliebige Kunden
gemeint die über das Internet ihre Daten bzw. Status abfragen können.

Hmm, mit VPN haben wir bisher keine so guten Erfahrungen gemacht, was
die Performance angeht. Die Mitarbeiter (ca. 10 Stk) müssen den ganzen
Tag mit dieser Verbindung arbeiten und da kommt es immer wieder mal zu
Leitungsstörungen (von Deutschland in die Schweiz) was das Programm
unnötig ausbremst.
Deswegen meine ich sollte jedes Büro seine eigene Datenbank haben,
damit wir diese VPN-Leitungsprobleme umgehen können.

Re: zentrale Datenbank für unterschiedliche Orte?

Rainer Schmidt schrieb:
> Dietmar Staritz schrieb:
>
>> Rainer Schmidt wrote:
>>> Benötige Datenbank, auf die intern von 2 örtlich getrennten Büros
>>> zugegriffen wird
>>> und auf die extern in eingeschränktem Umfang zugegriffen wird.
>
>> Was heist extern? Aussendienstler mit Laptop vom Kunden oder von zu
>> Hause aus?
>
> Ok, extern ist der falsche Ausdruck. Damit sind beliebige Kunden
> gemeint die über das Internet ihre Daten bzw. Status abfragen können.
>
> Hmm, mit VPN haben wir bisher keine so guten Erfahrungen gemacht, was
> die Performance angeht. Die Mitarbeiter (ca. 10 Stk) müssen den ganzen
> Tag mit dieser Verbindung arbeiten und da kommt es immer wieder mal zu
> Leitungsstörungen (von Deutschland in die Schweiz) was das Programm
> unnötig ausbremst.
> Deswegen meine ich sollte jedes Büro seine eigene Datenbank haben,
> damit wir diese VPN-Leitungsprobleme umgehen können.
>

Und jeder Mitarbeiter soll jeden beliebigen Datensatz ändern können?
Wie genau stellst Du Dir dann vor, die Daten anschließend wieder zu
synchronisieren? That way lies madness.

Re: zentrale Datenbank für unterschiedliche Orte?

Rainer Schmidt wrote:
>>>Benötige Datenbank, auf die intern von 2 örtlich getrennten Büros
VPN oder 2 DB , diese werden dann mit seperaten Nummernkreisen für die
ID'S eingereichtet, sodaß KEINE Überschneidung eintreten kann. Über
separaten Prozess kann dann nachts ein Abgleich organisiert werden, so
daß die Daten von A zu B und B zu A übertragen werden..

oder siehe unten...

>>>und auf die extern in eingeschränktem Umfang zugegriffen wird.
Jo, das läuft eh separat...

> Hmm, mit VPN haben wir bisher keine so guten Erfahrungen gemacht, was
> die Performance angeht. Die Mitarbeiter (ca. 10 Stk) müssen den ganzen
> Tag mit dieser Verbindung arbeiten und da kommt es immer wieder mal zu
> Leitungsstörungen (von Deutschland in die Schweiz) was das Programm
> unnötig ausbremst.
Gut, Leitungsmöglichkeiten Schweiz kann ich nicht einschätzen. Aber ich
glaube, preislich sollte man Aufwand und nutzen durchaus mal
durchdenken, was Hardeware, Programmier- und Pflegeaufwand für diese
DB-Konstellation bedeutet im Gegensatz zur Anmietung vernünftiger Leitungen.

FÜR getrennte DB sprechen:
- wenn A ausfällt läuft immerhin B noch und umgedreht
- es werden nur Updates und Insert übertragen, die vielen Select's
laufen auf der jeweils örtlichen DB.
- höhere Performance, da Server im jeweiligen lokalen bzw. in der DMZ
gut erreichbar eingebunden ist


Gegen getrennte DB
- Die Daten aus DB A und B müssen eh durchs Kabel, dann sogar 2mal...
- Zeitverzug zwischen den Standorten, Daten sind ja erst nach
Übertragung am anderen Standort verfügbar
- An welcher DB binde ich die Web-Schnittstelle für die Kunden? Siehe
oben, irgendwelche Daten sind erst nach Zeitverzug sichtbar.
- Wenn ID-Matsch - dann gute Nacht!
....


ODER ICH MISCHE DEN GANZEN KRAM:

ID' und andere sequentiell relevante Nummern (LS, Rechnung, Vorgang..)
werden ausschließlich von nur einer Master-DB über den VPN- Kanal gezogen.
Alle anderen Daten werden nach Update und Insert auf die Slave oder
Master übertragen und liegen in damit lokal und auf der jeweiligen
anderen DB ziemlich schnell verfügbar.
Die ganzen selects werden schnell lokal durchgeführt...
Die inserts und updates dürften nicht solange auf sich warten lassen, da
der Datenverkehr ja nur aus diesen Statements besteht, die vielen
selects werden lokal behandelt..

Wenn dann die Verbindung unterbrochen ist, kann Slave keine Daten ändern
oder neu eingeben, aber noch gucken.. Ausfall Master geht gar nix mehr..

Na, dann mal viel Spaß bei der Kosten / Nutzen - Abwägung

Dietmar

Re: zentrale Datenbank für unterschiedliche Orte?

> ODER ICH MISCHE DEN GANZEN KRAM:
>
> ID' und andere sequentiell relevante Nummern (LS, Rechnung, Vorgang..)
> werden ausschließlich von nur einer Master-DB über den VPN- Kanal gezogen.
> Alle anderen Daten werden nach Update und Insert auf die Slave oder
> Master übertragen und liegen in damit lokal und auf der jeweiligen
> anderen DB ziemlich schnell verfügbar.
> Die ganzen selects werden schnell lokal durchgeführt...
> Die inserts und updates dürften nicht solange auf sich warten lassen, da
> der Datenverkehr ja nur aus diesen Statements besteht, die vielen
> selects werden lokal behandelt..
>
> Wenn dann die Verbindung unterbrochen ist, kann Slave keine Daten ändern
> oder neu eingeben, aber noch gucken.. Ausfall Master geht gar nix mehr..
>
> Na, dann mal viel Spaß bei der Kosten / Nutzen - Abwägung
>
> Dietmar

oder noch schlimmer, wenn Master ausfällt, könnte man das Switchen des
Slaves zum Master vorsehen, solange wie er aktuell ist, man muss dann
nur den anderen mitteilen, das er Master wurde, damit die Anfragen an
ID's richtig laufen... oder wenn du Wartungen planst, kannst du den
Slave zum Master werden lassen und den dann zum Slave gewordenen Master
runterfahren ... z.B. in der Form, daß du 2 Variablen definierst, Ort
des lokalen Slaves und Ort des Masters, dann kannst du sogar alle wieder
auf den entfernten Server schicken, brauchst nur den Ort des lokalen
Slaves auf den Master oder anderen Slave verweisen.. (z.B. bei
Totalausfall des Servers am Standort, bis du mit deinem
Diensthubschrauber dort gelandet bist, können deine Kollegen zwar
langsam aber weiterarbeiten...)

Also, auf der gedanklichen Spielwiese gibt es viele Möglichkeiten, aber
ich denke, Sinn macht das erst, wenn die DB Trigger und Prozeduren
unterstützt, damit die Transfer-Arbeit nicht dein Client machen muß,
sondern der DB aufgeschultert wird.

Dietmar