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

[Mertens Bram]

On 2006-11-16, Emiliano Heyns wrote:
> Huub Reuver wrote:
> > On Wed, Nov 15, 2006 at 04:10:18PM +0100, Mertens Bram wrote:
> >
> >> Dit zijn de vragen die ik me stel en de problemen die ik vaststel
> >> bij
> >> de ontwikkeling van de database bij het bedrijf waarvoor ik werk.
> >>
> >> Hoe kan je van ??n set scripts zowel een "initi?le installatie" als
> >> een upgrade opleveren?  M.a.w. hoe genereer je SQL patches?
> 
> Niet. Het in-situ wijzigen van de database structuur is te fragiel;
> zeker bij MySQL; dat geen transacties over de Data Definition Language
> (CREATE, ALTER, etc) toestaat. Je moet er dan maar van uit gaan dat
> het allemaal goed gaat, en als die aanname voor een bepaalde gebruiker
> niet klopt dan is het spul stuk. De veilige manier is het creeren van
> een nieuwe database, en de data van de oude overpompen. Bij dat
> overpompen kan je de evt. scchema wijzigingen meenemen. Als een 2e
> MySQL database teveel van het goede is zou je kunnen kijken of je de
> data tijdelijk kan overslaan naar een backup formaat (tekst, xml,
> sqlite), de bestaande database leegmaken, en opnieuw vullen vanuit de
> backup, of alle tabellen prefixen, en die 2 "namespaces" gebruiken
> voor de overslag.

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 dit niet ideaal is is zeker maar niet alle bedrijven
hebben de middelen om dit soort problemen echt structureel op te
lossen.
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?)
Ik hoop eigenlijk een oplossing te vinden die niet DB-specifiek is,
hoewel mijn onmiddelijke zorg MySQL betreft.

> Hoe dan ook, je bewaart de volledige "oude" data totdat de gebruiker
> heeft kunnen vaststellen dat alles werkt zodat hij op zijn initiatief
> de oude data kan (laten) verwijderen.

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.

> > Houdt de data en de programma's aub gescheiden.
> 
> Als je de data en de programmas gescheiden houdt heeft de data ook
> niet veel zin.

Huub: verwees je hier naar het voorbeeld dat ik aanhaalde over SQL
statements in de PHP scripts?  Dat verwonderde me inderdaad, daarom
vermelde ik het ook.

> > Volgens mij spreek je met programma's en scripts van updates en
> > patches
> > en bij databases van transacties. Met "SQL patches" bedoel je
> > daarmee
> > "SQL queries waarmee de structuur van de database veranderd wordt"?
> 
> Ik vindt patches daar helemaal niet zo'n gek woord (al zou ik het zelf
> dus niet doen).

Met "SQL patches" bedoel ik inderdaad queries om de structuur aan te
passen.  Het is een techniek (en benaming) die courant toegepast wordt
bij de firma waarvoor ik werk.  Maar dat is dan ook weer de reden
waarom ik een alternatief zoek.  Ik heb al teveel problemen meegemaakt
met deze aanpak en ik wil dat vermijden bij iets dat ik zelf volledig
in de hand heb.

> > Hoe doe je dat handmatig?
> > Je maakt een query om de structuur op te vragen, je kijkt wat het
> > antwoord
> > is en wat je verwacht en je wijzigt de structuur (of niet)...

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.

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

> >> Wat doe je als je meerdere versies moet/wil ondersteunen en je
> >> ontdekt
> >> een bug in een oude versie?  Hoe zorg je er dan voor dat deze bug
> >> in
> >> alle versie verbeterd wordt zonder dat de correctie later (bij het
> >> upgraden naar een recentere versie) opnieuw uitgevoerd wordt?
> >>
> >> Waar kan ik "do's and dont's" vinden over het ontwikkelen van DB's?
> 
> Ontwikkelen van een database schema is het vakgebied van de
> datamodellering. Daarnaast wil je een "optimaal" design vanuit de pure
> datamodellering vaak nog optimaliseren (structuur wijzigingen,
> denormalisatie, indexes) voor o.a. performance; dit is het vakgebied
> van de DBA. Beide vakgebieden zijn niet met een weekendje lezen in te
> halen, maar ik heb gehoord dat "Database Development for Dummies" erg
> behulpzaam kan zijn. De titel is niet denigrerend bedoeld, de Dummies
> reeks zijn prima boeken.

Bedankt, dat boek ga ik zeker eens opzoeken.  Ik ben bekend met de
"for dummies" reeks, ik heb nog ergens een "Red Hat Linux 7.3 for
dummies" liggen.
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.

> > Een "bug" in de oude versie slaat op de database of op de PHP-code?
> > Ben je bekend met subversion (ik zal je niet aanraden met cvs te
> > gaan 
> > werken).

Met een "bug" bedoelde ik hier een probleem met de DB structuur.  Maar
eigenlijk ook nieuwe ontwikkelingen die een DB-wijzingen vereisen.
Het is mijn bedoeling om eerst de "core" functionaliteit te
implementeren (zowel qua PHP als DB structuur) en later beide uit te
breiden.  Ik zou dan later op een eenvoudige manier zowel de laatste
versie willen kunnen installeren als een oudere versie upgraden naar
een hogere versie.  In mij "wildste fantasiën" (bij wijze van spreken
dan) zou ik meteen van versie 2 naar versie 6 kunnen zonder de
individuele upgrades te moeten uitvoeren.

> Dat is leuk voor de ontwikkeling, maar je hebt ook een manier nodig om
> die fix veilig operationeel uit te rollen, en dat is waar Bram het zo
> te zien over heeft ("uitgevoerd wordt"). Als je per se in-situ wilt
> wijzigen is de tabel structuur bij de meeste databases (MySQL incluis)
> op te vragen. Je kan op basis daarvan besluiten of de tabel structuur
> gewijzigd moet worden. Zelf vindt ik het altijd makkelijk om een view
> of tabel op te nemen die simpelweg identificerende informatie
> oplevert, zodat ik weet welke versie DB ik heb en ik het niet aan de
> structuur hoef af te leiden.

In gebruik subversion om de code te beheren, voor PHP scripts kan je
da inderdaad patches genereren om zelfs mijn "wilde fantasie" te
realiseren.  Aan de andere kant is het net voor die PHP scripts niet
nodig, daar zit geen data tussen dus daar gooi je gewoon de oude
versie weg en zet je de nieuwste versie in de plaats.
Voor SQL statements helpt subversion echter weinig, een diff -u of een
svn diff leveren niet bepaald geldige SQL op.  Laat staan SQL die
controles bevat.

Toen ik op m'n werk dit probleem vast stelde heb ik volgende suggestie
gedaan: het toevoegen van een zogenaamde "SysVersionHist" tabel waarin
alle uitgevoerde patches bijgehouden worden.  Bij een upgrade is het
dan gewoon kwestie van deze tabel uit te lezen en al dan niet de
"patch" (de SQL statements dus) uit te voeren.  Deze suggestie is
echter slechts gedeeltelijk geïmplementeerd: we houden nu het nummer
bij van de laatste patch voor een bepaalde versie.  Daarnaast spreekt
men over patches en handovers: patches zijn eigenlijk bugfixes (van de
DB), terwijl handovers nieuwe functionaliteit bevatten.  Bij patches
wordt *manueel* een stored procedure toegevoegd die controleert of het
patchnummer in deze SysVersionHist tabel exact 1 nummer lager is dan
de nummer van die patch, zoniet wordt een foutmelding gegeven.

Persoonlijk ben ik er niet van overtuigd dat dit systeem goed werkt
maar ik mis inderdaad de kennis/ervaring van een DBA.  Ik hoop dat
deze discussie en/of eventuele tips/suggesties die ik krijg me kunnen
helpen om wel een beter alternatief uit te werken.

De view die Emiliano voorstelt lijkt me al een betere variant te zijn
aangezien je niet kan vergeten de versietabel te updaten bij het
uitvoeren van een patch.  Ook als er iemand manueel wijzigingen
uitvoert op de DB zal dit wel in een dergelijke view tot uiting komen
terwijl ik uit ervaring weet dat onze SysVersionHist tabel daar
uiteraard geen hulp biedt.  Persoonlijk begrijp ik niet dat zoiets kan
gebeuren op productie databanken maar jammer genoeg gebeurt het dus
wel degelijk.

Emiliano: kun je me (off-list) eens een voorbeeldje toesturen van zo'n
view?  Dat wil ik wel eens wat beter bestuderen.

Alvast bedankt voor de tips.

Bram

-- 
# Mertens Bram "M8ram"   <M8ram op linux.be>          Linux User #349737 #
# debian testing            kernel 2.6.17-2-686    i686    1024MB RAM #
# 11:36:10 up 20 days,  1:08,  3 users,  load average: 0.00, 0.02, 0.00 #