Die ultimative MySQL Legacydatenbank Alptraum

Question

Tabelle 1: Alles, einschließlich der Küchenspüle. Termine im falschen Format (Jahr zuletzt, so dass Sie auf dieser Spalte nicht sortiert werden können), gespeicherte Nummern als VARCHAR, vollständige Adressen in der ‚Straße‘ Spalte, Vorname und Nachnamen in der Vornamen Spalte, Stadt in dem Spalte Nachnamen, unvollständige Adressen, Zeilen, vorhergehenden Zeilen aktualisieren, indem Daten von einem Feld zum anderen zu bewegen, basierend auf einem gewissen Satz von Regeln, die im Laufe der Jahre verändert hat, doppelte Datensätze, unvollständige Datensätze, Müll Aufzeichnungen ... Sie nennen es ... ach ja, und natürlich kein TIMESTAMP- oder PRIMARY KEY-Spalte in Sicht.

Table2: Jede Hoffnung auf Normalisierung ging aus dem Fenster auf Knacken dieses Babys zu öffnen. Wir haben eine Reihe für jeden Eintrag und Aktualisierung der Zeilen in der Tabelle ein. So Duplikate wie es kein Morgen (800MB wert) und Spalten wie Phone1 Phone2 Phone3 Phone4 ... Phone15 (sie sind nicht angerufen. Ich benutze diese für Illustration) Der foriegn Schlüssel ist .. gut nehmen Vermutung. Es gibt drei Kandidaten je nachdem, welche Art von Daten war in der Zeile in Tabelle 1

Table3: Kann es noch schlimmer werden. Oh ja. Die „Fremdschlüssel ist eine VARCHAR-Spalte Kombination von Strichen, Punkten, Zahlen und Buchstaben! Wenn das nicht das Spiel bereitstellt (die es oft nicht), dann eine zweite Spalte von ähnlichen Produktcode sollte. Spalten, die Namen haben, die tragen NO Korrelation zu den Daten in sie, und die obligatorischen Phone1 Phone2 Phone3 Phone4 ... Phone15. Es gibt Spalten duplizierte aus Tabelle 1 und keine TIMESTAMP- oder PRIMARY KEY-Spalte in Sicht.

Table4: Es wurde als ein Werk in progess und Gegenstand beschrieben jederzeit ändern. Es ist essentailly simlar zu den anderen.

In der Nähe von 1 m Reihen ist dies ein großes Durcheinander. Zum Glück ist es nicht mein großes Durcheinander. Unglücklicherweise muss ich für jeden „Kunde“.

ein Composit-Rekord aus ihm ziehen

Zunächst erdacht ich eine Vier-Stufen-Übersetzung von Tabelle 1 einen Primärschlüssel hinzufügen und alle Daten in sortierbar-Format zu konvertieren. Dann noch ein paar Schritte von Abfragen, die gefilterten Daten zurückgegeben, bis ich Table1 musste, wo ich es verwenden könnte von den anderen Tabellen ziehen Sie den Composit zu bilden. Nach Wochen der Arbeit habe ich dies einen Schritt nach unten ein paar Tricks. So, jetzt kann ich meine App im Chaos Punkt und einen schönen sauberen Tisch KOMPOSITPROFILE Daten herausziehen. Zum Glück brauche ich nur eine der Telefonnummern für meine Zwecke so meine Tabelle Normalisierung ist kein Thema.

Dies ist jedoch, wo die eigentliche Aufgabe beginnt, weil jeden Tag Hunderte von Mitarbeitern hinzufügen / aktualisieren / löschen diese Datenbank in einer Weise, die Sie nicht wollen, sich vorzustellen, und jede Nacht muss ich die neuen Zeilen abgerufen werden.

Da vorhandene Zeilen in jeder der Tabellen geändert werden kann, und da es keine Zeitstempel UPDATE Spalten sind, werde ich in die Protokolle zurückgreifen müssen wissen, was passiert ist. Natürlich setzt dies voraus, dass es ein binäres Protokoll, das ist es nicht!

das Konzept Einführung ging wie Blei Ballon nach unten. Ich könnte genauso gut habe ihnen gesagt, dass ihre Kinder experimentelle Operation zu unterziehen haben werden. Sie sind nicht gerade hallo tech ... für den Fall, hatte man nicht gesammelt ...

Die Situation ist ein wenig empfindlich, da sie einige wertvolle Informationen, die meine Firma schlecht will. Ich habe von der Geschäftsleitung eines großen Unternehmens (Sie wissen, wie sie sind) zu „machen es möglich“.

herabgesandt

Ich kann mich keinen anderen Weg, um das nächtliche Updates zu handhaben, als mit noch einer anderen Anwendung der Bin-Protokolldatei Parsing, um herauszufinden, was sie zu dieser Datenbank im Laufe des Tages getan haben und dann entsprechend meinen Tisch Composite. Ich brauche wirklich nur an ihrem tabelle1 zu suchen, um herauszufinden, was zu meinem Tisch zu tun. Die anderen Tabellen nur Felder bieten den Datensatz zu spülen. (Mit Master-Slave wird nicht helfen, weil ich ein Duplikat des Chaos haben.)

Die Alternative ist, einen eindeutigen Hash für jede Zeile ihrer tabelle1 zu erstellen und eine Hash-Tabelle erstellen. Dann würde ich jeden Abend der gesamten Datenbank durchlaufen, wenn das hashs Spiel zu sehen, zu prüfen. Wenn sie nicht dann tun würde ich read dass Datensatz und überprüfen, ob es in meiner Datenbank vorhanden ist, wenn es funktioniert, dann würde ich es in meiner Datenbank aktualisieren, wenn es nicht dann tut sie einen neuen Rekord und ich würde es INSERT. Dies ist hässlich und nicht schnell, aber eine Binärlogdatei ist nicht schön entweder Parsen.

Ich habe das bekommen deutlich über das Problem zu helfen geschrieben. oft es an jemand anderen zu sagen hilft, das Problem zu klären eine Lösung deutlicher zu machen. In diesem Fall habe ich gerade eine größere Kopfschmerzen!

Ihre Gedanken sehr geschätzt würde.

Answer 1

Die Log-Dateien (binäre Protokolle) waren auch mein erster Gedanke. Wenn Sie wüssten, wie sie Dinge tat würden Sie schaudern. Für jede Zeile gibt es viele viele Einträge im Protokoll als Stücke hinzugefügt und geändert. Es ist einfach riesig! Vorerst ließ ich mich auf den Hash-Ansatz. Mit einiger cleveren Speicherauslagerungsdatei ist dies recht schnell.

Answer 2

Ich bin keine MySQL Person, so dass dies kommt aus dem linken Feld.

Aber ich denke, die Log-Dateien könnten die Antwort sein.

Zum Glück, die Sie wirklich brauchen nur 2 Dinge aus dem Protokoll kennen.

Sie müssen den Datensatz / Rowid, und Sie müssen den Vorgang.

In den meisten DB, und ich nehme an MySQL, gibt es eine implizite Spalte in jeder Zeile, wie ein Rowid oder RecordID, oder was auch immer. Es ist die interne Zeilennummer von der Datenbank verwendet. Das ist Ihr „frei“ Primärschlüssel.

Als nächstes müssen Sie den Vorgang. Bemerkenswert ist, ob es ein Einsatz, aktualisieren oder löschen Betrieb auf der Zeile.

Sie alle diese Informationen konsolidieren, in zeitlicher Reihenfolge, und führen Sie durch sie.

Für jede insert / update, wählen Sie die Zeile aus Ihrer ursprünglichen DB und insert / update, die Zeile in der Ziel-DB. Wenn es einen Lösch ist, dann löschen Sie die Zeile.

Sie kümmern sich nicht um Feldwerte, sie sind einfach nicht wichtig. Hat die ganze Reihe.

Sie sollten dann hoffentlich nicht müssen Binärlogdateien „analysieren“, muss MySQL bereits Routinen müssen das zu tun, müssen Sie nur finden und herauszufinden, wie sie benutzen (es auch einige sehr nützlich sein kann „dump log“ Dienstprogramm Sie können verwendet werden).

Auf diese Weise können Sie das System halten ziemlich einfach, und es sollte nur auf der tatsächlichen Aktivität während des Tages abhängen, anstatt die gesamte DB-Größe. Schließlich könnten Sie es später optimieren, indem sie „smarter“. Zum Beispiel legen sie vielleicht eine Zeile, dann aktualisieren, löschen Sie es anschließend. Sie würden wissen, können Sie nur diese Zeile ignorieren vollständig in Ihrer Wiedergabe.

Offensichtlich nimmt dies ein wenig obskuren Wissen um die Log-Dateien tatsächlich lesen, aber der Rest sollte einfach sein. Ich würde gerne glauben, dass die Protokolldateien als auch timestamped werden, so dass Sie wissen, auf Zeilen „von heute“ zu arbeiten, oder was auch immer Datumsbereich Sie wollen.

Answer 3

Können Sie nicht den vorhandenen Code benutzen, die auf diese Datenbank zugreift und passen sie an Ihre Bedürfnisse? Natürlich muss der Code schrecklich sein, aber es Macht für Sie die Datenbankstruktur handhaben, nicht wahr? Sie könnten hoffentlich Ihre Arbeit anstatt zu spielen Archäologen dann konzentrieren sich auf immer.

Answer 4

Sie könnten in der Lage sein Maatkit der mk-table-Sync-Tool zu verwenden, um eine Staging-Datenbank zu synchronisieren (die Datenbank ist nur sehr klein ist, nachdem alle). Dies wird „Duplikat das Chaos“

Sie könnten dann schreiben etwas, das nach der Synchronisation, verschiedene Abfragen tut, um einen Satz von mehr sane Tabellen zu erstellen, die Sie dann aus mitteilen.

Ich stelle mir vor, dass diese auf einer täglichen Basis ohne Leistungsproblem getan werden könnte.

alles aus einem anderen Server Dadurch wird vermieden, die ursprüngliche Datenbank zu beeinträchtigen.

Das einzige Problem, das ich sehen kann, ist, wenn einige der Tabellen keine Primärschlüssel haben.