[linux] Re: ontwikkelen van databases [beetje OT?]

[Emiliano Heyns]

On Thu, Nov 16, 2006 at 12:24:08PM +0100, Mertens Bram wrote:

> Voor de applicatie die ik nu wil bouwen zal dat waarschijnlijk geen
> probleem zijn.  Maar ik stel de vraag hier omdat ik hetzelfde probleem
> zie bij de firma waar ik voor werk en daar spreken we over enkele
> tientallen Gigabytes aan data.  Bij verschillende van onze klanten is
> de data op de DB-server dupliceren gewoon niet haalbaar qua
> disk-space.

Dat zou ook niet nodig moeten zijn; je kan een remote
backup-en-restore procedure uitvoeren, of de dump uitvoeren naar een
remote database, die bewerken op een werkstation met genoeg ruimte, en
hem dan terugzetten.

Hoe dan ook verbaast het me dat een klant met enkele tientallen GBs
aan data die wil riskeren voor een geen-weg-terug upgrade procedure
met mogelijk subtiele fouten die laat worden ontdekt.

Bij MySQL kan je tabellen renamen, dus als je de volgorde heel
voorzichtig (ivm constraints) kiest dan kan je misschien de tabel
overslag stuk-voor-stuk doen (nieuwe tabel, overslaan, oude
tabel droppen, nieuwe renamen). Kan niet voor elk schema, en lijkt me
een monniken werk.

> Ook het dumpen van de data en opnieuw inlezen zou een probleem vormen
> bij verschillende klanten: het dumpen of inladen duurt soms enkele
> uren.  (Het gaat hier dan telkens om Oracle DB's, MySQL is misschien
> performanter?)

Dat hangt af van de structuur van de dataset.

> Ik hoop eigenlijk een oplossing te vinden die niet DB-specifiek is,
> hoewel mijn onmiddelijke zorg MySQL betreft.

Ook DDL is DB-specifiek.

> Hoewel ik inzie dat dit duidelijke voordelen heeft vraag ik me af of
> alle klanten dit willen inzien en kunnen toepassen.  "Disk space is
> cheap" maar als ik naar de situatie bij enkele kalnten kijk is die
> "cheap" toch nog dikwijls te duur.

Dan zou ik (bij wijze van CYA) eerder een forse USB disk aan de server
hangen voor de duur van de migratie. Maar goed, 6 uur downtime is
natuurlijk niet onaanzienlijk.

> De structuur opvragen geeft uiteraard de "juiste" stand van zaken.
> Het probleem dat ik hierbij heb is dat je een dergelijke controle voor
> elke wijziging manueel moet inbouwen.  Dat lijkt me toch weinig
> effici?nt.

Er zijn commerciele tools voor (zoals http://www.red-gate.com/) die een DDL
diff kunnen maken. Ik ken in de FLOSS sfeer alleen http://www.alzabo.org/,
maar ik gebruik het zelf niet.

> > > Erg informatief kan phpmyadmin zijn. Deze laat bij transacties de
> > > gebruikte
> > > SQL syntax zien.
> > 
> > En zoals gezegd, DDL valt buiten de transactie scope bij MySQL.
> 
> Ik ken phpmyadmin en gebruik het regelmatig maar ik hou toch meer van
> de CLI, hoe minder ik een muis moet gebruiken hoe liever ik het heb en
> hoe minder last ik heb van nek en rug... (Whiplash e.d.)

De CLI en phpmyadmin maken hier geen verschil. DDL wordt door MySQL
buiten de transactie context om uitgevoerd, dus valt er niets te
tonen. Elke DDL is in MySQL direct 'committed' als het ware; een
rollback heeft er geen effect op.

> Ik ben me er ook van bewust dat dit een uitgebreide problematiek is en
> dat ik (jammer genoeg) niet meteen specialist ter zake kan worden.
> Daarentegen ging ik er van uit (maar ik ben wel eens na?ef) dat
> aangezien er talloze applicaties gebruik maken van databanken dat deze
> problematiek toch al uitgebreid behandeld (en opgelost) zou zijn.

De meeste applicaties in de FLOSS sfeer gebruiken hand-geschreven
delta DDL scripts die er maar op vertrouwen dat alles goed gaat.

-- 
Emiliano