Archief - Waarde toevoegen, maar checken of het al niet bestaat.

Ik heb 3 tables

Een met subscribers (id (PK) /email/naam/voornaam)
een met lijsten ((id (PK)/ lijstnaam)
en dan nog een subscribed_to die dus gaat kijken voor welke lijst er een gebruiker is ingeschreven. zoals hieronder

+------+-----------+----------+
| id | list_id | sub_id |
+------+-----------+----------+
| 1 | 5 | 8 |
| 2 | 5 | 3 |
| 3 | 4 | 3 |
+------+-----------+----------+

Nu Wil ik dus wel een INSERT INTO subscribed_to (list_id, sub_id) VALUES (4, 8) kunnen uitvoeren, omdat subscriber met het id 8 nog niet is ingeschreven voor lijst 4, maar INSERT INTO subscribed_to (list_id, sub_id) VALUES (4, 3) mag dus niet gaan.

Bij mij blijft hij beide gewoon uitvoeren. Ik dacht dat er mss een optie was in de aard van, insert into blabla values x y if not exist list_id = x sub_id = y

Weet iemand hoe ik dit kan checken? Of moet ik in mijn php script elke keer een query uitvoeren om te checken of waarden bestaan en dan terug qry uitvoeren indien niet?

merci alvast.

Oja, heb al iets gevonden ivm DUPLICATED_KEY, maar daar moest je dan alles uniek maken en ik mg wel degelijk Paar keer 5 hebben, gewoon niet 2 maal dezelfde waarde voor 1 rij.

Hangt van database tot database af hoe ge dat kunt doen.

hoogst waarschijnlijk gebruikt ge mysql?

Jep.

Allright. Ik heb het gevonden. Mag toe. Voor toekomstige mensen die dit probleem hebben:

$qry = mysql_query('INSERT INTO subscribed_to (`id_mailinglist`, `id_subscriber`)
SELECT '.$list[$i].', '.$id_sub.' FROM subscribed_to
WHERE NOT EXISTS
(SELECT *
FROM subscribed_to
WHERE id_mailinglist = '.$list[$i].'
AND id_subscriber = '.$id_sub.')
LIMIT 1');

Waarom maak je het zo moeilijk ? samengestelde sleutel van list_id en sub_id voorkomt dat dit erin kan toch?

sjabieee zei:

Waarom maak je het zo moeilijk ? samengestelde sleutel van list_id en sub_id voorkomt dat dit erin kan toch?

Klik om te vergroten...

klopt .. een unieke sleutel toevoegen op basis van de 2betrokken kolommen voorkomt de insert.

Je kan in principe ook - aangezien je toch MySQL gebruikt - REPLACE INTO gebruiken.

Of - en dat is imho de beste werkwijze - eerst de huidige inschrijvingen ophalen en enkel de nieuwe registreren (en verwijderde ook effectief weghalen), in combinatie met een unieke index op de 2 kolommen die uniek dienen te zijn.

Jullie uitleg begrijp ik absoluut niet. Wat bedoel je met samengestelde sleutel? Ben nog maar paar maanden bezig met php en mysql.

En ik dacht eerst te werken met huidige info ophalen, maar dat leek mij dan weer geen goede werkwijze omdat je 2 maal je databank gaat laten werken, dus performantie drop? not?

Ze bedoelen dat als je zowel van list_id als sub_id een samengestelde sleutel maakt, dat je dan elke combinatie van list_id en sub_id maar 1x kan voorkomen in je database.
Aangezien (4,3) er al instaat, ga je die dus niet nog eens kunnen toevoegen...

Azo, klinkt interessant. En hoe moet ik dat dan juist ingeven? Ik veronderstel dat dit een regeltje in MySQL zelf is dat ik in mijn table moet ingeven?

Gewoon allebij PRIMARY maken als je edit table doet...

Streaker zei:

En ik dacht eerst te werken met huidige info ophalen, maar dat leek mij dan weer geen goede werkwijze omdat je 2 maal je databank gaat laten werken, dus performantie drop? not?

Klik om te vergroten...

Premature optimization is the root of all evil. Je kan dit pas echt gaan benchmarken als je beide scenario's test met reële data. Maar als ik jouw voorstel van oplossing zie dan ben ik er wel vrij zeker van dat 1 select om de huidige combinaties op te halen, gevolgd door enkel de nodige inserts sneller zal zijn dan die oplossing.

dJeez zei:

Premature optimization is the root of all evil. Je kan dit pas echt gaan benchmarken als je beide scenario's test met reële data. Maar als ik jouw voorstel van oplossing zie dan ben ik er wel vrij zeker van dat 1 select om de huidige combinaties op te halen, gevolgd door enkel de nodige inserts sneller zal zijn dan die oplossing.

Klik om te vergroten...

Persoonlijk vind ik dat zo van die nutteloze discussies...
Ok, als je 100% volgens "het boekje" wil werken dan heb je gelijk maar ik vermoed dat niemand hier alles 100% volgens het boekje doet...

Kijk naar hoe sommige software met zulke dingen omspringt. Als je ziet hoeveel queries drupal per pagina nodig heeft. Als je ziet hoeveel queries hibernate genereert...

Als je een banksysteem ontwikkeld waar miljoenen records per seconde moeten verwerkt worden dan is dat nodig maar geef toe, hoeveel % van de developers zal ooit zo een systeem schrijven?

En uiteindelijk de winst die je boekt is niet zo super. Uiteindelijk zal de DB ook wel 2 queries uitvoeren. Ik heb dit eens gecheckt in een Oracle DB en een explain plan gedaan. Resultaat is dat de DB ook 2 queries te verwerken krijgt. Doordat je op PK werkt zijn die queries super performant en zal de winst die je boekt hoofdzakelijk overhead traffic zijn tussen web server en DB server omdat je 2 queries doorstuurt ipv 1.

Wil niet zeggen dat ik tegen best practices ben enzo, ver van. Maar dit gaat me toch iets te ver imo

Wanneer ik een explain plan doe voor een
insert into (...) select (...) where not exist (select .... )
Dan is de totale kost van die query 4.

Een simpele select (...) where (...) heeft een kost van 2.

Bij de select where not exist voert de DB eigenlijk meer queries uit en win je eigenlijk niets.

Merci voor de nuttige info. Ik ben all in voor de beste manier te leren. Ik Weet dat er veel gefoefeld wordt om software draaiend te houden en dat je vaak met simpele dingen uw ding kan laten werken zonder dat de gebruiker er weet van heeft of het zal merken, maar ik wil telkens toch zo goed mogelijk mijn code laten werken. Ik ben nog niet zolang met php/mysql bezig, maar ik voel toch dat het vaak beter/sneller kan en daar probeer ik dan ook steeds nartoe te werken, ook al steek ik mss vaak teveel tijd in iets dat uiteindelijk nooit het daglicht zal zien.

Dit was dan ook maar voor een school opdrachtje dat morgen al in de vuilbak gaat liggen, but anyway... Al doende leert men en ik leer het liever van de eerste keer juist dan later in een bedrijf komen en moeten zien dat je alles opnieuw mag beginnen leren omdat mijn manier toch niet zo goed is.

passero zei:

Persoonlijk vind ik dat zo van die nutteloze discussies...
Ok, als je 100% volgens "het boekje" wil werken dan heb je gelijk maar ik vermoed dat niemand hier alles 100% volgens het boekje doet...

...

Bij de select where not exist voert de DB eigenlijk meer queries uit en win je eigenlijk niets.

Klik om te vergroten...

Ik denk dat je de eerste regel in mijn post genegeerd hebt, want je zegt eigenlijk net hetzelfde als wat daar staat

We hebben op het werk ook net een optimalisarieronde achter de rug. Grootste snelheidswinst was er een Varnish voor te zetten en wat queryresultaten tijdelijk te cachen (zondag gaan we weten of dat volstaat ).