[MySQL] Structuur van een grote db wijzigen, inhoud bewaren

[Verwijderd]

Goededag,

Ik zit met het volgende probleem, ik moet voor een klant een site van de grond af aan opnieuw bouwen incl de database. Een van de prioriteiten is snelheid, dus ben ik de database maar wat gaan optimaliseren (zn vorige webmaster had meerdere joins in 1 query op tabellen met 10.000 records (wat trouwens totaal overbodig was als je de structuur wat aan zou passen)).
Ik stuit nu tegen het probleem dat ik de structuur van de database op enkele plaatsen wat moet wijzigen, het probleem echter is dat ik de informatie nog wel moet bewaren. Ik heb momenteel een dump van de db, maar dat is 99.000 regels ofzo, en daarin alles 'handmatig' (search & replace) aanpassen lijkt me geen goed plan.
Wat ik dus zoek is een manier om de INSERT INTO queries van de dump aan te passen aan de nieuwe structuur van mn tabellen. Aan de ene kant bent ik bang dat het echt slavenwerk wordt, maar aan de andere kant kan ik me niet voorstellen dat ik die eerste ben die tegen zon probleem oploopt. Er zijn hier vast en zeker oplossingen voor, iemand een suggestie ?

[Janoz]

In principe heb je al de data-access-code van je nieuwe systeem en de data-access-code van je oude systeem (afhankelijk van de gelaagdheid van je software ontwerp). Die stukken code kun je dus keurig in een conversie programma/script gebruiken om 1 malig alles om te zetten. Record uitlezen uit de ene tabel en weer invoeren in de andere volgens de nieuwe opmaak. Het is een eenmalig proces dus dat de hele conversie bv een uur duurt maakt natuurlijk weinig uit.

Meerdere joins in 1 query op tabellen met 10.000 records hoeft trouwens helemaal niet vreemd of inefficient te zijn. Ik ben wel benieuwd wat de oude situatie was en wat jij denkt dat nu een efficientere nieuwe situatie is.

[Verwijderd]

Hmm, dat is idd ook een optie, maar dat kost weer tijd, en ik heb niet zoveel tijd. Ik zal wel moeten

En wat bv inefficient is:
Er is nu een tabel wat messages linkt aan secties mbv id's.
Dus om te weten welk bericht in welke sectie hoort moet je vanuit message via koppeltabel naar sectietabel. Terwijl dat koppeltabel in dit geval net zo goed weggelaten kan worden. Want een message kan maar bij 1 sectie horen. Dus als je bv de sectionID in de message tabel zet ipv in een aparte tabel, scheelt dat je weer een flinke join. (of zit ik er nu helemaal naast, ben maar een amateur)
Zo zijn er nog een aantal kleine dingen

[Janoz]

Zolang een message maar bij 1 section hoort dan is de koppel tabel inderdaad overbodig. Die extra join is echter niet per definitie de bottleneck. Het zou ook heel goed kunnen zijn dat de indices niet goed staan.

Maar voor je oorspronkelijke probleem lijkt het me toch de kortste klap waneer je gewoon een conversiescript schrijft dat 1x alles bij langs gaat en omzet naar de nieuwe structuur. Je zou dit kunnen doen door records uit te lezen en weer te inserten, maar als de veranderingen kleiner zijn dan zou je ook inplace de boel aan kunnen passen. In je gegeven voorbeeld zou je een sectionId kunnen toevoegen en vervolgens een script schrijven dat die sectionId vult mbv de gegevens in de koppeltabel en heb je je nieuwe structuur klaar.

[Gomez12]

Verwijderd schreef op dinsdag 08 november 2005 @ 21:59:
Hmm, dat is idd ook een optie, maar dat kost weer tijd, en ik heb niet zoveel tijd. Ik zal wel moeten

En wat bv inefficient is:
Er is nu een tabel wat messages linkt aan secties mbv id's.
Dus om te weten welk bericht in welke sectie hoort moet je vanuit message via koppeltabel naar sectietabel. Terwijl dat koppeltabel in dit geval net zo goed weggelaten kan worden. Want een message kan maar bij 1 sectie horen. Dus als je bv de sectionID in de message tabel zet ipv in een aparte tabel, scheelt dat je weer een flinke join. (of zit ik er nu helemaal naast, ben maar een amateur)
Zo zijn er nog een aantal kleine dingen

Deze join is misschien op dit moment niet echt zinnig, maar kost volgens mij weinig extra resources mits je indexes goed staan. En als je later ooit nog eens iets als schaduwtopics ( dus topic in normale sectie en in admin sectie om te kunnen blijven controleren ) / aliasen wilt hebben, dat je dan later ooit nog eens een andere oplossing mag gaan verzinnen ( met koppeltabellen ofzo ).

Op dit moment ben je flexibel tegenover een beetje performance loss ( kies ik in 90% van de progs die ik bouw voor, tegenwoordig heeft bijna iedereen processortkracht over ). Maar met deze performance loss krijg je later bijna geen performance loos als je van je flexibiliteit gebruik gaat maken tegenover een uitgewerkt ( in assembly geprogd ) 100% performende applicatie waar als je later een functie aan wilt toevoegen iedereen het merkt alszijnde 5% performance loss.

Btw ga pas echt 100% voor performance als je er problemen mee krijgt. Die niet op een andere manier op te lossen zijn.

Maar ontopic, bouw gewoon een paar conversie scriptjes / sql-queries en bouw in een test-omgeving je nieuwe omgeving op. Voor test kan je Gewoon mbv conversie sql-queries ( en deze mogen imho vrij smerig zijn ) de data overzetten, aan de klant tonen en dan op een gegeven moment met de klant een datum/tijd afspreken dat de site even down gaat dan en je conversie kan draaien.

[Verwijderd]

Ik zou niet je oude data dumpe maar twee nieuwe databases aanmaken, 1 met de oude en 1 met de nieuwe structuur. Vul de 'oude' database met de oude data en ga dan een conversiescript bouwen en testen op basis hiervan. NB: gebruik daar dus niet de live db voor.

Ga de data stukje voor stukje over te zetten door SELECT queries op de oude database te doen, om deze data vervolgens om te zetten in INSERT queries in de nieuwe database. Doe dit in een geautomatiseerd script, zodat je de handelingen precies kan reproduceren. Als je script klaar is, kan je het toepassen op het ogenblik van conversie, zodat het 'live' systeem slechts zeer kort offline hoeft te zijn tijdens het uitrollen van de nieuwe versie, en je toch zeker weet dat alle data goed wordt overgenomen in het nieuwe systeem.

Bedenk goed: gegevens zijn waardevol, dus daar moet je heel zorgvuldig mee omgaan. Neem dus goed de tijd hiervoor.

Succes

[Verwijderd]

Iedereen bedankt, ik ga inderdaag gewoon met selects en inserts alles overzetten. Wat ik nameljik van plan was om de sql dump zelf aan te passen en dat te uploaden. Maar zo tabel voor tabel gaat beter. En sommige tabellen hoeven niet eens gewijzigd te worden

Thnx

[DaCoTa]

Dit soort database schema wijzigingen doen wij altijd dmv een update script. Dus de tabellen wijzigen op een gevulde database. In 9 van de 10 gevallen kan dat met 'domme' SQL scripts, bestaande uit ALTER TABLE statements enzo. In een enkel geval is er meer logica nodig voor de omzetting, en dan wordt de mutatie aangestuurd door een eenmalig te draaien softwaremodule. Dit gaat dan 3 fases van testen door (lokale ontwikkelomgeving, in house testomgeving, acceptatieomgeving met een zeer recente mirror van de productieomgeving) voor het op de live database uitgevoerd wordt. Op deze manier zijn alle wijzigingen (we ontwikkelen een groeiend systeem dat al geruime tijd live draait) met minimale downtime door te voeren.

M.i. is het compleet migreren van de data van een oud naar een nieuw schema veel foutgevoeliger, als je in dezelfde database werkt, krijg je meteen klappen als er ergens een constraint gebroken wordt.

[ Voor 6% gewijzigd door DaCoTa op 09-11-2005 16:09 ]