seb_

Musst du auch nicht. Dann erwarte aber auch eine dementsprechend geringe Resonanz, wenn man dir jedes Puzzlestück einzeln aus der Nase ziehen soll. Hier gibt es ausreichend angagierte Leute. Nun stelle dir vor, sie sollen in jedem Beitrag jedes Puzzlestück erraten. Also entweder du spielst mit oder lebst damit. Hier gibt es schließlich (wie in jedem anderen Forum auch) Richtlinien.

Man hilft gerne, erwartet aber auch einen grundlegenden Informationsfluss. Und auf Hinweise versierter Benutzer einzugehen, versteht sich von selbst, denke ich.

MfG

__________________
Lesen gefährdet Ihre Dummheit!

Mister Ad

tr0y

Da deine Ausführungen über das genaue Vorhaben relativ dürftig gehalten sind, möchte ich dir hier Ansatzweise ein paar Sachen erläutern, die dir / deiner Datenwirtschaftslogik den nötigen Denkanstoß geben, die Sache entweder zu überdenken wie es vorgesehen war oder gegenteilig eure "Planung" bestätigen.

Prinzipiell dienen Datenbanken dazu einen Datenstamm zentral zu speichern / verfügbar zu machen, dabei wird aus Gründen der Wartbarkeit und der Speichereffizienz die Tabellenstruktur der einzelnen Tabellen normalisiert. Sodas nirgendwo Daten doppelt und dreifach eingetragen werden. Die Normalisierung setzt in der Regel die Datenstrukturen miteinander in Beziehung ( Relation - daher der Name "relationale Datenbank" mit einer eigens dafür entwickelten Structured Query Language - kurz SQL ).

Die Nutzung einer (relationalen) Datenbank ethabliert in der nutzenden Anwendung eine zentralisierte Datenvorhaltung, wann immer der Datenstamm benötigt wird, ist die Anwendung nie für dessen Vorhaltung, Performance oder Integrität zuständig. Datenbanken wie MySQL sind dafür konzipiert mehrere Client-Connections gleichzeitig zu bedienen und wenn nötig Datenbanken über mehrere Database-Hubs/-Mirrors zu spiegeln. Ersteres ist nicht zwingend an lokale Verbindungen gebunden sondern durchaus auch mit richtiger Infrastruktur innerhalb des LANs der hostenden Roots sinnvoll per remote lösbar. Zweiteres realisiert man am sinnvollsten mit der in der Datenbank-Serversoftware vorhandenen Replikationsmechanik, wobei es hierbei absolut egal ist ob nun 1000 Datensätze einer Tabelle oder 200 Millionen Datensätze einer oder mehrerer Datenbanken eines Servers repliziert werden müssen.

Zu Beginn des Threads äußerst du uns den Wunsch eine gewisse Menge an Daten auf mehrere Tabellen zu verteilen ( die, so spekuliere ich mal, allesamt die selbe Tabellenstruktur haben werden ), hierbei aber nicht nach einem eigentlichen Replika-Schema arbeiten zu wollen, sondern eine differenzielle Teilmenge aller Daten in gleiche Teile zu trennen und in eine dezentrale Speicherschnittstelle mehrerer Zielserver einzuspeisen. Um mehrere Daten-Teilmengen auf den jeweiligen Servern zu Verfügung zu stellen.

Im Prinzip wirft diese angedachte Vorgehensweise die Frage auf ob du diesen selektiven Aufwand beim einfügen der Daten überhaupt durchführen musst, oder ob es nicht sinnvoller wäre deinen "Bunch of Hosts" per Datenbank-Replizierung mit dem gesamten Datenbankstamm vollautomatisiert zu versorgen. Eine echte alternative, die natürlich unter der Beachtung etwaige Latenzschwierigkeiten, das selbe leisten könnte wäre ein Host der x nicht-lokale Clienten auf anderen Servern versorgt. Diese zweite Variante sollte aber wohl durchdacht und hinsichtlich Performance "mit allen Wassern gewaschen sein".

Der von dir gepostete SQL-Source wirft außerdem mit etwas verwunderlichen Limits um sich, die so garnicht in der SQL möglich sind. Bei INSERT INTO Statements ist der einfügende Client in der Lage einen oder mehrere Datensätze unter gleichem Datenbank-Feld-Schema in eine Tabelle einzufügen.

Gerade hier wird dem lesenden "Community-Mitglied" mit etwas SQL-Knowhow schnell bewusst, das du scheinbar nicht ausreichend informiert bist wie und was mit SQL möglich ist. Ich hoffe ich konnte dir einen minimalen Einblick oder gar einen kleinen Ausblick über den Tellerrand der einfachen MySQL-Nutzung ermöglichen, mit ausreichender Information und dem aneignen der anfänglichen Replikationslogik von MySQL, wirst du dein vorhaben ( so unwirklich gut beschrieben es auch jetzt immer sein mag ) lösen können.

Sollte dein eigentliches Problem aber ganz woanders ansetzen, könnte man auch das bei ausrechender Information diskutieren.

__________________
Lasse mir ohne Anwendung von Gewalt Dinge schenken, Amazon weiß darüber bald mehr.

lstegelitz

Das ist ja wie in der Dusche nach dem Sport... keine Angst, wir gucken euch schon nix weg

__________________
Über 90% aller Gewaltverbrechen passieren innerhalb von 24 Stunden nach dem Konsum von Brot.