Hallo, ik wil in mysql een range van serienrs tegelijk updaten. Is hier een query voor. ik heb al gezocht op de site van mysql maar wordt daar niet veel wijzer. voorbeeld van een enkel serienr is ongeveer zo:
UPDATE tabel SET omschrijving='verkocht' WHERE serienummer='10001001'
Maar de range is in 4 groepen verdeeld die beginnen met '10001...' 10002..' 10003...' 10004...' per groep dus 999 stuks.
UPDATE
tabel
SET
omschrijving='verkocht'
WHERE
SUBSTRING(serienummer, 1, 5) = '10001'
Verder is het een rare query, je gaat niet de omschrijving naar de bliksem helpen wanneer je de status van een record wilt aanpassen. Maar goed, dat mag je natuurlijk helemaal zelf weten.
Verder kan het geen kwaad om de range en het nummer in de range in aparte kolommen (of zelfs een aparte tabel) op te slaan, het zijn blijkbaar aparte nummers.
1: Bij welk karakter te beginnen, in dit geval nummer 1
5: Het aantal karakters, in dit geval 5 stuks.
Maar nogmaals, het is en blijft een rare query met het aanpassen van de omschrijving wanneer je de status wilt veranderen. Een klein foutje zorgt er nu voor dat je daadwerkelijk data kwijt raakt, daar waar je eigenlijk alleen maar een status hoeft aan te passen. Dit lijkt me geen goede constructie, het is vragen om problemen.
@Frank: het is alleen een (verkeerde) veldnaam. Het had inderdaad beter status o.i.d. kunnen heten, maar Rob heeft voor omschrijving gekozen. Waarschijnlijk met hetzelfde uitgangspunt. Zolang hij de velden dus in de juiste constructie blijft gebruiken, zullen er geen problemen voorvallen ; ).
Pfffffff, een status noem je 'omschrijving' ? En de omschrijving? Die heet nu status? Ik voel nattigheid! Bereid je vast voor op bugs, je gaat hier fouten maken, daar vraag je gewoon om.
Een status is geen omschrijving, hoe je het ook wendt of keert.
Succes met het terugzetten van je backup!
Ps. Ik spreek uit ervaring, heb dit soort ellende te vaak zien gebeuren
Persoonlijk zou ik inderdaad werken met veldnaam 'status', enum(0,1). Ik geef je gelijk : ). Echter ligt deze keuze geheel aan scripters kant. Je waarschuwing is duidelijk.
// Ik vraag me overigens af wat voor fout er voor kan vallen als je een veld een niet-doorgaanse naam gegeven hebt....
Persoonlijk zou ik inderdaad werken met veldnaam 'status', enum(0,1).
En er zijn niet meer statussen mogelijk? Ik raad je aan om een aparte tabel met statussen aan te maken en hier met een foreign key naar te verwijzen. Dan heb je oneindig veel mogelijkheden en loopt je data geen enkel risico. Een ENUM heeft namelijk ook nog wel wat bugs in huis...
// Ik vraag me overigens af wat voor fout er voor kan vallen als je een veld een niet-doorgaanse naam gegeven hebt....
Even snel een query uitvoeren, niet goed kijken en de logische aanname doen dat er in het veld X ook daarwerkelijk gegevens X staan. Te logisch voor woorden, maar je kunt gruwelijk de mist in gaan wanneer blijkt dat er Y in stond...
Duidelijkheid helpt je nauwelijks wanneer je de zaken heel goed bekijkt, doorleest en analyseert (wat je zelden doet...) maar helpt enorm wanneer je er met een half oog naar kijkt. En daar ontwerp je een systeem voor, om zo min mogelijk fouten te maken! Dat je fouten gaat maken staat wel vast, dat is menselijk. Maar domme fouten zijn wel heel erg dom.
Ik geef je gelijk, maar ik doelde meer op: zolang Rob overzicht houdt en dus weet wat er in 'omschrijving' komt, zullen zich geen fouten voordoen.
Daarnaast vind ik een enum() veiliger. Zo kun je ook niet gaan lopen klooien met de input. Alleen 0 en 1 (en indien nodig meerdere, uiteraard) zijn toegestaan, anders zal de query fout aflopen.
Van fouten kun je leren, maar een backup maken voordat je je op de rand van de afgrond waagt met gevaarlijke queries, kan je al weer een boel stress besparen.
Daarnaast vind ik een enum() veiliger. Zo kun je ook niet gaan lopen klooien met de input. Alleen 0 en 1 (en indien nodig meerdere, uiteraard) zijn toegestaan, anders zal de query fout aflopen.
Veiliger? Je kunt waardes die in gebruik zijn zo weggooien, geen haan die daar naar kraait. (alle versies, behalve versie 5 strict). Zie ook yapf.net.
Met een aparte tabel en een foreign key zal je dit niet gebeuren.
