MySQL geen echte database?

[Verwijderd]

Hallo iedereen

Ik wil graag MySQL server installeren op een linux server in een productieomgeving.
Nu lees ik hier dat sommige mensen MySQL niet echt een super-database vinden:
nieuws: Oracle gaat zich op kleinere bedrijven richten

Wat is er mis met MySQL?

[VisionMaster]

Geen idee
Op verschillende instituten draait MySQL vol op en met mysqld's.
Datasets varieren van 1 MB tot 84 GB en nog snel ook
(ik weet dat het KNMI een flinke heeft die in de buurt van terabytes bij moet houden ivm Grid Computing)

Ik moet een kleine database opzetten in een productie omgeving die heel snel heel veel logs en checks moet bij houden. (100+ transactie)/s en hebben daar juist MySQL met een leuke zwik tabellen voor opgezet.

4.0.13 is wat we gebruiken (ik hoop te upgraden naar x.x.14)

[ Voor 69% gewijzigd door VisionMaster op 21-10-2003 23:52 ]

[Erkens]

http://vulcanus.its.tudelft.nl/~acm/got/antimysql.php

_{uit ACM's sig}

[Verwijderd]

MySQL mist bepaalde functionaliteit die volgens vele toch bij een database behoren. Zoals je zelf al aangeeft met de link:

Zo ondersteund(e) MySQL geen subqueries, stored procedures, geen triggers of foreign key constraints en zonder InnoDB geen table locking en wat redelijk belangrijk is in een bedrijfsomgeving.

Bovenstaande punten zijn voor bedrijven toch redelijk tot zeer belangrijk

[gorgi_19]

Zie de sig van ACM

* gorgi_19 kijkt boos naar Erkens.

[ Voor 23% gewijzigd door gorgi_19 op 21-10-2003 23:54 ]

[VisionMaster]

Verwijderd schreef op 21 October 2003 @ 23:52:
MySQL mist bepaalde functionaliteit die volgens vele toch bij een database behoren. Zoals je zelf al aangeeft met de link:

Zo ondersteund(e) MySQL geen subqueries, stored procedures, geen triggers of foreign key constraints en zonder InnoDB geen table locking en wat redelijk belangrijk is in een bedrijfsomgeving.

Bovenstaande punten zijn voor bedrijven toch redelijk tot zeer belangrijk

nofi, maar er zitten toch wel een hoop leuke nieuwe features in MySQL sinds v4.x die je hier noemt als niet aanwezig. 2 jaar terug in gebakken en 1 jaar terug stabiel foreign key constraint gebruik en table locking (per user).

[Verwijderd]

Maar is MySQL af te raden als het gaat om snelheid, gegevensbescherming, stabiliteit en functionaliteit?

[CaineTanathos]

als je het ietjes beter had gelezen , wist je dat mysql in vergelijking met Oracle niet echt veel voorsteld qua features, maar dan enkele belangrijke feature al in beta fase zijn (sub queries, Stored Procedures. Maar dat wil niet zeggen dat mysql een slechte database is. Integendeel het is een zeer snelle database, die eerst speciaal voor dynamisch websites werd ontwikkeld.

ProstGreSql is trager dan Mysql maar kan iets beter om met grotere databases en ondersteund ook al Subqueries, ...

btw geen foreign key ondersteunin, is opzich niet het ergste, alleen moet je dan in het programma doen (checken op dubbels,etc)

[ Voor 13% gewijzigd door CaineTanathos op 21-10-2003 23:57 ]

[gorgi_19]

Verwijderd schreef op 21 oktober 2003 @ 23:54:
Maar is MySQL af te raden als het gaat om snelheid, gegevensbescherming, stabiliteit en functionaliteit?

Andere vraag: Heb je al die snelheid en gegevensbescherming nodig? Je kan ook zeggen: "Ik neem Oracle", maar dat is voor een hoop gevallen gewoon simpelweg overkill.

Waarom wil je per se SP's hebben? Is het nodig?

[ Voor 8% gewijzigd door gorgi_19 op 21-10-2003 23:56 ]

[Verwijderd]

Oracle is duur

[Beaves]

Pak dan PostgreSQL, net zo gratis als MySQL maar in tegenstelling tot MySQL wel alle belangrijke mogelijkheden zoals rollback.

[gorgi_19]

Verwijderd schreef op 21 oktober 2003 @ 23:59:
Oracle is duur

Erhm.. ja? Maar biedt een stuk betere performance, gegevensbescherming, support, etc. dan MySQL. Vergelijk het om op een Dual Xeon met 2 GB geheugen met notepad te gaan werken; een beetje overkill.

Oftewel: Wat heb je nodig? Een paar simpele selectquerys en MySQL is voldoende.

Verder: Wat is duur? Duur is in dit geval een relatief begrip; Oracle kan, alles bij elkaar genomen, goedkoper zijn dan MySQL.

* gorgi_19 mompelt iets over right tool for the right job.

[ Voor 36% gewijzigd door gorgi_19 op 22-10-2003 00:04 ]

[VisionMaster]

gorgi_19 schreef op 22 October 2003 @ 00:00:
[...]

Verder: Wat is duur? Duur is in dit geval een relatief begrip; Oracle kan, alles bij elkaar genomen, goedkoper zijn dan MySQL.

* gorgi_19 mompelt iets over right tool for the right job.

* VisionMaster is het 100% eens met gorgi_19
Ook Postgres heeft zijn nadelen. Fout afhandelingen in Postgres zijn erg rot. MySql is lekker simpel en toch vaak the right tool. Maar als het erg Hot 2 Handle wordt ga ik ook liever naar een Oracle als het er ECHT op aan moet komen en je flink veel bedrijfskritische onderdelen heb afhangen van deze database.

[raptorix]

VisionMaster schreef op 21 oktober 2003 @ 23:54:
[...]


nofi, maar er zitten toch wel een hoop leuke nieuwe features in MySQL sinds v4.x die je hier noemt als niet aanwezig. 2 jaar terug in gebakken en 1 jaar terug stabiel foreign key constraint gebruik en table locking (per user).

No offence maar een database die bij aanvang al niet eens gebruik maakt van foreign key constraints kan je toch niet echt serieus nemen. Ik zeg niet dat Mysql ongeschikt is, maar ik zou Mysql zeker niet gaan toepassen in omgevingen waar je liever geen data kwijt raakt, dan wel je database een dag uit lucht mag zijn. Voor zaken als Forums, Statistieken, etc is het prima geschikt.

[curry684]

Wat beroemde citaten:
"MySQL is a sorry excuse for a flat filesystem with indexes"
"MySQL is what PHP users use for everything... why create a file when you can use a MySQL database?"

MySQL is gewoon een brak excuus voor een database, dat toevallig erg snel veel common werk redelijk stabiel kan afhandelen. Complexe enterpriselevel databases kun je wel vergeten bij gebrek aan views, complexe joins and so on.

Zie ook de al gegeven link uit ACM's sig.

Laat het duidelijk zijn: MySQL is echt de beste keuze voor 90% van de PHP-sites, en voor forums en andere 'veel data weinig evaluatie'-projecten. Zodra je 24/7 fabrieken wil gaan aansturen zul je echter aan Oracle of MSSQL moeten geloven.

[LauPro]

MySQL is voor velen - en ook voor mij - een uitkomt als je het vergelijkt met bijv. Access: Access gaat over zo'n nek bij grote hoeveelheden data, limiet van 2 GB per bestand en daarnaast is het ook nog is behoorlijk traag ivm andere databases. Maar dat komt omdat Access vaak verkeerd wordt gebruikt en dan is de stap naar MySQL snel gemaakt. Je hebt vaak helemaal niet zoveel functies nodig als die van MSSQL (waar je nog voor betalen moet ook) en dan is een MySQL-database even snel gemaakt als 1 van Access.

Ik heb zelf nog geen slechte ervaringen met MySQL, echter lijkt me een goede backup van levensbelang. Zolang je dus gewoon goede, stabiele apparatuur gebruikt is MySQL even stabiel als MSSQL schat ik zo. En volgens mij wordt MySQL nog wel is weggestopt op een oud bakkie waardoor het in de praktijk misschien niet helemaal werkt zoals het moet.

Maar bijv. dus het bevolkingsregister draaien op MySQL, tja dat gaat denk ik niet lukken .

@curry684: Ik heb dat stukje wel is eerder gelezen maar ik zie er nou niet bepaald fouten in staan van zo'n groot kabliber waardoor het niet meer geschikt zou zijn voor een productieomgeving. Ok, dingen als Check die ontbreken zijn even lastig maar aan de andere kant kan je dat toch zo omzetten zodra die functie erin zit? Ik heb er verder geen last van, het is niet mooi idd.

Ik zie er zo nog wel wat argumenten tussenstaan waar ik zelf mee kan leven, en daar kan ook in een productieomgeving mee worden geleefd. Daarnaast ben ik van mening dat een database voor DATA is en geen politieagent moet zijn. Al die checks zijn mooi, alleen die moeten worden gechecked voor invoer. Als je die checks voor de invoer al niet doet ben je imo al prutserig bezig.

En dan bijvoorbeeld dit punt: '8. No ipaddress or geometrical datatypes'. Het is een illusie dat een IPv4 adres (ja voorlopig hebben we IPv4) gekoppeld is aan een PERSOON. Dat vergeten nog veel mensen volgens mij. Pas bij IPv6 maken we een kleine kans dat we aan de hand van een IP-adres een persoon kunnen identificeren (al kan dat niet wereldwijd ivm de routeringstabellen). Dan zou ik graag willen weten waarom je zo'n veld nodig hebt? Filteren op host-IP-adressen is imo de meest ranzige mannier van filteren (tenzij je in een LAN bezig bent met private adressing). Moet die zelfde ranzige mannier van filteren dan mogelijk worden gemaakt in de database? En al zou het zijn voor statistieken met allerlei filters oid, dan schiet MySQL zichzelf voorbij als database imo.

[ Voor 45% gewijzigd door LauPro op 22-10-2003 01:06 ]

[VisionMaster]

raptorix schreef op 22 October 2003 @ 00:36:
[...]

No offence maar een database die bij aanvang al niet eens gebruik maakt van foreign key constraints kan je toch niet echt serieus nemen. Ik zeg niet dat Mysql ongeschikt is, maar ik zou Mysql zeker niet gaan toepassen in omgevingen waar je liever geen data kwijt raakt, dan wel je database een dag uit lucht mag zijn. Voor zaken als Forums, Statistieken, etc is het prima geschikt.

Ik noem dat ontwikkeling. Misschien dat ik dat een beetje beter begrijp vooral omdat ik zelf nog al in de programmeer wereld rond hang. Ik zie potentie in MySQL. Het is een groeiende ontwikkeling. En niet *BAM* hier is het product.
Ik vind dit meerwaarde hebben.
Uiteraard ... bevolkingsregisters vertrouw ik ook liever toe aan Oracle achtige databases. evenals mijn Energie rekening
De tijd voor MySQL komt nog wel. Die dudes hebben een pareltje van een product neer gezet. Linux was ook er ook niet in 1 dag zoals het er nu bij staat.

Ik vind dus het argument dat Foreign keys vanaf het begin niet ondersteunt wordt een beetje een respect lozeuiting voor het initiatief dat MySQL is. Ooit komen er views en alle andere dingen die Oracle vandaag de dag al heeft. Maar dan met een iets andere licentie

[Beaves]

LauPro schreef op 22 October 2003 @ 00:48:
Ik heb zelf nog geen slechte ervaringen met MySQL, echter lijkt me een goede backup van levensbelang. Zolang je dus gewoon goede, stabiele apparatuur gebruikt is MySQL even stabiel als MSSQL schat ik zo. En volgens mij wordt MySQL nog wel is weggestopt op een oud bakkie waardoor het in de praktijk misschien niet helemaal werkt zoals het moet.

Stabiele apparatuur is natuurlijk vereist, maar dan nog heb je met MySQL geen absolute zekerheid door het ontbreken van rollback features die de andere zoals PostgreSQL, Oracle en MS SQL wel hebben.

Wat als je een query uitvoert die de database verneukt? Dan kan je dus de meest recente backup terug gaan zetten, bij de andere kan je rollback feature's gaan gebruiken (mist je geen "commit" hebt gedaan).

[LauPro]

Beaves schreef op 22 oktober 2003 @ 01:02:
[...]
Wat als je een query uitvoert die de database verneukt? Dan kan je dus de meest recente backup terug gaan zetten, bij de andere kan je rollback feature's gaan gebruiken (mist je geen "commit" hebt gedaan).

Jij bent dus aan het 'testen' met allemaal malafide query's op een productieserver?

[Beaves]

LauPro schreef op 22 oktober 2003 @ 01:09:
[...]
Jij bent dus aan het 'testen' met allemaal malafide query's op een productieserver?

Ehm, nee, maar waar gewerkt wordt, worden fouten gemaakt. Als je een complex programma hebt (CRM bijvoorbeeld) die gebruik maakt van een database is een foutje snel gemaakt. Dan is een rollback wel handig.

En wat dacht je van crashes, een server kan altijd vastlopen door onvoorziene omstandigheden zoals een UPS die ineens besluit om alles uit te zetten zonder stop commando. Ook dan zijn al die extra beveiligingen handig.

[Rataplan]

LauPro schreef op 22 oktober 2003 @ 01:09:
[...]
Jij bent dus aan het 'testen' met allemaal malafide query's op een productieserver?

Op een productieserver moeten vaak veel tabellen aan de hand van één oorzaak worden geupdate. Als 1 van die queries misloopt (de voorraad was toch op want een andere user probeert tegelijkertijd hetzelfde artikel te verkopen), moet je al die andere queries ongedaan maken.

Dat kan je zelf oplossen met tegengestelde queries die ook weer fout kunnen gaan etcetera - of je gebruikt een database met een commit/rollback-systeem. Honderden uren extra ontwikkeltijd, kan dat schelen. En dan heb ik het nog niet over de voordelen van views in een OOP-omgeving.

Maar mysql is voor acht van de tien dingen die ik doe the right tool for the right job.

*leest*

En dat van power failure enzo is ook waar

[LauPro]

Dat begrijp ik, maar een bedrijf heeft er natuurlijk niet veel aan dat soort functies als die grotendeels alleen op de ontwikkeling zijn gericht (aangenomen dat zoiets 1 keer wordt ontwikkeld en dat het daarna werkt, iets dat volgens mij vaak het geval is).

Begrijp me niet verkeerd, over het algemeen ben ik nogal huiverig over Open Source programmatuur. Ik denk echter dat MySQL een van de betere Open Source producten is waarbij het ook zeker een kans maakt in productieomgevingen (en dan dus meer dan alleen websites). En dat het een aantal functies mist t.o.v. de concurrent (zo noem ik het dan even) is misschien jammerlijk echter niet zo fataal zodat het totaal niet geschikt is. En wellicht is die redundant voeding met 2 UPS'en wel de investering waard t.o.v. MSSQL?

Ik heb op de frontpage al gereageerd op je post, maar het is natuurlijk oneerlijk om MySQL af te rekenen op dingen die al opgelost zijn (bijv. subquery's). Want MySQL zit al bij versie 4 en niet bij versie 3.

[Rataplan]

Ik geloof niet dat dit tegen mij gericht was, maar toch:

LauPro schreef op 22 October 2003 @ 01:33:
(...) een bedrijf heeft er natuurlijk niet veel aan dat soort functies als die grotendeels alleen op de ontwikkeling zijn gericht (aangenomen dat zoiets 1 keer wordt ontwikkeld en dat het daarna werkt, iets dat volgens mij vaak het geval is).

Even flauw inkoppen: het is één keer ontwikkeld - en het heet transaction management

Het ligt er maar aan waar je je prioriteiten legt. MySQL heeft geen last van de overhead van transaction management, dus is het sneller. Bedrijfskritische informatie gaat altijd op een verifieerbare manier de database in; en daarbij is transaction management nou bijna onmisbaar. Als je invoer niet 100% reproduceerbaar hoeft te zijn (dit forum bijvoorbeeld) terwijl je een enorm volume tegen zo laag mogelijke kosten wil verwerken, is MySQL dus goedkoper (minder servers nodig, bijvoorbeeld). Als je wel 100% zeker wilt zijn heb je de keuze tussen paranoid locking (dan kan er maar 1 user tegelijk posten) en een foutcorrectie-mechanisme zoals commit/rollback. Ik kan je verzekeren dat de boekhouding van T.net niet in een multi-user environment op MySQL gedraaid wordt. Daarvoor heeft MySQL een paar te grote - fatale - tekortkomingen.

Dat opgeloste zaken als subqueries niet meer meegenomen mogen worden is natuurlijk een terechte opmerking. Dat van die views trouwens ook.

[ Voor 7% gewijzigd door Rataplan op 22-10-2003 01:56 ]

[MSalters]

LauPro schreef op 22 oktober 2003 @ 00:48:
En dan bijvoorbeeld dit punt: '8. No ipaddress or geometrical datatypes'. Het is een illusie dat een IPv4 adres (ja voorlopig hebben we IPv4) gekoppeld is aan een PERSOON. Dat vergeten nog veel mensen volgens mij. Pas bij IPv6 maken we een kleine kans dat we aan de hand van een IP-adres een persoon kunnen identificeren (al kan dat niet wereldwijd ivm de routeringstabellen). Dan zou ik graag willen weten waarom je zo'n veld nodig hebt? Filteren op host-IP-adressen is imo de meest ranzige mannier van filteren (tenzij je in een LAN bezig bent met private adressing). Moet die zelfde ranzige mannier van filteren dan mogelijk worden gemaakt in de database?

Er zijn mensen die een MySQL voor andere toepassingen dan fora gebruiken. Ik heb zelf wel eens aan een distributed project gwerkt, waar elke PC een bepaalde rol had. Zo'n PC haalde op basis van z'n 192.168.x.y IP adres z'n configuratie van de MySQL server. Het voordeel was dat je een vervangende PC gewoon een standaard ghost installatie kon geven, IP-adres instellen en klaar. Dat ghosten kon je al van te voren gedaan hebben, zodat je in 1 minuut een defecte PC kon vervangen. Wegens gebrek aan IP-type werd dit veld dus een string, met alle beheersissues van dien.

[VisionMaster]

Rataplan schreef op 22 October 2003 @ 01:53:
Ik geloof niet dat dit tegen mij gericht was, maar toch:

[...]
Even flauw inkoppen: het is één keer ontwikkeld - en het heet transaction management

Het ligt er maar aan waar je je prioriteiten legt. MySQL heeft geen last van de overhead van transaction management, dus is het sneller. Bedrijfskritische informatie gaat altijd op een verifieerbare manier de database in; en daarbij is transaction management nou bijna onmisbaar. Als je invoer niet 100% reproduceerbaar hoeft te zijn (dit forum bijvoorbeeld) terwijl je een enorm volume tegen zo laag mogelijke kosten wil verwerken, is MySQL dus goedkoper (minder servers nodig, bijvoorbeeld). Als je wel 100% zeker wilt zijn heb je de keuze tussen paranoid locking (dan kan er maar 1 user tegelijk posten) en een foutcorrectie-mechanisme zoals commit/rollback. Ik kan je verzekeren dat de boekhouding van T.net niet in een multi-user environment op MySQL gedraaid wordt. Daarvoor heeft MySQL een paar te grote - fatale - tekortkomingen.

Dat opgeloste zaken als subqueries niet meer meegenomen mogen worden is natuurlijk een terechte opmerking. Dat van die views trouwens ook.

Gezien het reilen en zeilen op T.net verbaasd het me niets als hun boekhouding outsourced is of via MySQL loopt. Maar goed ... dat terzijde.
Ik zie nog steeds niet in waarom je een beetje flaimed op MySQL. Er gebeuren wel interesantere dingen met MySQL. Het KNMI en ESA doet aardobserverend onderzoek. Ik weet dat in het gebied van Grid Computing gebruik gemaakt wordt van MySQL databases. Er leuk zou je zeggen, maar de data die van de sateliet komt is vrij duur en kostenintensief. Als MySQL niet een stabiele versie zou hebben en dus niet bedrijfscritisch kunnen werken hadden ze wel een duurdere DB genomen. (Dataset in de orde van een TB of wat).

[Rataplan]

VisionMaster schreef op 22 October 2003 @ 19:31:
Ik zie nog steeds niet in waarom je een beetje flaimed op MySQL. Er gebeuren wel interesantere dingen met MySQL. Het KNMI en ESA doet aardopserverend onderzoek. Ik weet dat in het gebied van Grid Computing gebruik gemaakt wordt van MySQL databases. Er leuk zou je zeggen, maar de data die van de sateliet komt is vrij duur en kostenintensief. Als MySQL niet een stabiele versie zou hebben en dus niet bedrijfscritisch kunnen werken hadden ze wel een duurdere DB genoemn. (Dataset in de orde van een TB of wat).

Ik flamen op MySQL? Waar in godesnaam? Het enige wat ik probeer duidelijk te maken is dat je voor complexe tablesets, die aangestuurd worden met samenhangende multiple queries, transaction management nodig hebt. Dat heeft MySQL niet aan boord, dus is het geen optie. Dat het geen professionele oplossing is hoor je mij niet beweren; dat het dus ook maar meteen met andere databases kan concurreren wél, want dat is lariekoek. MySQL heeft gewoon niet altijd de juiste features aan boord.

Ik heb liever een Porsche dan een vrachtwagen, maar als ik drie ton zand wil vervoeren is een Porsche een prutsoplossing. Hoe is dat flamen?

Dat KNMI en ESA voor het verzamelen van statistische data gebruik maken van MySQL is logisch; gewoon statische data in een database rammen is nou juist een van de sterke punten van dit product. Je moet alleen niet aan de hand van de database de database willen bijstellen; dan is MySQL dus *niet* geschikt. Het al dan niet bedrijfskritisch zijn wil niet zeggen dat MySQL zomaar kan uitvallen, maar dat MySQL moeilijk beheersbaar is als je een dynamische dataset beheert.

Lees gewoon het voorbeeld van de oprakende voorraad dat ik eerder gaf nog eens over. Denk aan tabellen klanthistorie, facturatie, pakbonnen, grootboek, subboek, omzet-per-verkoper, weet ik wat al niet, en twee dozijn queries. De laatste query gaat om 1 of andere reden de mist in: mag jij me vertellen hoe je dat elegant in MySQL kan oplossen.

[twiekert]

Rataplan schreef op 22 October 2003 @ 19:48:
[...]
Het enige wat ik probeer duidelijk te maken is dat je voor complexe tablesets, die aangestuurd worden met samenhangende multiple queries, transaction management nodig hebt. Dat heeft MySQL niet aan boord, dus is het geen optie.

Ik lees op de mysql site dat sinds de versie 4.0.14 transactions worden ondersteund.

http://www.mysql.com/doc/en/Transactional_Commands.html

Ondersteund mysql nu wel transactions (zoals oracle / msSQL dat doen) of niet

Of zijn de functies van mysql hierbij heel beperkt?

[VisionMaster]

Rataplan schreef op 22 October 2003 @ 19:48:
[...]
Intelligente BlaaT...
[...]

Ok Ya GoTha Point ...

[ Voor 83% gewijzigd door VisionMaster op 22-10-2003 23:50 ]

[VisionMaster]

twiekert schreef op 22 oktober 2003 @ 20:50:
[...]


Ik lees op de mysql site dat sinds de versie 4.0.14 transactions worden ondersteund.

http://www.mysql.com/doc/en/Transactional_Commands.html

Ondersteund mysql nu wel transactions (zoals oracle / msSQL dat doen) of niet

Of zijn de functies van mysql hierbij heel beperkt?

Het locking mechanisme is per database iets anders geimplementeerd. En ja moet toegeven dat multi-transactionele handelingen met MySQL zich nog totaal niet hebben bewezen en nog in de kinderschoenen staat.
Ik zal het over een tijdje eens gaan uitproberen Disclaiming: ik heb er wel voor gezorgt dat de database die heel veel te verwerken krijgt (multi-transactioneel) Veel moet doen, maar allemaal heeeeeel erg klein (speciaal zo ontworpen ivm de hoeveelheid transacties en een beetje ivm MySQL, just in case ).

offtopic:
k*t had beter effe edit kunnen doen ... sorry

[ Voor 4% gewijzigd door VisionMaster op 22-10-2003 23:55 ]

[Rataplan]

VisionMaster schreef op 22 oktober 2003 @ 23:54:
Het locking mechanisme is per database iets anders geimplementeerd. En ja moet toegeven dat multi-transactionele handelingen met MySQL zich nog totaal niet hebben bewezen en nog in de kinderschoenen staat.

Check, al moet ik toegeven dat ik toegeven dat ik me dit niet realiseerde toen ik m'n posts hierboven schreef. Met een jaartje zal dit wel redelijk bugloos draaien, en dan wordt het een kwestie van wie de snelste is (edit: dan ziek ik de views voor de derde keer even door de vingers ) De beperkingen hieraan die ik zo 1-2-3 kan zien zijn niet heel erg, al is 100% support natuurlijk nooit weg. Maar dat komt later wel, eerst eens zien hoe dit overeind blijft.

VisionMaster schreef op 01 januari 1970 @ 01:00:
Ok Ya GoTha Point ...

[ Voor 6% gewijzigd door Rataplan op 23-10-2003 01:13 ]