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

[Emiliano Heyns]

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.

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.

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

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

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

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

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

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.

Emile