[mysql] Identieke data uit twee tabellen halen werkt half

[Verwijderd]

Goedendag,

Ik ben bezig met een script om de gegevens uit twee tabellen uit te lezen.
De twee tabellen bevatten identieke data. Het enige dat verschilt is dat de gegevens uit tabel 2 gegevens bevatten van events uit het verleden.

Dit lukt mij half.

code:

SELECT `parkingpanel_history`.* ,`parkingpanel_reserveringen`.* 
FROM parkingpanel_history, parkingpanel_reserveringen

werkt. en geeft zoals te verwachten alle rijen terug.

Zodra ik echter een wat specifiekere greep wil hebben en alleen de rijen waar reservering_naam begint met 'a' wordt het al moeilijker.

code:

SELECT `parkingpanel_history`.* ,`parkingpanel_reserveringen`.* 
FROM parkingpanel_history, parkingpanel_reserveringen WHERE `parkingpanel_reserveringen`.`reservering_naam`  LIKE 'a%'

Maar dit werkt.

Maar het geld alleen voor de gegevens uit tabel `parkingpanel_reserveringen` en niet uit `parkingpanel_history`.

Dus als ik een tweede toevoeg.

code:

SELECT `parkingpanel_history`.* ,`parkingpanel_reserveringen`.* 
FROM parkingpanel_history, parkingpanel_reserveringen WHERE `parkingpanel_reserveringen`.`reservering_naam` OR `parkingpanel_history`.`reservering_naam` LIKE 'a%'

Dit lukt echter niet.
Want hij geeft als ik hem uitvoer in mijn PHP script gewoon alle rijen weer.
En in PHPMyAdmin lijkt hij alle rijen dubbel weer te geven. Al dan wel beginnend met een A. Maar ik zie de heer A.Adema (terplekke verzonnen) 15 keer onder elkaar staan. Wat niet bepaald de bedoeling is.

Kan iemand mij misschien vertellen wat ik fout doe?

Want ik begrijp dat het in de OR ligt

Maar als ik ervan maak

code:

SELECT `parkingpanel_history`.* ,`parkingpanel_reserveringen`.* 
FROM parkingpanel_history, parkingpanel_reserveringen WHERE `parkingpanel_reserveringen`.`reservering_naam` AND `parkingpanel_history`.`reservering_naam` LIKE 'a%'

Biedt me dat weinig soelaas.

[Creepy]

Als je uit twee identieke tabellen aan het selecteren bent, kan je dan niet beter een UNION gebruiken? Je bent nu bezig met een JOIN en daarom krijg je een cartegisch product.

[ Voor 38% gewijzigd door Creepy op 29-03-2010 11:51 ]

[Cloud]

Nu ben ik geen MySQL expert (Postgres weet ik wat meer van), maar ten eerste lijkt mij:

SQL:

... WHERE `parkingpanel_reserveringen`.`reservering_naam` AND ...

niet kunnen. Zelfs niet als `parkingpanel_reserveringen`.`reservering_naam` een boolean veld zou zijn. Het is namelijk géén vergelijking in je statement. Als ik goed begrijp wat je probeert te doen, moet je eigenlijk:

SQL:

... WHERE `parkingpanel_reserveringen`.`reservering_naam` LIKE 'a%' AND ...

daar hebben staan. Voor wat betreft de dubbele rijen heeft Creepy hierboven een goede suggestie.

[Verwijderd]

Creepy schreef op maandag 29 maart 2010 @ 11:50:
Als je uit twee identieke tabellen aan het selecteren bent, kan je dan niet beter een UNION gebruiken? Je bent nu bezig met een JOIN en daarom krijg je een cartegisch product.

Dat dacht ik eerst ook,.

Alleen history heeft nog 1 rij extra

history_id

code:

(SELECT * FROM `parkingpanel_reserveringen` WHERE `reservering_naam` LIKE 'a%') UNION (SELECT * FROM `parkingpanel_history` WHERE `reservering_naam` LIKE 'a%')

Wil dus helaas niet werken.

Plus daarbij dat ik hem daarna wil groeperen op een gelijke rij. En dat gaat geloof ik niet met UNION

[Cloud]

Wat bedoel je met 1 rij extra? Dat maakt toch niet uit voor een UNION? Bedoel je niet toevallig een kolom, want dat maakt natuurlijk wel uit. De kolomselecties uit beide queries moeten dezelfde namen/datatypen hebben, anders kan de DB server er niets zinnigs van maken.

Een oplossing is dan, de extra kolom weglaten of anders toevoegen bij de query waar hij ontbreekt (SELECT NULL as `OntbrekendeKolom`) indien dat natuurlijk uitkomt voor je verdere verwerking.

[Verwijderd]

Cloud schreef op maandag 29 maart 2010 @ 12:02:
Wat bedoel je met 1 rij extra? Dat maakt toch niet uit voor een UNION? Bedoel je niet toevallig een kolom, want dat maakt natuurlijk wel uit. De kolomselecties uit beide queries moeten dezelfde namen/datatypen hebben, anders kan de DB server er niets zinnigs van maken.

Een oplossing is dan, de extra kolom weglaten of anders toevoegen bij de query waar hij ontbreekt (SELECT NULL as `OntbrekendeKolom`) indien dat natuurlijk uitkomt voor je verdere verwerking.

Zodra ik invoer

SQL:

(
SELECT *
FROM `parkingpanel_reserveringen`
WHERE `reservering_naam` LIKE 'a%'
)
UNION (

SELECT *
FROM `parkingpanel_history`
WHERE `reservering_naam` LIKE 'a%'

Geeft hij de foutmelding :
#1222 - The used SELECT statements have a different number of columns

Ik zou dan natuurlijk idd per rij kunnen gaan definiëren.
Maar de vraag is dan nog kan ik dan nog groeperen en sorteren op naam?

Want wat ik mbv dit topic nu heb samengesteld doet deels wat ik wil:

SQL:

SELECT `parkingpanel_history`.* ,`parkingpanel_reserveringen`.* FROM parkingpanel_history, parkingpanel_reserveringen WHERE `parkingpanel_reserveringen`.`reservering_naam` LIKE 'a%' AND `parkingpanel_history`.`reservering_naam` LIKE 'a%' GROUP BY `parkingpanel_history`.`reservering_email`, `parkingpanel_reserveringen`.`reservering_email` ORDER BY `parkingpanel_reserveringen`.`reservering_naam`, `parkingpanel_history`.`reservering_naam` ASC

Alleen geeft hij de rijen een stuk of 15 keer weer.
Terwijl sommige data zowel in tabel 1 als tabel 2 aanwezig is. Maar nooit meer dan 3 x.
Dus als ik sommige data 3 x zou zien dan zou ik aannemen dat ik iets fout doe in de group.
Maar dat is hier niet het geval. Want hij toont het maar liefst 15 keer. Terwijl de tabel geen 15 velden heeft.

Tabel reserveringen heeft 28 velden en de tabel history heeft er +1 29

P.S. ondanks de ongeschreven regel toch heel erg bedankt voor de moeite!!!

[ Voor 4% gewijzigd door Verwijderd op 29-03-2010 12:13 ]

[321X]

1) http://dev.mysql.com/doc/refman/5.0/en/union.html

2) Jouw reactie:

Verwijderd schreef op maandag 29 maart 2010 @ 12:09:
Zodra ik invoer

SQL:

(
SELECT *
FROM `parkingpanel_reserveringen`
WHERE `reservering_naam` LIKE 'a%'
)
UNION (

SELECT *
FROM `parkingpanel_history`
WHERE `reservering_naam` LIKE 'a%'

Geeft hij de foutmelding :
#1222 - The used SELECT statements have a different number of columns

Ik zou dan natuurlijk idd per rij kunnen gaan definiëren.
Maar de vraag is dan nog kan ik dan nog groeperen en sorteren op naam?

en het citaat wat jij ook nog citeert:

Cloud schreef op maandag 29 maart 2010 @ 12:02:
Wat bedoel je met 1 rij extra? Dat maakt toch niet uit voor een UNION? Bedoel je niet toevallig een kolom, want dat maakt natuurlijk wel uit. De kolomselecties uit beide queries moeten dezelfde namen/datatypen hebben, anders kan de DB server er niets zinnigs van maken.

Een oplossing is dan, de extra kolom weglaten of anders toevoegen bij de query waar hij ontbreekt (SELECT NULL as `OntbrekendeKolom`) indien dat natuurlijk uitkomt voor je verdere verwerking.

De oplossing voor die fout werd al voorgedragen voor je jouw SQL Statement probeerde... ;-) Hint: Lees de quote opnieuw.

[Cloud]

Verwijderd schreef op maandag 29 maart 2010 @ 12:09:
[...]

Geeft hij de foutmelding :
#1222 - The used SELECT statements have a different number of columns

Dat is inderdaad het probleem wat ik bedoelde.

Ik zou dan natuurlijk idd per rij kunnen gaan definiëren.
Maar de vraag is dan nog kan ik dan nog groeperen en sorteren op naam?

De vraag is eigenlijk, waarom denk jij dat dat niet zou kunnen? Het groeperen en sorteren moet je natuurlijk niet ín de beide queries gaan doen, dat zal niet het gewenste resultaat geven. Het groeperen en sorteren doe je over het resultaat van de UNION, dus in pseudosql:

SQL:

SELECT ... hier de kolommen die je nodig hebt ...
FROM (
(
... union query 1 ...
)
UNION (
... union query 2 ...)
)
WHERE ... hier je eventuele verdere selectie ...
GROUP BY ...
ORDER BY ...

Als ik de rest van je reactie lees wordt me alleen niet helemaal duidelijk waarom je eigenlijk wilt groeperen? Je groepeert namelijk op alle kolommen die je selecteert en gebruikt geen aggregate over een andere kolom.

[Verwijderd]

Werkt!!

SQL:

(SELECT `reservering_naam`, `reservering_straat`, `reservering_postcode`, `reservering_woonplaats`, `reservering_telefoon`, `reservering_mobiel`, `reservering_email` FROM parkingpanel_reserveringen WHERE `reservering_naam` LIKE 'a%') UNION (SELECT `reservering_naam`, `reservering_straat`, `reservering_postcode`, `reservering_woonplaats`, `reservering_telefoon`, `reservering_mobiel`, `reservering_email` FROM parkingpanel_history  WHERE `reservering_naam` LIKE 'a%') 

Maar uiteindelijk idd dat is logisch.
Echter en GROUP by clause uit beide tabellen wil niet werken.

SQL:

(SELECT `reservering_naam`, `reservering_straat`, `reservering_postcode`, `reservering_woonplaats`, `reservering_telefoon`, `reservering_mobiel`, `reservering_email` FROM parkingpanel_reserveringen WHERE `reservering_naam` LIKE 'a%') UNION (SELECT `reservering_naam`, `reservering_straat`, `reservering_postcode`, `reservering_woonplaats`, `reservering_telefoon`, `reservering_mobiel`, `reservering_email` FROM parkingpanel_history  WHERE `reservering_naam` LIKE 'a%') GROUP BY `reservering_email`

Want als ik per UNION een GROUP clause neerzet zou hij alsnog dingen dubbel kunnen weergeven.

Ik wil ze groeperen omdat ik een lijst wil maken van alle klienten. Maar 1 klient kan natuurlijk meerdere reserveringen hebben bij 1 bedrijf. En nou niet dat je alle klanten 30 x te zien krijgt in het klant overzicht.

Ik dacht mijn fout te zien.

Maar dus niet.

SQL:

SELECT `reservering_naam`, `reservering_straat`, `reservering_postcode`, `reservering_woonplaats`, `reservering_telefoon`, `reservering_mobiel`, `reservering_email` FROM (parkingpanel_reserveringen) UNION (parkingpanel_history)

Dit is zoals het voorbeeld hierboven maar dat lijkt niet te werken

[ Voor 13% gewijzigd door Verwijderd op 29-03-2010 13:17 ]

[Hydra]

Wat betreft je datamodel: dit geeft ook goed aan dat het niet klopt. Dat een reservering in het verleden ligt is absoluut geen reden om het in een andere tabel te stoppen.

[NMe]

Heb je eigenlijk wel een flauw benul van wat je aan het doen bent? Programming FAQ - SQL: Hoe werkt dat GROUP BY nu eigenlijk?

Daarnaast ruikt zo'n aparte tabel voor dezelfde data een beetje naar slecht ontwerp. Waarom staat dat niet gewoon in één tabel?

[Woy]

Je moet het ook zien als 2 losse queries, en dus is het logisch dat een group by ook los gebeurt. Je zou er aan kunnen denken om te selecteren uit de union ( via een view zou kunnen )

SQL:

select field1, count( field2 )
from myUnionedView
group by field1

of eventueel direct in je query

SQL:

select field1, count(field2)
from ( select field1, field2
     from tabel1
     union
     select field1, field2
     from tabel2 ) as myUnion
group by field1

Verder ben ik het met de 2 posters hierboven eens dat je eerst eens goed moet bedenken of je echt de data wel in 2 verschillende tabellen wil hebben.

[ Voor 13% gewijzigd door Woy op 29-03-2010 13:19 ]

[Verwijderd]

Hydra schreef op maandag 29 maart 2010 @ 13:16:
Wat betreft je datamodel: dit geeft ook goed aan dat het niet klopt. Dat een reservering in het verleden ligt is absoluut geen reden om het in een andere tabel te stoppen.

Nou de reden hiervan is dat ik een hele eenvoudige versie van het systeem al heb lopen maar die verzorgt een extreme load op de server.

Terwijl het een rete éénvoudig script is.
Dus probeer ik de load te verminderen door de overbodige items uit de tabel te halen die bijna elke minuut 1 tot 100 keer wordt aangesproken.

[Woy]

Verwijderd schreef op maandag 29 maart 2010 @ 13:18:
[...]


Nou de reden hiervan is dat ik een hele eenvoudige versie van het systeem al heb lopen maar die verzorgt een extreme load op de server.

Terwijl het een rete éénvoudig script is.
Dus probeer ik de load te verminderen door de overbodige items uit de tabel te halen die bijna elke minuut 1 tot 100 keer wordt aangesproken.

Dan zou ik eerst eens gaan kijken naar de juiste indexen, en tabelindeling, daar kun je veel meer op winnen!

[Hydra]

Verwijderd schreef op maandag 29 maart 2010 @ 13:18:
Nou de reden hiervan is dat ik een hele eenvoudige versie van het systeem al heb lopen maar die verzorgt een extreme load op de server.

En twee tabellen dmv een union benaderen gaat niet datzelfde probleem opleveren?

Terwijl het een rete éénvoudig script is.
Dus probeer ik de load te verminderen door de overbodige items uit de tabel te halen die bijna elke minuut 1 tot 100 keer wordt aangesproken.

Dat is echt peanuts voor een fatsoenlijke RDBMS. Indices op de juiste kolommen zullen een hele hoop schelen.

[Verwijderd]

Hydra schreef op maandag 29 maart 2010 @ 13:22:
[...]


En twee tabellen dmv een union benaderen gaat niet datzelfde probleem opleveren?


[...]


Dat is echt peanuts voor een fatsoenlijke RDBMS. Indices op de juiste kolommen zullen een hele hoop schelen.

Niet als het één keer uitgelezen wordt.
Want de data die verlopen is wordt ook niet meer getoond.

[Creepy]

Gewoon een where op je datum kolum en een index op diezelfde kolom? Daar heb je echt geen aparte tabel voor nodig. Ga nu eerst eens kijken en controleren wat er traag is als je alles in 1 tabel hebt en ga dat optimaliseren voordat je extra tabellen gaat aanmaken. Een database kan prima rijen filteren, en snel ook

[ Voor 6% gewijzigd door Creepy op 29-03-2010 13:44 ]

[NMe]

Verwijderd schreef op maandag 29 maart 2010 @ 13:39:
[...]

Niet als het één keer uitgelezen wordt.

Ik herhaal mijn eerste vraag uit mijn vorige post: heb je wel enig idee wat je aan het doen bent? Met een goeie query heeft een database zelfs met miljoenen rijen nog geen problemen.

[Verwijderd]

NMe schreef op maandag 29 maart 2010 @ 13:53:
[...]

Ik herhaal mijn eerste vraag uit mijn vorige post: heb je wel enig idee wat je aan het doen bent? Met een goeie query heeft een database zelfs met miljoenen rijen nog geen problemen.

Ik zeg je eerlijk ik ben geen held in MySQL maar een extreme prutser ben ik ook weer niet.
Ben gisteren met het betreffende script naar een vriend van me geweest. En die is het met je eens dat het script niet al te belachelijk veel load zou moeten veroorzaken. Maar toch doet dat het.

In ieder geval volgens de grafieken van VmWare trekt het script soms (niet altijd) soms 98 van de server resources weg.

Al draait het op een Quad Xeon.
Het zou onmogelijk moeten zijn maar alsnog.

Het rare is ook dat de query soms gewoon lijkt te blijven hangen.
Maar om dit alles wat te verlichten haal ik af en toe de hoofdtabel leeg en haal de vervallen entry's eruit en gooi die in een aparte database.

[Janoz]

Wat is de structuur van die database? (incl indexen) en wat is ongeveer wat het script doet? Welke blijkbaar simpele query laat je los op je gegevens die de server onderuit haalt?

[Hydra]

Verwijderd schreef op maandag 29 maart 2010 @ 14:04:
Ik zeg je eerlijk ik ben geen held in MySQL maar een extreme prutser ben ik ook weer niet.

Als je dit soort data af gaat splitsen in aparte tabellen voor 'performance' redenen ben je gewoon extreem aan het prutsen, sorry.

Vertel eens hoe die data eruit ziet en om wat voor'n queries het gaat?

[leuk_he]

[b][message=33725057,noline]
Want als ik per UNION een GROUP clause neerzet zou hij alsnog dingen dubbel kunnen weergeven.

Nee, want union toont per definitie geen dubbele rijen, als je dat wilt dan moet je union all doen.

Maar als je van elke klant maar 1 rij wilt dan ga je toch die klant tabel erbij trekken? (iets over normaliseren ipv group by). Als je je dat uniek moet krijgen met een group by dan.....

in pseudo code:

Select klantnaarm from klant where
exitxs (select null from reseveringen where naam=klant.naam)
or exists
(select null from reseveringen_history where naam=klant.naam

[Verwijderd]

Verwijderd schreef op maandag 29 maart 2010 @ 13:18:
[...]
Dus probeer ik de load te verminderen door de overbodige items uit de tabel te halen die bijna elke minuut 1 tot 100 keer wordt aangesproken.

Als de query-cache goed staat ingesteld, dan is dat al helemaal geen probleem.

[FastWallie]

Zit het performance probleem niet in je like op een ongeindexeerd naamveld ipv het combineren van 2 tabellen?

Ben wel nieuwsgierig naar de aantallen records van beide tabellen. Een goed geschreven union zou mijn inziens maximaal de responsetijd mogen opleveren van de som van beide afzonderlijke queries.

[plagvreugd]

Ben het ermee eens dat topicstarter best aan het prutsen is. Begon met het niet kunnen schrijven van een WHERE-clause met twee LIKE-condities (WHERE huppeldepup LIKE 'a%' OR IetsAnders like 'a%').

Ook ik denk dat hij een union nodig heeft ipv een join.

En volgens mij heeft hij het woordje distinct nodig, in plaats van dat groepeergebeuren: groeperen alleen maar om rijen uniek te krijgen (en geen counts of sums of zo doen) is prutswerk.

Ook raad ik topicstarter aan om op zijn vocabulaire te letten. 'Rij' gebruiken als je 'kolom' bedoelt schept verwarring. Evenals zeggen dat je de vervallen entry's in een aparte database stopt, terwijl je (hopelijk) een aparte tabel bedoelt.

Tot slot nog het verzoek om bij het posten van SQL wat enters toe te voegen om de leesbaarheid te vergroten.

[RobIII]

plagvreugd schreef op dinsdag 06 april 2010 @ 02:54:
Evenals zeggen dat je de vervallen entry's in een aparte database stopt, terwijl je (hopelijk) een aparte tabel bedoelt.

Los van dat ik het met de rest van je reply eens ben; wat boeit het of het een aparte tabel of aparte DB is

[ Voor 14% gewijzigd door RobIII op 06-04-2010 09:30 ]

[Hydra]

RobIII schreef op dinsdag 06 april 2010 @ 09:29:
Los van dat ik het met de rest van je reply eens ben; wat boeit het of het een aparte tabel of aparte DB is

Afgezien van dat je moet gaan kloten met verschillende databaseconnecties kun je ook geen joins e.d. meer doen, dit terwijl die entries in een aparte DB stoppen m.i. geen voordelen biedt.

FastWallie schreef op maandag 05 april 2010 @ 22:09:
Zit het performance probleem niet in je like op een ongeindexeerd naamveld ipv het combineren van 2 tabellen?

No shit sherlock

[ Voor 23% gewijzigd door Hydra op 06-04-2010 10:41 ]

[RobIII]

Hydra schreef op dinsdag 06 april 2010 @ 10:39:
[...]


Afgezien van dat je moet gaan kloten met verschillende databaseconnecties kun je ook geen joins e.d. meer doen, dit terwijl die entries in een aparte DB stoppen m.i. geen voordelen biedt.

Ik weet niet hoe het met MySQL zit*, maar bij MSSQL kan ik gewoon over verschillende DB's een join doen hoor Kwestie van FQ namen gebruiken;

SQL:

Select ...
From MyTable a
Inner join someotherDB.dbo.someOtherTable b om a.foo = b.bar

* Dat werkt op MySQL dus ook (dbo achterwege laten).

[ Voor 4% gewijzigd door RobIII op 06-04-2010 10:46 ]

[Hydra]

RobIII schreef op dinsdag 06 april 2010 @ 10:43:
Ik weet niet hoe het met MySQL zit*, maar bij MSSQL kan ik gewoon over verschillende DB's een join doen hoor Kwestie van FQ namen gebruiken;

SQL:

Select *
From MyTable a
Inner join someotherDB.dbo.someOtherTable b om a.foo = b.bar

* Dat werkt op MySQL dus ook.

Binnen 1 DB server wel ja, maar daar werd niet over gesproken. Verder zie ik ook geen enkel voorbeeld daarvan.

[ Voor 4% gewijzigd door Hydra op 06-04-2010 10:46 ]

[RobIII]

Hydra schreef op dinsdag 06 april 2010 @ 10:46:
[...]


Binnen 1 DB server wel ja, maar daar werd niet over gesproken.

Euh, jawel

plagvreugd schreef op dinsdag 06 april 2010 @ 02:54:
Evenals zeggen dat je de vervallen entry's in een aparte database stopt

Ik zie niets over aparte servers? Beiden heeft voor/nadelen; dat lijkt me duidelijk; zo kan ik een aparte DB apart backuppen in een ander tijdschema om maar wat te noemen.

[ Voor 15% gewijzigd door RobIII op 06-04-2010 10:49 ]

[Hydra]

RobIII schreef op dinsdag 06 april 2010 @ 10:48:
Euh, jawel

Ik zie niets over aparte servers? Beiden heeft voor/nadelen; dat lijkt me duidelijk; zo kan ik een aparte DB apart backuppen in een ander tijdschema om maar wat te noemen.

Verschil van interpretatie

Als dat een requirement is; prima. Maar records in een andere DB stoppen heeft an sich geen voordelen.

[plagvreugd]

Nou goed, verschillende databases heeft voor- en nadelen. Mijn opmerking was er iig op gericht dat topicstarter het eerst alleen over een aparte tabel heeft en daarna (opeens) over een aparte database. Dit zorgt op zijn minst voor ruis en m.i. ook voor verwarring over wat topicstarter nou wil.

De discussie begon met een (eenvoudige) syntaxvraag en nu praten we over performanceverschillen en voor en nadelen van verschillende databases tov verschillende tabellen in 1 database. We raken nogal offtopic, met name door de mijns inziens gebrekkige communicatie van de topicstarter

[cariolive23]

Verwijderd schreef op maandag 29 maart 2010 @ 13:18:
Dus probeer ik de load te verminderen door de overbodige items uit de tabel te halen die bijna elke minuut 1 tot 100 keer wordt aangesproken.

Al zou je per seconde 100 van dit soort eenvoudige queries uitvoeren, ook dat mag nog een piek opleveren in de belasting van de server. Dit stelt niks voor, kun je op een oude Celeron nog werkend krijgen.

Ga eens achterhalen wat nu de daadwerkelijke oorzaak is, voor zo'n paar records ga je niet de data verplaatsen van de ene tabel naar de andere tabel.

Het is misschien ook geen slecht plan om eens je SQL-kennis bij te spijkeren, daarmee kun je jouw scripts ook flink opwaarderen. Zomaar een DISTINCT of GROUP BY in een query zetten, dat klinkt niet als een weloverwogen beslissing.

Ps. Heb je de server, VM en database wel geconfigureerd? Zo niet, dan weet je al zeker dat je nooit fatsoenlijke performance kunt krijgen.

[Hydra]

plagvreugd schreef op dinsdag 06 april 2010 @ 14:45:
De discussie begon met een (eenvoudige) syntaxvraag en nu praten we over performanceverschillen en voor en nadelen van verschillende databases tov verschillende tabellen in 1 database. We raken nogal offtopic, met name door de mijns inziens gebrekkige communicatie van de topicstarter

Yup, die zich bovendien een week niet vertoond heeft