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

[Mertens Bram]

On 2006-11-16, Emiliano Heyns wrote:
> 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.

Inderdaad, maar dan krijg je bovenop de benodigde tijd voor het
dumpen/laden nog eens netwerk-belasting en bovendien duurt remote
dumpen/laden dikwijls nog langer ook.  Je kan natuurlijk nog betwisten
wat de waarde is van een on-disk backup maar ook dat is blijkbaar
moeilijk te verkopen aan (sommige) klanten.

> 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.

Dat is niet het enige dat me in de laatste 18 maanden versteld heeft
doen staan.  Ondanks het feit dat bepaalde systemen soms
levensnoodzakelijk zijn voor een bedrijf is het soms bijzonder slecht
gesteld qua backup-strategie, security, afhankelijkheid van bepaalde
leveranciers/personeelsleden, noem maar op.  We hebben klanten waar
talloze scripts lopen waarvan niemand weet dat ze lopen, waarom ze
lopen en of ze zonder fouten lopen.  In sommige gevallen worden de
logs nog steeds gemaild naar personeelsleden die al meerdere jaren
niet meer in het bedrijf werken...  Natuurlijk zie je ook het andere
uiterste: bedrijven waarbij iemand een officiële change-request moet
indienen om bij wijze van spreken een config-file in z'n eigen
home-dir aan te passen.  Maar dit wordt erg OT. :)

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

Klopt, maar wat ik bedoel is dat de oplossing die ik gedachten heb meer een
"procedure" of "framework" is dan een specifiek stuk code.  De CREATE
TABLE statements bij Oracle, MS SQL en MySQL zijn wel telkens
verschillend maar de problematiek die ik geschetst heb komt volgens
mij wel overal voor.

[...]

> > 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.

Die alzabo ziet er interessant uit, ga ik zeker eens mee spelen,
bedankt!

[...]
> > 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.

Daar begon ik al voor te vrezen, gek toch aangezien er toch voldoende
ogen op dit specifieke probleem moeten zijn.  Zijn er dan echt geen
fora/mailing lists o.i.d. waar dit soort algemene ontwikkel problemen
besproken kunnen worden?  Hoewel het niet strikt gerelateerd is aan de
ontwikkeling van DBMS verwachtte ik één of andere algemene SQL
development lijst te vinden bij bijvoorbeeld MySQL.

Alvast bedankt voor de reacties.

Bram

-- 
# Mertens Bram "M8ram"   <M8ram op linux.be>          Linux User #349737 #
# debian testing            kernel 2.6.17-2-686    i686    1024MB RAM #
# 13:52:55 up 20 days,  3:25,  4 users,  load average: 0.21, 0.08, 0.02 #