Prüfsumme oder keine Prüfsumme: das ist hier die Frage!
Guten Tag die Herrschaften, nach einiger Zeit des Schaffens habe ich ein mal ne Denkblockade. Hier die Grundlage dazu. Ich bin gerade dabei Werte aus einer DB auszulesen und diese schön sauber mit korrekten Encoding usw. weg zu schreiben. Nun möchte ich natürlich auch sicher gehen, dass die Ausgangsdaten auch korrekt in der Ziel-DB ankommen. Quasi ist mir da sofort ne Art Prüfsummen-Bildung in den Kopf geschossen, frei nach dem Motto: Lies die Daten, mach ne Prüfsumme, schreib sie in die DB, lies sie und mach von den abermals gelesenen Daten ne Prüfsumme und vergleich beide und wenn gleich: COMMIT. Jetzt meine Frage. Geht das auch eleganter oder gibts das überhaupt oder bin ich gerade betriebsblind oder oder oder? Quasi wäre ich an Hinweisen, Vorschlägen und sonstigem, was helfen kann, interessiert. Ach ja, ich rede hier von ner DB die zarte 1 GB groß ist. Also immer her mit euren Vorschlägen. Danke schon mal und Gruß Michael
Am 10.05.2012 16:42, schrieb Michael Weber:
Guten Tag die Herrschaften,
nach einiger Zeit des Schaffens habe ich ein mal ne Denkblockade. Hier die Grundlage dazu.
Ich bin gerade dabei Werte aus einer DB auszulesen und diese schön sauber mit korrekten Encoding usw. weg zu schreiben. Nun möchte ich natürlich auch sicher gehen, dass die Ausgangsdaten auch korrekt in der Ziel-DB ankommen. Quasi ist mir da sofort ne Art Prüfsummen-Bildung in den Kopf geschossen, frei nach dem Motto: Lies die Daten, mach ne Prüfsumme, schreib sie in die DB, lies sie und mach von den abermals gelesenen Daten ne Prüfsumme und vergleich beide und wenn gleich: COMMIT.
Jetzt meine Frage. Geht das auch eleganter oder gibts das überhaupt oder bin ich gerade betriebsblind oder oder oder?
Quasi wäre ich an Hinweisen, Vorschlägen und sonstigem, was helfen kann, interessiert.
Ach ja, ich rede hier von ner DB die zarte 1 GB groß ist.
Also immer her mit euren Vorschlägen.
Hallo, Tests sind nie verkehrt. Wenn es zu langsam geht, kann man später noch optimieren. Mit dem Modul hashlib kannst du diverse Prüfsummen erstellen. Wenn der Sync zwischen beiden DBs ständig erfolgt, würde ich aber nicht immer alle Daten prüfen. Wenn du eine ordentliche Testumgebung hast, reicht es dort unittests laufen zu lassen. Gruß, Thomas -- Thomas Guettler, http://www.thomas-guettler.de/ E-Mail: guettli (*) thomas-guettler + de
Guten Morgen Thomas,
Tests sind nie verkehrt. Wenn es zu langsam geht, kann man später noch optimieren. Mit dem Modul hashlib kannst du diverse Prüfsummen erstellen.
An hashlib hab ich auch schon gedacht.
Wenn der Sync zwischen beiden DBs ständig erfolgt, würde ich aber nicht immer alle Daten prüfen. Wenn du eine ordentliche Testumgebung hast, reicht es dort unittests laufen zu lassen.
Der Sync ist ne einmalige Sache mit dem Ziel, das System, von dem gelesen wird, sterben zu lassen. Bitte korrigiere mich, wenn ich etwas falsch verstanden habe. Aber sind Unittests nicht dafür da, den Code und seine Funktionsfähigkeit an sich zu testen? Weil, wenn dem wirklich so ist, würde mir das nichts bringen, da ich nach einer Möglichkeit suche, sicher zu stellen, dass der gelesene Datensatz unverfälscht in das Ziel geschrieben wird. Quasi wäre das meine persönliche Garantie. Oder habe ich jetzt Unittests doch falsch verstanden? Gruß und Danke schon mal. Michael
Am 11.05.2012 08:59, schrieb Michael Weber:
Bitte korrigiere mich, wenn ich etwas falsch verstanden habe. Aber sind Unittests nicht dafür da, den Code und seine Funktionsfähigkeit an sich zu testen?
Korrekt. Und damit sind unittests nicht das, was Du suchst. -- Schönen Gruß - Regards Hartmut Goebel Dipl.-Informatiker (univ.), CISSP, CSSLP Goebel Consult Spezialist für IT-Sicherheit in komplexen Umgebungen http://www.goebel-consult.de Monatliche Kolumne: http://www.cissp-gefluester.de/ Goebel Consult ist Mitglied bei http://www.7-it.de
Am 11.05.2012 08:59, schrieb Michael Weber:
Guten Morgen Thomas,
Tests sind nie verkehrt. Wenn es zu langsam geht, kann man später noch optimieren. Mit dem Modul hashlib kannst du diverse Prüfsummen erstellen.
An hashlib hab ich auch schon gedacht.
Wenn der Sync zwischen beiden DBs ständig erfolgt, würde ich aber nicht immer alle Daten prüfen. Wenn du eine ordentliche Testumgebung hast, reicht es dort unittests laufen zu lassen.
Der Sync ist ne einmalige Sache mit dem Ziel, das System, von dem gelesen wird, sterben zu lassen.
Bitte korrigiere mich, wenn ich etwas falsch verstanden habe. Aber sind Unittests nicht dafür da, den Code und seine Funktionsfähigkeit an sich zu testen? Weil, wenn dem wirklich so ist, würde mir das nichts bringen, da ich nach einer Möglichkeit suche, sicher zu stellen, dass der gelesene Datensatz unverfälscht in das Ziel geschrieben wird. Quasi wäre das meine persönliche Garantie.
Ja, du hast Recht. "Unittest" ist nicht der passende Begriff. Ich meinte hier Integrationstest[1] Falls du ständig Daten zwischen den DBs abgleichen würdest, wäre hier auch ein ständiger Integrationstest sinnvoll. Für eine Einmalaktion natürlich nicht.
Oder habe ich jetzt Unittests doch falsch verstanden?
Nein, hast du nicht. Gruß, Thomas [1] http://de.wikipedia.org/wiki/Softwaretest#Integrationstest -- Thomas Guettler, http://www.thomas-guettler.de/ E-Mail: guettli (*) thomas-guettler + de
Guten Morgen Thomas,
Ja, du hast Recht. "Unittest" ist nicht der passende Begriff. Ich meinte hier Integrationstest[1] Falls du ständig Daten zwischen den DBs abgleichen würdest, wäre hier auch ein ständiger Integrationstest sinnvoll. Für eine Einmalaktion natürlich nicht.
Cool, dann bin ich ja beruhigt, dass ich in die gleiche Richtung gedacht hab :-). Grüße Michael
Am 11.05.2012 08:59 schrieb Michael Weber:
Der Sync ist ne einmalige Sache mit dem Ziel, das System, von dem gelesen wird, sterben zu lassen.
Tja, aber wo willst Du da ansetzen mit Prüfsummen? Stehen in der alten DB denn schon Prüfsummen drin? Wenn nein, hast Du doch folgendes Szenario: * lies Datensatz * berechne Prüfsumme * schreibe Datensatz und nun? was machst Du mit der Prüfsumme? Ok, Du kannst natürlich * lies geschriebenen Datensatz * berechne Prüfsumme * vergleiche Prüfsumme machen. Aber damit hast Du nur den Schreibvorgang verifiziert. Was, wenn - hypothetisch - beim Lesen was schiefging? Aber ich denke mal, daß das unwahrscheinlich ist, da die gängigen DB-Systeme doch so zuverlässig sind, daß man darauf verzichten kann. Und das ebenso beim Schreiben... Thomas
Hallo Thomas,
Tja, aber wo willst Du da ansetzen mit Prüfsummen? Stehen in der alten DB denn schon Prüfsummen drin?
Definitiv: Nein.
Wenn nein, hast Du doch folgendes Szenario:
* lies Datensatz * berechne Prüfsumme * schreibe Datensatz
und nun? was machst Du mit der Prüfsumme? Ok, Du kannst natürlich
* lies geschriebenen Datensatz * berechne Prüfsumme * vergleiche Prüfsumme
machen. Aber damit hast Du nur den Schreibvorgang verifiziert. Was, wenn - hypothetisch - beim Lesen was schiefging?
OMG, an das Leseproblem hatte ich noch gar nicht gedacht.
Aber ich denke mal, daß das unwahrscheinlich ist, da die gängigen DB-Systeme doch so zuverlässig sind, daß man darauf verzichten kann. Und das ebenso beim Schreiben...
Ich denke mal, dass ich die ganze Prüfsummen-Orgie eher unter den Tisch fallen lassen werde einfach mal den beiden Datenbanksystemen vertraue will. Statt dessen werde ich lieber ausreichend Tests machen mit den Daten, die in der Ziel-DB landen. Gruß und fetten Dank Michael
Hallo,
On Thu, 10 May 2012 16:42:56 +0200
Michael Weber
Ich bin gerade dabei Werte aus einer DB auszulesen und diese schön sauber mit korrekten Encoding usw. weg zu schreiben. Nun möchte ich natürlich auch sicher gehen, dass die Ausgangsdaten auch korrekt in der Ziel-DB ankommen. Quasi ist mir da sofort ne Art Prüfsummen-Bildung in den Kopf geschossen, frei nach dem Motto: Lies die Daten, mach ne Prüfsumme, schreib sie in die DB, lies sie und mach von den abermals gelesenen Daten ne Prüfsumme und vergleich beide und wenn gleich: COMMIT.
Jetzt meine Frage. Geht das auch eleganter oder gibts das überhaupt oder bin ich gerade betriebsblind oder oder oder?
Ich würde dir hingegen vorschlagen einfach eine Datenbank zu verwenden der du vertrauen kannst. Ich habe noch nie einen korrupten Datensatz aus z.B. PostgreSQL bekommen und es würde mir im Traum nicht einfallen da Checksummen zu machen. Wenn man damit anfängt, dann hat das kein Ende, da kann ich auch paranoid werden und die Daten im RAM checksummen, kann ja sein dass ein kosmischer Bitflip sie kaputtgemacht hat. Und dann sollte ich die Funktion zum checksummen checksummen, und diese wieder checksummen. It's checksums all the way down. Nene, ich sehe hier echt keinen Handlungsbedarf. Mir wirkt so als erfindest du dein eigenes Problem. Aber vielleicht fehlen mir die Informationen: wie kommst du auf die Idee Daten in der Datenbank zu checksummen, hattest du denn damit schon Probleme? grüße, Marek
Am 10.05.2012 16:42, schrieb Michael Weber:
Ach ja, ich rede hier von ner DB die zarte 1 GB groß ist.
Dann würde ich beide Datenbanken als SQL oder die einzelnen Tabellen als CVS dumpen und einen diff darüber jagen. Du gehst ja davon aus, dass es keine Fehler bei der Übertragung gegeben hat. -- Schönen Gruß - Regards Hartmut Goebel Dipl.-Informatiker (univ.), CISSP, CSSLP Goebel Consult Spezialist für IT-Sicherheit in komplexen Umgebungen http://www.goebel-consult.de Monatliche Kolumne: http://www.cissp-gefluester.de/ Goebel Consult ist Mitglied bei http://www.7-it.de
participants (5)
-
Hartmut Goebel -
Marek Kubica -
Michael Weber -
Thomas Guettler -
Thomas Rachel