[phpMyAdmin] vervang opdracht voor MySQL

[livingtale]

Nergens op het web kan ik een forum of tutorial van het programma phpMyAdmin vinden.
Wie kan mij aan een adres helpen?

Of antwoord geven op de volgende vraag:
Mijn database heeft een tabel "_users". In die tabel is een veld "notify". Als ik een backup ophaal dan zie ik dat dat veld bestaat uit getallen gescheiden door komma's. Ik weet waar die getallen voor staan. Als een bepaald getal voorkomt, stel 111, wil ik dat vervangen door 111,112,
Hoe doe ik dat ik?

[orf]

phpMyAdmin voert queries uit op je mySQL database. Je moet dan ook op zoek gaan naar de documentatie voor je database in plaats van phpMyAdmin.

Kommagescheiden data klinkt als een erg fout datamodel. Dat kun je beter oplossen door te kijken naar je datamodel in plaat van string functies als REPLACE().

[livingtale]

orf schreef op vrijdag 27 juni 2008 @ 14:33:
Kommagescheiden data klinkt als een erg fout datamodel. Dat kun je beter oplossen door te kijken naar je datamodel in plaat van string functies als REPLACE().

Bedankt voor je reactie, maar wat bedoel je met bovenstaande?
Met het datamodel kan ik niet veel doen, dat wordt gecreëerd door een forumprogramma.
Probleem is dat, als ik een deeltopic promoveer tot hoofdtopic, niemand meer geabonneerd is op waarschuwingen. Door de getallen te vervangen (topicnummers) maak ik iedereen die op de oude geabonneerd was automatisch lid van de nieuwe topic . Vandaar het simpele vervangen van de getallen.

Begrijp ik je goed dat ik dus wèl REPLACE() moet gebruiken (omdat het datamodel vastligt)?
En waar kan ik daar info over vinden?

[Niemand_Anders]

Probeer eens google: 'mysql replace'

[leuk_he]

Je kunt losse SQL statements uitvoeren. Dat ga je hier doen.

Iets van

code:

update users
set notify=replace(notify,"111," , "111,112,")

(hoop dat ik niemand op de tenen trap met een bijna uitgewerkt voorbeeld )

Hiervoor heb je een SQL tutorial nodig.

als je dit specifieke ding uitzoekt:
Je hebt de replace string functie nodig, niet het replace commando.

[ Voor 35% gewijzigd door leuk_he op 27-06-2008 14:56 ]

[livingtale]

dit is een stukje van een user (backup-tekst want ik zou niet weten hoe ik anders de inhoud van notify kan bekijken, laat staan wijzigen - vandaar de vraag om een tutorial):
'Margje',1,'00,000,92,112,57,102,107',
Van 00 tot 107 is veld Notify

[NMe]

leuk_he schreef op vrijdag 27 juni 2008 @ 14:52:
Je kunt losse SQL statements uitvoeren. Dat ga je hier doen.

Iets van

code:

update users
set notify=replace(notify,"111," , "111,112,")

(hoop dat ik niemand op de tenen trap met een bijna uitgewerkt voorbeeld )

Hiervoor heb je een SQL tutorial nodig.

als je dit specifieke ding uitzoekt:
Je hebt de replace string functie nodig, niet het replace commando.

Dat werkt alvast niet als 111 de laatste entry in het veld is, of als het getal 1111 bijvoorbeeld voorkomt. Maar dat weet je zelf ook gezien je post verder.

@topicstarter: je datamodel is gewoon verkeerd. Kommagescheiden waardes horen niet thuis in je database. Lees eens wat over databasenormalisatie, en herzie liever je datamodel. Je huidige probleem zou je dan bijvoorbeeld al niet hebben, en dan heb ik het nog niet eens over het feit dat de oplossing voor je directe vraag je systeem 50x zo traag gaat maken als wat het zou zijn met een goed datamodel.

[livingtale]

Begrijp ik het goed, NMe en orf, dat jullie zeggen dat ik de programmeur van mijn discussieprogramma moet opdragen om zijn werk beter te doen?
Want hoezo, herzie je datamodel?
Wat ik op dit Forum vaak tegenkom is dat men reageert met als het ware "hoe kun je nou voor zoiets doms kiezen". Ook als je duidelijk maakt dat nu eenmaal het uitgangspunt is.

[Janoz]

livingtale schreef op vrijdag 27 juni 2008 @ 16:05:
Begrijp ik het goed, NMe en orf, dat jullie zeggen dat ik de programmeur van mijn discussieprogramma moet opdragen om zijn werk beter te doen?

Ja, een basis tutorial normaliseren zou erg goed voor hem zijn. Dit is een overduidelijke N:M relatie (meerdere gebruikers kunnen zich op meerdere topics abboneren) die normaal middels een extra koppeltabel geimplementeerd zou moeten worden.

Want hoezo, herzie je datamodel?

Dat is nu brak. Je probleem is nu eigenlijk dat je datamodel ruk is. Dat jij nu rond moet lopen hacken met replaces is meer een gevolg van je echte probleem.

Sowieso vind ik het vreemd dat een promotie van een discussie draadje er voor zorgt dat ineens alle notificaties niet meer kloppen.

Wat ik op dit Forum vaak tegenkom is dat men reageert met als het ware "hoe kun je nou voor zoiets doms kiezen". Ook als je duidelijk maakt dat nu eenmaal het uitgangspunt is.

Ik denk dat je het dan verkeerd interpreteert. Het punt is vaak dat er ergens een fundamentele ontwerpfout gemaakt wordt waaruit vervolgens verschillende problemen naar voren komen. Je kunt dan wel al die gevolgen op gaan lopen lossen, maar daarmee los je het werkelijke probleem niet op.

[NMe]

livingtale schreef op vrijdag 27 juni 2008 @ 16:05:
Begrijp ik het goed, NMe en orf, dat jullie zeggen dat ik de programmeur van mijn discussieprogramma moet opdragen om zijn werk beter te doen?
Want hoezo, herzie je datamodel?

Een relationele database is, zoals de naam al zegt, bedoeld om relaties tussen entiteiten op te slaan. Jij hebt een entiteit "user" en een andere entiteit, waarvan ik aanneem dat de user heeft aangegen dat hij daarvan notified wil worden. Idealiter heb je daar 3 tabellen voor nodig. Eentje is gewoon de usertabel, en eentje logischerwijs voor de entiteit waar die users over notified wil kunnen worden. De derde tabel bevat niet meer dan een id dat verwijst naar de user tabel en een id dat verwijst naar de andere tabel. Je koppelt door middel van die tabel beide andere tabellen aan elkaar, waardoor je middels een simpele query kunt doen wat jij nu probeert te doen met stringoperaties.

Nogmaals: lees wat door over databasenormalisatie of laat de programmeur die het datamodel gemaakt heeft dat doen. Dit is nogal basale kennis die van essentiëel belang is om te hebben als je met databases werkt.

Wat ik op dit Forum vaak tegenkom is dat men reageert met als het ware "hoe kun je nou voor zoiets doms kiezen". Ook als je duidelijk maakt dat nu eenmaal het uitgangspunt is.

Iets kan best het uitganspunt zijn; als dat uitgangspunt niet goed is, dan is je applicatie niet goed. Soms is de enige manier om vooruit te gaan door een stapje terug te doen.

[leuk_he]

Waaarschuwing.. gedeeltelijk offtopic!!!

livingtale schreef op vrijdag 27 juni 2008 @ 16:05:
Wat ik op dit Forum vaak tegenkom is dat men reageert met als het ware "hoe kun je nou voor zoiets doms kiezen".

Het is een fout ontwerp. Het is een gruwel om als ontwikkelaar verder te moeten met een fout ontwerp. Vaak wordt ook gesteld dat de oplossing via 'X' moet door de topic starter terwijl de oplosssing via Y logisch, gebruikelijk en sneller is.

Maar zoals altijd staat het je vrij in het forum antwoorden te negeren die niet op jouw sitiatie van toepassing zijn. Er komen ALTIJD oplossingen voorbij die nergens op slaan omdat je nou eenmaal antwoorden op allerlei nivos tegen komt.

B.V Jij vraagt om een myphp tutuorial, terwijl je een SQL tutorial nodig hebt. EIGENLIJK heeft zelfs de DB ontwerper een cursus normalizen op straffe van zweepslagen nodig.

[Niemand_Anders]

Eigenlijk bedoelen nme en orf dat wel ja. Zoals je zelf al hebt gemerkt is de gekozen oplossing (array opslaan als een tekst) nou niet echt handig. Een koppeltabel (user <--> topic) had eenvoudiger en logischer geweest.

Even snel (effectief) een lijstje tonen van welke gebruikers je moet waarschuwen is er niet bij. Of andersom, van welke topics wordt een gebruiker op de hoogte gehouden.

Maar je openings topic bevat ook geen oplossingen welke je zelf al hebt geprobeert en dat is meestal de trigger welke reacties als 'lees een boek', 'je data model is fout', etc uitlokt.

[JackPoint]

Met substr kun je wel een gedeelte sellecteren. Meer over substr op http://nl.php.net/manual/en/function.substr.php

[NMe]

JackPoint schreef op vrijdag 27 juni 2008 @ 16:32:
met substr kun je wel een gedeelte sellecteren. Meer over substr op http://nl.php.net/manual/en/function.substr.php

...en op welke manier helpt dat binnen SQL?

[Voutloos]

Mysql heeft ook dergelijke string functies, maar die kant wil je dus echt niet opgaan.

[JackPoint]

Klopt, je kan beter normaliseren. Maar als dat niet mogelijk is kan je met substr in PHP nog wel wat oplossen.

[NMe]

Voutloos schreef op vrijdag 27 juni 2008 @ 16:35:
Mysql heeft ook dergelijke string functies, maar die kant wil je dus echt niet opgaan.

Ì know, maar linken naar de PHP-handleiding heeft niet zoveel zin als de topicstarter vraagt naar een oplossing die hij kan gebruiken in phpMyAdmin.

[pedorus]

TS stelt hier een vraag van het type Pounding A Nail: Old Shoe or Glass Bottle? volgens mij. Gelukkig zijn er veel mensen die TS daarop wijzen, in plaats van dat ze een pasklare oplossing voor dit symptoom aandragen.

Nicola De Francesch heeft ook al zo'n geweldig datamodel lijkt wel.

[leuk_he]

pedorus schreef op vrijdag 27 juni 2008 @ 16:51:
TS stelt hier een vraag van het type Pounding A Nail: Old Shoe or Glass Bottle?

Schouderklopje voor deze link.

[Noork]

Ik zie dat hier zoveel mensen de gekozen oplossing afkeuren. Op zich juist natuurlijk, maar de praktijk is vaak anders. Er zijn talloze redenen te bedenken dat het zo is gedaan. Wellicht was het niet nodig om een nieuwe tabel te maken omdat er b.v. slechts enkelen gebruik van notificaties maken. Een nieuwe koppelingstabel brengt ook vaak extra code voor de interface met zich mee. Misschien was er onvoldoende budget en tijd om dit te realiseren. En het kan ook nog een legacy stukje code zijn, dingen die er gewoon zijn ingeslopen bij q&d uitbreidingen/veranderingen.

De programmeur in kwestie voorzien van zweepslagen lijkt me wat overdreven.

...praat eens met hem :-) en verdiep je er zelf ook eens in. Als je het verschil niet kent tussen PHP, Mysql, SQL en phpmyadmin wanneer je een forum runt dat hierOp gebaseerd is, is er ook iets mis.

[NMe]

Noork schreef op vrijdag 27 juni 2008 @ 17:21:
Ik zie dat hier zoveel mensen de gekozen oplossing afkeuren. Op zich juist natuurlijk, maar de praktijk is vaak anders. Er zijn talloze redenen te bedenken dat het zo is gedaan. Wellicht was het niet nodig om een nieuwe tabel te maken omdat er b.v. slechts enkelen gebruik van notificaties maken.

Onzin. Het is minder werk om het meteen goed te doen, te meer omdat je dan geen problemen tegenkomt zoals die in dit topic.

Een nieuwe koppelingstabel brengt ook vaak extra code voor de interface met zich mee. Misschien was er onvoldoende budget en tijd om dit te realiseren.

Ook onzin, zie mijn vorige punt.

En het kan ook nog een legacy stukje code zijn, dingen die er gewoon zijn ingeslopen bij q&d uitbreidingen/veranderingen.

Des te meer reden om het te herzien zodra het problemen oplevert.

[Noork]

-NMe- schreef op vrijdag 27 juni 2008 @ 17:27:
Ook onzin, zie mijn vorige punt.

Ik zie dit toch echt anders, niet dat het veel uitmaakt. Het kan in sommige gevallen gewoonweg tijdwinst opleveren. Soms weegt het voordeel van het ontwikkelen van een extra tabel + code niet op tegen de kleine voordeeltjes. En een replace() functie is ook weer niet zo'n lastig iets om te doen. In mijn ogen geen probleem, je zou hier zelfs even een php scriptje voor kunnen maken, bij het wijzigen van status van topic. Maar het wil verder niet zeggen dat ik een voorstander ben van comma separated waarden in 1 kolom.

Maar ik denk dat de TS niet moet worden geadviseerd om de ontwerper op z'n flikker te geven, maar beter kan vragen naar de reden achter de gemaakte keuzes; onkunde of iets anders?

[livingtale]

Wat een stortvloed aan reacties. En geholpen ben ik nog niet.
Maar daarover straks.
Ik ontwerp geen programma's. Hoogstens probeer ik ze aan te passen naar mijn wensen. Daar ben ik best wel handig in, al zeg ik het zelf. Dan kom je een simpel probleem tegen het lijf dat je graag wilt oplossen. Een probleem dat ontstaat omdat het programma wat je gebruikt door jou anders wordt gebruikt dan de standaard gebruiker. Bovendien ken je je gebruikers. Dus als je een subtopic verplaatst wéét je dat ze niet de moeite zullen nemen om in hun profiel de kennisgeving ook voor dat nieuwe topic in te stellen. Da's niet alleen pech hebben voor hen, maar ook voor de site, want dan gaat zo'n topic niet leven.

Da's de achtergrond van mijn probleem.
Voor zo'n relatief klein probleem is het natuurlijk onzin om te roepen dat de hele database anders opgezet moet worden. Nog even afgezien dat dat volstrekt buiten mijn bereik ligt. En ik al helemaal niet weet waarom de database zo is opgezet. Nou heb ik jullie commentaar wel aan de programmeur doorgegeven, maar denk je nou echt dat die daar wakker van ligt?

Ik denk dat er heel veel website bouwers zijn zoals ik me hier net heb geportretteerd.
Als jullie vinden dat dergelijke hulpvragers hier niet thuishoren, okay.
Maar ik heb duidelijk verteld wat mijn hulpvraag in eerste instantie was -en daar in feite geen antwoord op gekregen, want ik heb nog steeds geen flauw benul hoe met phpMyAdmin om te gaan en da's gewoon een programma dat mijn host levert - ook daarover klagen heeft niet zoveel zin, noch hoe ik zo'n opdracht moet uitvoeren (ik heb het geprobeerd, maar ja, als je niet weet hoe phpMyAdmin werkt is dat ook maar try and error).

Bedankt Noork, dat je het wat relativeerde.
Want waarom hel en verdoemenis preken, omdat iets niet is zoals jij denkt dat het zou moeten.
Hier zijn natuurlijk prachtige analogieën te bedenken, maar ik denk dat mijn punt ook zo wel duidelijk is.
Toch nog even een verwijzing naar mijn vorige topic: [perl] in formmail.pl (Matt wright) gebruik checkboxes
Eigenlijk speelde daar het zelfde.....

[Noork]

De query die leuk_he aangeeft was dus bijna goed. Zoiets bedoel je volgens mij:

code:

UPDATE tabelnaam SET kolomnaam=replace(kolomnaam, "99", "100")

Waarbij 99 de oude waarde is en 100 de nieuwe.

Hier vind je hoe je dan deze SQL queries moet draaien in phpMyAdmin: How to run SQL Queries using phpMyAdmin

Dat topic over formmail geeft soms wel de trend aan hier op Got. Soms word je goed geholpen, maar vaak ook heb je gebruikers die het zo nodig weer eens beter moeten weten en hele andere oplossingen aandragen. Niet zinvol en constructief. Je vraag immers niet om een alternatief.

[ Voor 5% gewijzigd door Noork op 27-06-2008 18:47 ]

[Verwijderd]

Noork schreef op vrijdag 27 juni 2008 @ 18:45:
De query die leuk_he aangeeft was dus bijna goed. Zoiets bedoel je volgens mij:

code:

UPDATE tabelnaam SET kolomnaam=replace(kolomnaam, "99", "100")

Waarbij 99 de oude waarde is en 100 de nieuwe.

Waarbij 199 wordt vervangen door 1100.

Dit werkt zo niet

Kap nou met halfslachtige oplossingen! Dit is typisch iets dat nu op applicatieniveau moet worden afgehandeld, omdat het datamodel rot is. Het is ofwel dat datamodel aanpassen (geen optie in dit geval) of een workaround programmeren. Daarbij moet je zelf alle velden gaan splitten, kijken of je waarde voorkomt, zo ja vervangen en de rij updaten.

[leuk_he]

livingtale schreef op vrijdag 27 juni 2008 @ 18:16:
Wat een stortvloed aan reacties. En geholpen ben ik nog niet.

Aangezien je je concenteert op de reacties die je niet aanstaan en je daarop reageert krijg je van mij de moeilijkste oplossing mogelijk:

Exporteer heel de database naar een text file.
Lees de resulteerde SQL in in een text editor.
Knip het gedeelte eruit waar je uit je 111, x wilt vervangen en zet dat even in een ander document.
gebruik de search replace functie van de editor om de tekst te vervangen die je wilt vervangen. (bijvoorkeur met een sed scriptje aangezine dat de meest complexe manier is.
plak het relevant stuk terug in het grote document.
Maar de database helemaal leeg, of maak een nieuwe. en lees de backup terug in.

(ik zelf was voor de sql oplossing gegaan dieik het begin poste. )

[pedorus]

phpMyAdmin bevat gewoon links naar zowel de documentatie van zichzelf, als die van MySQL. Op de eerste pagina nog wel. Maar phpMyAdmin heb je hier nauwelijks wat van nodig, enkel het 'sql' knopje moet je even op drukken. Vervolgens moet je hier eens goed naar kijken:

pedorus schreef op vrijdag 27 juni 2008 @ 16:51:
Nicola De Francesch heeft ook al zo'n geweldig datamodel lijkt wel.

Als je nu snapt wat die functies doen, en die worden uitgelegd in de documentatie, is dat toch wel zo'n 1 minuut aanpaswerk voor een 'quick-and-dirty' fix.

Hoe Noork denkt dat het meer code kost om een extra tabel te gebruiken, daar snap ik niks van. Voorbeeld is het aanmaken van een notificatie. Met extra tabel is er maar een INSERT INTO query nodig. Zonder moeten eerst de huidige notificaties worden opgehaald, de notificatie worden toegevoegd, en moet het naar de database worden geschreven. Ook de draadjes laten zien is veel moeilijker. En ik vraag me ook af wat je als maximum lengte voor het veld kiest (waardoor er een maximum komt aan het aantal notificaties afhankelijk van de lengte van hun nummers). Kortom, een voor mij onverklaarbaar datamodel.

NB: Let op dat de oplossing van Noork misgaat op bijvoorbeeld 199, wat 1100 wordt. Daarmee beschadig je de database onherstelbaar(/lastig herstelbaar).

[Noork]

Verwijderd schreef op vrijdag 27 juni 2008 @ 18:49:
[...]

Waarbij 199 wordt vervangen door 1100.

Idd, dit was ik vergeten te melden.

[wackmaniac]

http://www.phpmyadmin.net/home_page/docs.php

Eerste hit op Google....

Je kan wel enorm gaan zagen op de (terechte) reacties, maar een seconde nadenken en Google gebruiken levert zomaar de documentatie van PHPMyAdmin op, precies waar je om vroeg:

Nergens op het web kan ik een forum of tutorial van het programma phpMyAdmin vinden.
Wie kan mij aan een adres helpen?

[ Voor 21% gewijzigd door wackmaniac op 27-06-2008 20:50 ]

[Verwijderd]

wackmaniac schreef op vrijdag 27 juni 2008 @ 20:49:
http://www.phpmyadmin.net/home_page/docs.php

Eerste hit op Google....

Je kan wel enorm gaan zagen op de (terechte) reacties, maar een seconde nadenken en Google gebruiken levert zomaar de documentatie van PHPMyAdmin op, precies waar je om vroeg:


[...]

Als er iets is waar de ts al helemaal niks aan heeft is het de handleiding van phpmyadmin, ookal vraagt hij hier wel om.

Verder is het natuurlijk allemaal goed bedoelt om de ts gelijk te wijzen op structurele fouten in zijn datamodel, maar voor iemand die niet de kennis is huis heeft om een database te verbeteren (inc. alle software die afhankelijk was van die bepaalde tabellen/velden die je aan gaat passen) is het niet echt nuttige informatie.
Zoals hij al aangeeft heeft hij de verantwoordelijke programmeur hier op gewezen, maar daarmee is het probleem van de ts nog niet verholpen. Soms is het dus beter om antwoord te geven op de echte vraag, wat sommige hier nog wel doen gelukkig .
_{(al is dit ook niet echt een antwoord op de vraag )}

[ Voor 39% gewijzigd door Verwijderd op 27-06-2008 21:02 ]

[Verwijderd]

livingtale schreef op vrijdag 27 juni 2008 @ 18:16:
Ik ontwerp geen programma's. ... Voor zo'n relatief klein probleem is het natuurlijk onzin om te roepen dat de hele database anders opgezet moet worden. Nog even afgezien dat dat volstrekt buiten mijn bereik ligt. En ik al helemaal niet weet waarom de database zo is opgezet. Nou heb ik jullie commentaar wel aan de programmeur doorgegeven, maar denk je nou echt dat die daar wakker van ligt?

De TS kan beter de fouten maar door zijn gang programmeurs, die zijn er natuurlijk verantwoordelijk voor! Of is het misschien toch jouw probleem, Pedorus?

[wackmaniac]

Verwijderd schreef op vrijdag 27 juni 2008 @ 20:56:
[...]

Als er iets is waar de ts al helemaal niks aan heeft is het de handleiding van phpmyadmin, ookal vraagt hij hier wel om.

Verder is het natuurlijk allemaal goed bedoelt om de ts gelijk te wijzen op structurele fouten in zijn datamodel, maar voor iemand die niet de kennis is huis heeft om een database te verbeteren (inc. alle software die afhankelijk was van die bepaalde tabellen/velden die je aan gaat passen) is het niet echt nuttige informatie.
Zoals hij al aangeeft heeft hij de verantwoordelijke programmeur hier op gewezen, maar daarmee is het probleem van de ts nog niet verholpen. Soms is het dus beter om antwoord te geven op de echte vraag, wat sommige hier nog wel doen gelukkig .
_{(al is dit ook niet echt een antwoord op de vraag )}

Ik weet het, was ook vooral om aan te geven dat als hij ook maar enig zoekwerk had verricht hij al een stuk verder was gekomen.

[Verwijderd]

livingtale schreef op vrijdag 27 juni 2008 @ 18:16:

Da's de achtergrond van mijn probleem.
Voor zo'n relatief klein probleem is het natuurlijk onzin om te roepen dat de hele database anders opgezet moet worden.

Dat is het probleem met jou. Jij ziet niet in dat door een gigantische ontwerpfout simpele dingen niet meer simpel zijn. Door de geconcateneerde waarden in een kolom kun je een heleboel functionaliteit van de DBMS niet meer gebruiken. Jij noemt het een klein probleem. Wij noemen het een onvergeeflijke fout van iemand die nooit iets van database normalisatie heeft begrepen.

Nog even afgezien dat dat volstrekt buiten mijn bereik ligt. En ik al helemaal niet weet waarom de database zo is opgezet. Nou heb ik jullie commentaar wel aan de programmeur doorgegeven, maar denk je nou echt dat die daar wakker van ligt?

Wat kan mij dat schelen? Die programmeur is een prutser. Dat is niet mijn probleem, maar die van jou. Als de programmeur zich er niets van aantrekt is het nog steeds niet mijn probleem.

Ik denk dat er heel veel website bouwers zijn zoals ik me hier net heb geportretteerd.
Als jullie vinden dat dergelijke hulpvragers hier niet thuishoren, okay.

Zulke vragen mogen wel, maar het enige juiste antwoord is dat er geen quick fix is, en dat er in het verleden een grote fout is gemaakt. Jammer, maar jij krijgt hier niet het antwoord dat je wilde horen.

Maar ik heb duidelijk verteld wat mijn hulpvraag in eerste instantie was -en daar in feite geen antwoord op gekregen, want ik heb nog steeds geen flauw benul hoe met phpMyAdmin om te gaan en da's gewoon een programma dat mijn host levert - ook daarover klagen heeft niet zoveel zin, noch hoe ik zo'n opdracht moet uitvoeren (ik heb het geprobeerd, maar ja, als je niet weet hoe phpMyAdmin werkt is dat ook maar try and error).

Bedankt Noork, dat je het wat relativeerde.
Want waarom hel en verdoemenis preken, omdat iets niet is zoals jij denkt dat het zou moeten.
Hier zijn natuurlijk prachtige analogieën te bedenken, maar ik denk dat mijn punt ook zo wel duidelijk is.
Toch nog even een verwijzing naar mijn vorige topic: [perl] in formmail.pl (Matt wright) gebruik checkboxes
Eigenlijk speelde daar het zelfde.....

Het eigenlijke probleem is dat je dingen moet regelen waar je (nog) geen verstand van hebt. Dan krijg je dit soort gevoelens. Iedereen hier weet meer van dit soort problemen dan jij, maar de uitleg die je krijgt komt ofwel niet over, ofwel het is niet wat je wilt dat het is. Vervelend. Maar als je daar zo mee zit moet je om andere taken gaan vragen.

[Cousin Boneless]

Volgens mij kun je (meer bij toeval) wat met de functie FIND_IN_SET
Heb het nog nooit gebruikt, maar het lijkt hoopvol:
http://dev.mysql.com/doc/refman/5.1/en/string-functions.html

SQL:

UPDATE _users
SET notify = CONCAT(notify, ',112')
WHERE FIND_IN_SET('111', notify) > 0 
     AND FIND_IN_SET('112', notify) = 0

Probeer het eens zou ik zeggen.. doe maar wel even backuppen voortijd!

[ Voor 7% gewijzigd door Cousin Boneless op 27-06-2008 21:38 ]

[NMe]

Verwijderd schreef op vrijdag 27 juni 2008 @ 21:11:
[..]

Ik wilde heel graag een post tikken, maar het beter verwoorden dan Cheatah hierboven deed lukt me denk ik niet.

Jij wil de symptomen van je probleem oplossen. Wij lossen je probleem op. Dat jij dat nuanceverschil niet kunt waarderen, dát is jouw probleem, niet het onze. Er zijn vieze hacks te verzinnen, evenals wat nettere workarounds, maar vanuit pure SQL-code wordt het ofwel niet allesdekkend (en dus foutgevoelig), ofwel totaal onleesbaar als query.