MySQL Dump mit Perl bearbeiten

Hallo,

ich habe einen MySQL-Dump, also ein Backup einer MySQL-Datenbank. Bevor
dieses eingespielt wird, möchte ich einige Änderungen an den Daten
vornehmen. Ich vermute, es ist am schnellsten, ich nehme die Änderungen
im dump selber vor, statt die Daten einzuspielen und dann in der
Datenbank zu ändern.

Wie kann ich das .sql-File am besten einlesen und bearbeiten? Gibt es da
schon fertige Module? Oder muss ich mir selbst einen parser schreiben?

Ein Ansatz war (bei etwas anderen Anforderungen):
Den dump einspielen, die Daten, die ich benötige als CSV exportieren, das
CSV bearbeiten, das CSV einspielen.
Das scheint mir aber etwas, hmm, umständlich.

Gruss

Chris

Re: MySQL Dump mit Perl bearbeiten

Hi Christian

Christian Schmidt wrote:
> ich habe einen MySQL-Dump, also ein Backup einer MySQL-Datenbank. Bevor
> dieses eingespielt wird, möchte ich einige Änderungen an den Daten
> vornehmen. Ich vermute, es ist am schnellsten, ich nehme die Änderungen
> im dump selber vor, statt die Daten einzuspielen und dann in der
> Datenbank zu ändern.

Welche Art von Änderungen willst du vornehmen?
Nein, am schnellsten ist's im Normalfall, diese Änderungen per SQL
auszuführen.

> Wie kann ich das .sql-File am besten einlesen und bearbeiten? Gibt es da
> schon fertige Module? Oder muss ich mir selbst einen parser schreiben?

Du kannst über RegExps das File verändern.

> Ein Ansatz war (bei etwas anderen Anforderungen):
> Den dump einspielen, die Daten, die ich benötige als CSV exportieren, das
> CSV bearbeiten, das CSV einspielen.
> Das scheint mir aber etwas, hmm, umständlich.

Das ist sicher das überflüssigste, was du machen kannst.

Wo ist nun deine MySQL-Frage?

HTH, Johannes

Re: MySQL Dump mit Perl bearbeiten

Johannes Vogel schrieb:

> Christian Schmidt wrote in de.comp.lang.perl.misc:

>> ..

> Wo ist nun deine MySQL-Frage?

Genau, mehr MySQL-Fragen in Perl-NGs =)


SCNR

gruß, Frank

Re: MySQL Dump mit Perl bearbeiten

Christian Schmidt wrote:

> Hallo,
>
> ich habe einen MySQL-Dump, also ein Backup einer MySQL-Datenbank. Bevor
> dieses eingespielt wird, möchte ich einige Änderungen an den Daten
> vornehmen. Ich vermute, es ist am schnellsten, ich nehme die Änderungen
> im dump selber vor, statt die Daten einzuspielen und dann in der
> Datenbank zu ändern.

Da wäre ich mir nicht so sicher; das wäre eine genaue Untersuchung wert.
Gerade Daten, die ohnehin in die Datenbank kommen sollen, sind in der DB
oft am einfachsten zu bearbeiten; das hängt aber von der Art der
Änderungen ab.

> Wie kann ich das .sql-File am besten einlesen und bearbeiten? Gibt es
> da schon fertige Module? Oder muss ich mir selbst einen parser
> schreiben?

MySQL ist so ein Parser (SCNR)


> Ein Ansatz war (bei etwas anderen Anforderungen):
> Den dump einspielen, die Daten, die ich benötige als CSV exportieren,
> das CSV bearbeiten, das CSV einspielen.
> Das scheint mir aber etwas, hmm, umständlich.

Das ist, je nach Rahmenbedingungen, auch eine Möglichkeit - allerdings
besteht bei CSV die Gefahr, daß Zeichen wie '"', ',', ';' etc. nicht so
sauber verarbeitet werden, wie es vielleicht wünschenswert wäre. Eine
Art "modifiziertes CSV" wäre dann vielleicht eine Möglichkeit.

Aber wie gesagt - ich würde zur Nachbearbeitung in der DB tendieren.


Thomas
--
Windows 98 - from the people who brought you EDLIN

Re: MySQL Dump mit Perl bearbeiten

Christian Schmidt wrote:
>
> ich habe einen MySQL-Dump, also ein Backup einer MySQL-Datenbank. Bevor
> dieses eingespielt wird, möchte ich einige Änderungen an den Daten
> vornehmen. Ich vermute, es ist am schnellsten, ich nehme die Änderungen
> im dump selber vor, statt die Daten einzuspielen und dann in der
> Datenbank zu ändern.

Das kommt wohl auf Art und Umfang der Änderungen an.

> Wie kann ich das .sql-File am besten einlesen und bearbeiten? Gibt es da
> schon fertige Module?

Mir sind keine bekannt. Aber im Prinzip ist ein Dump eine Anreihung
gültiger SQL-Statements. Allerdings halt mit MySQL-Erweiterungen wie
magischen Kommentaren, erweiterter Syntax etc.

> Oder muss ich mir selbst einen parser schreiben?

Machen. Aber laß dich warnen, je nach Version von mysqldump und
verwendeten Optionen kann ein Dump recht unterschiedlich aussehen.
Außerdem können da Binärdaten drin stehen etc. pp.

Zumindest Text::Balanced wirst du schon brauchen, um einzelne Elemente
sauber zu extrahieren. Genau diese Probleme sparst du dir allerdings,
wenn du die Daten in der Datenbank bearbeitest.

> Ein Ansatz war (bei etwas anderen Anforderungen):
> Den dump einspielen, die Daten, die ich benötige als CSV exportieren, das
> CSV bearbeiten, das CSV einspielen.
> Das scheint mir aber etwas, hmm, umständlich.

Allerdings ist CSV tendenziell deutlich einfacher als ein Dump.


XL

Re: MySQL Dump mit Perl bearbeiten

Am Thu, 14 Dec 2006 18:17:16 +0100 schrieb Johannes Vogel:

> Hi Christian
>
> Christian Schmidt wrote:
>> ich habe einen MySQL-Dump, also ein Backup einer MySQL-Datenbank. Bevor
>> dieses eingespielt wird, möchte ich einige Änderungen an den Daten
>> vornehmen. Ich vermute, es ist am schnellsten, ich nehme die Änderungen
>> im dump selber vor, statt die Daten einzuspielen und dann in der
>> Datenbank zu ändern.
>
> Welche Art von Änderungen willst du vornehmen?
> Nein, am schnellsten ist's im Normalfall, diese Änderungen per SQL
> auszuführen.

Nach den bisherigen Anmerkungen glaube ich das inzwischen auch eher.

Aber nochmal an einem ganz konkreten Beispiel:
In einer Spalte steht das Geburtsdatum und ich möchte in einer
zusätzlichen Spalte das aktuelle Alter (Jahresgenau, nicht Taggenau)
speichern. Redundanz und das jährliche update sind bekannt, gewünscht,
eingeplant und notwendig.

Ich bilde mir jetzt ein, wenn ich ein CSV-File "Zeilenweise" durchgehe,
das Alter berechne und dann in diese Zeile dazuschreibe geht das
schneller als wenn ich Zeilenweise durch die Datenbank gehe. Aber
vermutlich stehe ich hier einfach auf dem Schlauch und habe zu wenig
Ahnung von SQL :-) Im Moment hab ich nämlich noch konkret gar keine
Ahnung wie ich das machen könnte... Deshalb die auch nochmal nach nebenan
zu den MySQL-Profis.

Und zu den Dimensionen: Ich muss dann jeden Tag ca. 4 Mio Datenzeilen
bearbeiten. Im Moment "übe" ich mit 300.000 :-)


Gruß

Chris

Re: MySQL Dump mit Perl bearbeiten

Am Thu, 14 Dec 2006 18:17:16 +0100 schrieb Johannes Vogel:

> Hi Christian
>
> Christian Schmidt wrote:
>> ich habe einen MySQL-Dump, also ein Backup einer MySQL-Datenbank. Bevor
>> dieses eingespielt wird, möchte ich einige Änderungen an den Daten
>> vornehmen. Ich vermute, es ist am schnellsten, ich nehme die Änderungen
>> im dump selber vor, statt die Daten einzuspielen und dann in der
>> Datenbank zu ändern.
>
> Welche Art von Änderungen willst du vornehmen?
> Nein, am schnellsten ist's im Normalfall, diese Änderungen per SQL
> auszuführen.

Nach den bisherigen Anmerkungen glaube ich das inzwischen auch eher.

Aber nochmal an einem ganz konkreten Beispiel:
In einer Spalte steht das Geburtsdatum und ich möchte in einer
zusätzlichen Spalte das aktuelle Alter (Jahresgenau, nicht Taggenau)
speichern. Redundanz und das jährliche update sind bekannt, gewünscht,
eingeplant und notwendig.

Ich bilde mir jetzt ein, wenn ich ein CSV-File "Zeilenweise" durchgehe,
das Alter berechne und dann in diese Zeile dazuschreibe geht das
schneller als wenn ich Zeilenweise durch die Datenbank gehe. Aber
vermutlich stehe ich hier einfach auf dem Schlauch und habe zu wenig
Ahnung von SQL :-) Im Moment hab ich nämlich noch konkret gar keine
Ahnung wie ich das machen könnte... Deshalb die auch nochmal nach nebenan
zu den MySQL-Profis.

Und zu den Dimensionen: Ich muss dann jeden Tag ca. 4 Mio Datenzeilen
bearbeiten. Im Moment "übe" ich mit 300.000 :-)


Gruß

Chris

Re: MySQL Dump mit Perl bearbeiten

Christian Schmidt wrote:

> In einer Spalte steht das Geburtsdatum und ich möchte in einer
> zusätzlichen Spalte das aktuelle Alter (Jahresgenau, nicht Taggenau)
> speichern. Redundanz und das jährliche update sind bekannt, gewünscht,
> eingeplant und notwendig.

Das ist ein ganz falscher Ansatz. Den Wert berechnet man in
der Selektion.

Abgesehen davon stecken in Deinen Überlegungen
diverse Denkfehler:

o Du müsstest täglich und nicht jährlich updaten
o Du vernachlässigst bei Deinen Aufwandsüberlegungen
den Aufwand von Export und Import

Grüße
Frank
--
Dipl.-Inform. Frank Seitz; http://www.fseitz.de/
Anwendungen für Ihr Internet und Intranet
Tel: 04103/180301; Fax: -02; Industriestr. 31, 22880 Wedel

Re: MySQL Dump mit Perl bearbeiten

Christian Schmidt wrote:

> In einer Spalte steht das Geburtsdatum und ich möchte in einer
> zusätzlichen Spalte das aktuelle Alter (Jahresgenau, nicht Taggenau)
> speichern. Redundanz und das jährliche update sind bekannt, gewünscht,
> eingeplant und notwendig.

Das ist ein ganz falscher Ansatz. Den Wert berechnet man in
der Selektion.

Abgesehen davon stecken in Deinen Überlegungen
diverse Denkfehler:

o Du müsstest täglich und nicht jährlich updaten
o Du vernachlässigst bei Deinen Aufwandsüberlegungen
den Aufwand von Export und Import

Grüße
Frank
--
Dipl.-Inform. Frank Seitz; http://www.fseitz.de/
Anwendungen für Ihr Internet und Intranet
Tel: 04103/180301; Fax: -02; Industriestr. 31, 22880 Wedel

Re: MySQL Dump mit Perl bearbeiten

Christian Schmidt schrieb:
> In einer Spalte steht das Geburtsdatum und ich möchte in einer
> zusätzlichen Spalte das aktuelle Alter (Jahresgenau, nicht Taggenau)
> speichern. Redundanz und das jährliche update sind bekannt, gewünscht,
> eingeplant und notwendig.

http://dev.mysql.com/doc/refman/5.0/en/date-calculations.htm l

Meinjanur


gruß, Frank

Re: MySQL Dump mit Perl bearbeiten

Am Thu, 14 Dec 2006 19:53:04 +0100 schrieb Frank Seitz:

> Christian Schmidt wrote:
>
>> In einer Spalte steht das Geburtsdatum und ich möchte in einer
>> zusätzlichen Spalte das aktuelle Alter (Jahresgenau, nicht Taggenau)
>> speichern. Redundanz und das jährliche update sind bekannt, gewünscht,
>> eingeplant und notwendig.
>
> Das ist ein ganz falscher Ansatz. Den Wert berechnet man in
> der Selektion.

IdR hast Du mit dieser Aussage Recht, in meinem Fall aber nicht. Kurz
gesagt, es geht um ein Data Warehouse,
http://de.wikipedia.org/wiki/Starschema

> Abgesehen davon stecken in Deinen Überlegungen
> diverse Denkfehler:
>
> o Du müsstest täglich und nicht jährlich updaten

Nein, mir reicht die Genauigkeit $aktuelles_Jahr-$Geburtsjahr völlig aus.
Und wenn ich am 30.6. update, stimmt es ja im Schnitt wieder :-)

> o Du vernachlässigst bei Deinen Aufwandsüberlegungen
> den Aufwand von Export und Import

Genau das versuche ich ja herauszufinden. Lohnt sich der "Aufwand". Ich
werde morgen mal ohne Im- und Export testen, mal sehen wie das
funktioniert.

Chris

Re: MySQL Dump mit Perl bearbeiten

Hi Christian

Christian Schmidt wrote:
> Am Thu, 14 Dec 2006 19:53:04 +0100 schrieb Frank Seitz:
>> Christian Schmidt wrote:
>>> In einer Spalte steht das Geburtsdatum und ich möchte in einer
>>> zusätzlichen Spalte das aktuelle Alter (Jahresgenau, nicht Taggenau)
>>> speichern. Redundanz und das jährliche update sind bekannt, gewünscht,
>>> eingeplant und notwendig.
>> Das ist ein ganz falscher Ansatz. Den Wert berechnet man in
>> der Selektion.
> IdR hast Du mit dieser Aussage Recht, in meinem Fall aber nicht. Kurz
> gesagt, es geht um ein Data Warehouse,
> http://de.wikipedia.org/wiki/Starschema

Moment mal: Du hast kaum Ahnung von SQL, willst aber ein DW oder OLAP
System im grossen Stil designen? Scheint, als könntest du dich gut (oder
sehr billig) verkaufen. Aber ohne Kenntnisse von DBS sollte man sowas
nicht designen wollen. Andere (inkl. dir selbst) werden sich später über
dich ärgern.

>>> Und zu den Dimensionen: Ich muss dann jeden Tag ca. 4 Mio Datenzeilen
>>> bearbeiten. Im Moment "übe" ich mit 300.000 :-)

Das sind nicht zwingend Grössenordnungen, die MySQL in die Knie zwingen
sollten. Die Frage ist aber, wie man diese Datenmengen behandelt. Wenn
du wild Cross Joins darauf anwendest, ist das natürlich ungünstig.

Hier mal einige Spielereien auf einer alten Mühle:
Linux dev 2.6.15-1-686 #2 Mon Mar 6 15:27:08 UTC 2006 i686
Pentium III (Katmai), 501.364 MHz, 512 KB Cache, 646752 kB Mem,
HDD: Maxtor 6Y080L0 160 GB, PHP 5.1.1, MySQL 4.1.13-standard-log

1. Daten bereitstellen:
for ($j=0; $j $sql = "insert into test values ";
for ($i=0; $i $sql.=sprintf("('%04d-%02d-%02d'),",
rand(1900,2000),rand(1,12),rand(1,30));
print substr($sql,0,-1).";";
}
print substr($sql,0,-2).";";

# time php test.php > test.sql
real 1m41.112s
user 1m36.906s
sys 0m3.946s

ergibt test.sql:
insert into test values ('1910-02-27'),('1955-06-28'),(...);
insert into test values ('1952-12-07'),('1982-08-14'),(...);
(...)

2. Daten einspeisen:
mysql> create table test (birthday date);
# time mysql test < test.sql
real 1m13.533s
user 0m7.814s
sys 0m1.347s

Records: 4194304

3. Daten auslesen
mysql> select avg(year(now())-year(birthday)) from test;
1 row in set (5.47 sec)

4. Daten auslesen und für Weiterverwendung schreiben
mysql> create table test2 (birthday date,age tinyint);
mysql> insert into test2 (birthday,age)
select birthday, year(now())-year(birthday) from test;
Query OK, 4194304 rows affected (13.11 sec)

mysql> select avg(age) from test2; --> 56.0185
1 row in set (3.25 sec)


Da du von täglichen Aufgaben und grösseren Datenmengen schreibst, gehe
ich davon aus, dass du genügend Budget für ein anständiges System für
diese Anwendung zur Verfgügung hast. Dann würde ich behaupten, dass
deine Sachen nicht wirklich Performance-Probleme bereiten werden und du
dich vor allem darauf konzentrieren solltest, dass das System sauber und
möglichst ohne Basteleien konzipiert wird.

Übrigens könnte man sich auch Gedanken machen, ob MySQL bzw. ein RDBMS
die richtige Wahl ist. Vielleicht magst du sogar lieber ein
Statistik-Paket verwenden? Sieh dir dazu mal SAS o.ä. an.

HTH, Johannes

Re: MySQL Dump mit Perl bearbeiten

Christian Schmidt:

> Aber nochmal an einem ganz konkreten Beispiel:
> In einer Spalte steht das Geburtsdatum und ich möchte in einer
> zusätzlichen Spalte das aktuelle Alter (Jahresgenau, nicht Taggenau)
> speichern. Redundanz und das jährliche update sind bekannt, gewünscht,
> eingeplant und notwendig.

Warum willst du etwas, was du zur Laufzeit jederzeit berechnen
kannst, extra nochmal in der DB abspeichern? Eben im Hinblick
auf die Aufwände, die sich durch das Update ergeben. Außerdem
ist der Ansatz mit jährlichen Updates ziemlich ungenau, denn wenn
jemand am 31.12. geboren wurde, ist er dann am 1.1 des Folge-
jahres auch ein Jahr alt, genauso wie jemand, der genau vor einem
Jahr geboren wurde? Seriöserweise müsstest du also dieses Update
zumindest monatlich, besser wöchentlich fahren. Und da kann schon
einiges an Aufwänden (Export/Neuberechnung/Re-Import)
zusammenkommen.

> Und zu den Dimensionen: Ich muss dann jeden Tag ca. 4 Mio Datenzeilen
> bearbeiten. Im Moment "übe" ich mit 300.000 :-)

Ein Grund mehr, das Abspeichern und die Pflege reduntanter
Informationen zu vermeiden.

LG, Ferry

--
Ing Ferry Bolhar
Magistrat der Stadt Wien - MA 14
A-1010 Wien
E-Mail: bol@adv.magwien.gv.at

Re: MySQL Dump mit Perl bearbeiten

Christian Schmidt schrieb:

> In einer Spalte steht das Geburtsdatum und ich möchte in einer
> zusätzlichen Spalte das aktuelle Alter (Jahresgenau, nicht Taggenau)
> speichern. Redundanz und das jährliche update sind bekannt, gewünscht,
> eingeplant und notwendig.

Gibt es keine Views in MySQL?
Redundante Daten abzuspeichern ist selten eine gute Idee.

> Ich bilde mir jetzt ein, wenn ich ein CSV-File "Zeilenweise" durchgehe,
> das Alter berechne und dann in diese Zeile dazuschreibe geht das
> schneller als wenn ich Zeilenweise durch die Datenbank gehe.

Ach Gottchen.
Um die Daten zu dumpen, mußt Du einmal "zeilenweise" durch die Daten
gehen.
Um sie zu verändern, mußt Du auch komplett durch die Daten gehen.
Um sie wieder zu laden, mußt Du noch einmal "zeilenweise" durch die
Daten gehen.
Bei vorsichtiger Schätzung dauert das bestimmt 20mal länger als das
einzelne SQL-Statement, das Du absetzen müßtest.
Und: während Du diesen Zyklus Export-Ändern-Import durchführst,
stehen die Daten nicht (die ganze Zeit über) zur Verfügung.

Datenbanken sind u.A. für solche Aufgaben erfunden worden und
optimiert.

> Und zu den Dimensionen: Ich muss dann jeden Tag ca. 4 Mio Datenzeilen
> bearbeiten. Im Moment "übe" ich mit 300.000 :-)

Je mehr Daten, desto Datenbank :)

Re: MySQL Dump mit Perl bearbeiten

Am Fri, 15 Dec 2006 08:48:29 +0100 schrieb Ferry Bolhar:

> Christian Schmidt:
>
>> Aber nochmal an einem ganz konkreten Beispiel:
>> In einer Spalte steht das Geburtsdatum und ich möchte in einer
>> zusätzlichen Spalte das aktuelle Alter (Jahresgenau, nicht Taggenau)
>> speichern. Redundanz und das jährliche update sind bekannt, gewünscht,
>> eingeplant und notwendig.
>
> Warum willst du etwas, was du zur Laufzeit jederzeit berechnen
> kannst, extra nochmal in der DB abspeichern? Eben im Hinblick

Ok, wie ich heute beim testen gemerkt habe, das Geburtsdatum war ein
blödes Beispiel. Das ist wirklich am schnellsten bei der Abfrage
berechnet.

Bin aber bei einer anderen Tabelle an Grenzen gestoßen, die in meinem
Fall redundanz Sinnvoll machen. Ich habe vorhin mal die Berechnung von
300.000 Kontoständen bei 11 Mio Buchungen angestoßen, mal sehen wie lange
das dauert.

Hier macht Redundanz vermutlich Sinn.

> auf die Aufwände, die sich durch das Update ergeben. Außerdem
> ist der Ansatz mit jährlichen Updates ziemlich ungenau, denn wenn
> jemand am 31.12. geboren wurde, ist er dann am 1.1 des Folge-
> jahres auch ein Jahr alt, genauso wie jemand, der genau vor einem
> Jahr geboren wurde? Seriöserweise müsstest du also dieses Update

Deshalb update in der Mitte des Jahres, dann gleichen sich die zwei
Personen (31.12. und 1.1.) aus. Aber das Thema ist erstmal vom Tisch.

gruß

Christian

Re: MySQL Dump mit Perl bearbeiten

Christian Schmidt wrote:
> Am Fri, 15 Dec 2006 08:48:29 +0100 schrieb Ferry Bolhar:
>>
>>auf die Aufwände, die sich durch das Update ergeben. Außerdem
>>ist der Ansatz mit jährlichen Updates ziemlich ungenau, denn wenn
>>jemand am 31.12. geboren wurde, ist er dann am 1.1 des Folge-
>>jahres auch ein Jahr alt, genauso wie jemand, der genau vor einem
>>Jahr geboren wurde? Seriöserweise müsstest du also dieses Update
>
> Deshalb update in der Mitte des Jahres, dann gleichen sich die zwei
> Personen (31.12. und 1.1.) aus.

Ägypten?
Eine Person wird am Tag ihres Geburtstages um ein Jahr älter.
An dem Tag muss ihre gespeicherte Altersangabe aktualisiert
werden, wenn sie korrekt sein soll. Auf die Menge aller
Personen müsstest Dein Update also jeden Tag anwenden.

Grüße
Frank
--
Dipl.-Inform. Frank Seitz; http://www.fseitz.de/
Anwendungen für Ihr Internet und Intranet
Tel: 04103/180301; Fax: -02; Industriestr. 31, 22880 Wedel

Re: MySQL Dump mit Perl bearbeiten

Am Sat, 16 Dec 2006 00:36:42 +0100 schrieb Frank Seitz:

> Christian Schmidt wrote:
>> Am Fri, 15 Dec 2006 08:48:29 +0100 schrieb Ferry Bolhar:
>>>
>>>auf die Aufwände, die sich durch das Update ergeben. Außerdem
>>>ist der Ansatz mit jährlichen Updates ziemlich ungenau, denn wenn
>>>jemand am 31.12. geboren wurde, ist er dann am 1.1 des Folge-
>>>jahres auch ein Jahr alt, genauso wie jemand, der genau vor einem
>>>Jahr geboren wurde? Seriöserweise müsstest du also dieses Update
>>
>> Deshalb update in der Mitte des Jahres, dann gleichen sich die zwei
>> Personen (31.12. und 1.1.) aus.
>
> Ägypten?

Wie meinen?

> Eine Person wird am Tag ihres Geburtstages um ein Jahr älter.
> An dem Tag muss ihre gespeicherte Altersangabe aktualisiert

(1.1.+31.12.)/2=30.6.
Wenn mir diese Genauigkeit reicht, wo liegt das Problem?

Chris

Re: MySQL Dump mit Perl bearbeiten

Mahlzeit!

Christian Schmidt wrote:

> Bin aber bei einer anderen Tabelle an Grenzen gestoßen, die in meinem
> Fall redundanz Sinnvoll machen. Ich habe vorhin mal die Berechnung von
> 300.000 Kontoständen bei 11 Mio Buchungen angestoßen, mal sehen wie lange
> das dauert.

Stored Procedure o.ä., die beim Anlegen einer neuen Buchung den Saldo
am Konto verändert. (Oder besser: überlege Dir, ob Du öfter das Konto
ausliest oder neue Buchungen anlegst, man kann auf Auslesen oder
Schreiben optimieren)

Variante: Abends einen Buchungsschnitt machen, der die Tagesbewegungen
auf den Kontensaldo überträgt.

Also Redundanz ja, Dumpbearbeitung aber auch hier auf gar keinen Fall
(jedenfalls meiner Meinung nach).

Gruß,
Christian
--
sub _{print"\n"}_;for(;$s<9;++$s){$_='1E2018201E00001E2018201E00001E2018201'
..'E002020001C2222221400005CA2A2A27C02001C2222221C20003E0402 02201F2422221C00'
..'242A2A2A12002020001C2222221F20001C2A2A2A0C';while(s;(..); ;){printf'%c',hex
$1&1<<$s?40:32}_}$_=':::Christian Garbs:',y;:;\t;;print;_;_

Re: MySQL Dump mit Perl bearbeiten

On 2006-12-16 10:21, Christian Schmidt wrote:
> Am Sat, 16 Dec 2006 00:36:42 +0100 schrieb Frank Seitz:
>> Christian Schmidt wrote:
>>> Am Fri, 15 Dec 2006 08:48:29 +0100 schrieb Ferry Bolhar:
>>>>auf die Aufwände, die sich durch das Update ergeben. Außerdem
>>>>ist der Ansatz mit jährlichen Updates ziemlich ungenau, denn wenn
>>>>jemand am 31.12. geboren wurde, ist er dann am 1.1 des Folge-
>>>>jahres auch ein Jahr alt, genauso wie jemand, der genau vor einem
>>>>Jahr geboren wurde? Seriöserweise müsstest du also dieses Update
>>>
>>> Deshalb update in der Mitte des Jahres, dann gleichen sich die zwei
>>> Personen (31.12. und 1.1.) aus.
>>
>> Ägypten?
>
> Wie meinen?
>
>> Eine Person wird am Tag ihres Geburtstages um ein Jahr älter.
>> An dem Tag muss ihre gespeicherte Altersangabe aktualisiert
>
> (1.1.+31.12.)/2=30.6.

Es macht keinen Unterschied, an welchem Tag Du aktualisierst. Wenn Du
nur einmal im Jahr das Alter berechnest, wird die Anzahl der Leute, bei
denen es falsch ist, im Durchschnitt 50% betragen.

> Wenn mir diese Genauigkeit reicht, wo liegt das Problem?

Wenn Deinen Benutzern diese Genauigkeit auch reicht, gibt es kein
Problem.

hp


--
_ | Peter J. Holzer | > Wieso sollte man etwas erfinden was nicht
|_|_) | Sysadmin WSR | > ist?
| | | hjp@hjp.at | Was sonst wäre der Sinn des Erfindens?
__/ | http://www.hjp.at/ | -- P. Einstein u. V. Gringmuth in desd

Re: MySQL Dump mit Perl bearbeiten

Christian Schmidt wrote:
> Am Sat, 16 Dec 2006 00:36:42 +0100 schrieb Frank Seitz:
>>
>>Eine Person wird am Tag ihres Geburtstages um ein Jahr älter.
>>An dem Tag muss ihre gespeicherte Altersangabe aktualisiert
>
> (1.1.+31.12.)/2=30.6.
> Wenn mir diese Genauigkeit reicht, wo liegt das Problem?

Es ist Unfug. Abgesehen davon ist da kein Problem.

Grüße
Frank
--
Dipl.-Inform. Frank Seitz; http://www.fseitz.de/
Anwendungen für Ihr Internet und Intranet
Tel: 04103/180301; Fax: -02; Industriestr. 31, 22880 Wedel