RE: [Perfparse-users] Help Needed

[Sand P. <Phi...@sy...>]

> When the current versions are stable, we will be looking to=20
> convert the binary table in the PP database.  This will=20
> probably take our product up to version 1.0.  I need some=20
> advise from users about the best method.
>=20
> The advantages of the change are:
> - A range for the Warn and Crit values, rather than just a=20
> single value.
> - Smaller storage space needed for same data.
> - Faster access to data, bigger graphs possible.
> - A scalable solution where new information can be added easily.
Sounds good, how will the tow tables look like?

> Option 1.
> ---------
>=20
> Copy the old table to new tables and delete old table.
>=20
> Pro:
>    Fast.
>    Easy to program & test =3D> low in bugs.
> Con:
>    Will double size of MySQL database during conversion.
>      This space is very hard to recover.

I think I would prefere that one. We're storing the performance Data for
long time (estimated 3years deletion policy)
So over long terms our db will grow anyway :) Userers who store Data for
shortterms could easyly create a new Database for perfparse "1.0" and
delete the old Database when it's not needed anymore...

> Option 2.
> ---------
>=20
> Copy all data to an external text files.  Delete old table. =20
> Copy back to new tables.  Delete text files.
>=20
> Pro:
>    Fast.
>    No increase in MySQL table space.
> Con:
>    Harder to program & test =3D> bugs possible.
>    Text file size is far larger than table, which is binary.
>    Need database size again in temporary storage for text=20
> dump of table.
After messing around with mysqldum(b)p this week, i think it's to risky
to do it that way...but if you can make sure, that no data will be lost
during that progress, it would be nice, too. But I think you should
better use this time to put in some other features (like multiple
metrics in one graph :) )


> Option 3.
> ---------
>=20
> Copy over a line at a time and delete line from old table.
>=20
> Pro:
>    No extra space needed.  No increase in MySQL table space.
>    Easy to program & test =3D> low in bugs.
> Con:
>    Deleting line by line is slow.  Conversion may take several weeks.
I think thats no alternative...as you said, that would last a few weeks
for a few million lines...
Before doing that, I personally would start with a new database ...

> Finally, a plee to anybody who knows some MySQL and a little=20
> 'c'.  Can you spare some time to help develop and/or test a=20
> conversion program.=20
> You time will be welcome, and you will be credited as a developer.
I now a little sql and can read a little c ... But we're just in a ADS
Migration Process here, so I don't have very much time...but when I find
some time here, i'll try to help...But don't schedule me :)


************************************************

sycor plastics - die neue Branchenl=F6sung f=FCr die Kunststoffindustrie

www.sycor-plastics.de

************************************************




Diese E-Mail ist vertraulich und kann dar=FCber hinaus pers=F6nliche Info=
rmationen beinhalten. Wenn Sie nicht der bestimmungsgem=E4=DFe Empf=E4nge=
r sind, l=F6schen Sie bitte die E-Mail und deren Anh=E4nge sofort und ben=
achrichtigen Sie uns dar=FCber. Die Firma sycor willigt in keine Vertr=E4=
ge oder vertragliche Verpflichtungen ein oder =FCbermittelt rechtsverbind=
liche Angebote, die in Form von E-Mail versandt werden, sofern dies nicht=
 ausdr=FCcklich in schriftlicher Form zwischen den Parteien vereinbart wu=
rde.

This e-mail is confidential and may contain personal and/or privileged in=
formation. If you are not the intended recipient please delete this e-mai=
l and all attachments immediately and inform us. The company sycor does n=
ot agree with contracts or contract obligations sent by e-mail, neither d=
o we transmit legally binding offers by e-mail, unless this is not expres=
sly agreed upon between the parties and documented in written form.