Records updates zonder PK
Geen van de kolommen is echter een PK of uniek.
(Hoe) kan ik dan een specifiek record updaten in die tabel als de records precies dezelfde waarden hebben in elke kolom?
Mijn kolommen:
`waarde1`, `waard2`, `waarde3`
Mijn records:
1, 2, 3
3, 1, 2
2, 3, 1
1, 2, 3
1, 3, 2
1, 2, 3
Merk op dat records '1', '4' en '6' kwa inhoud niet van elkaar te scheiden zijn.
Hoe kan ik deze records 1 voor 1 toch aanpassen zonder dat ik moet werken met offsets, limits e.d.
Als ik met phpMyAdmin de record '4' wilde aanpassen, bedacht deze de query:
Code (php)
1
UPDATE `test_tabel` SET `waarde2` = '0' WHERE CONCAT( `waarde1` ) = '1' AND CONCAT( `waarde2` ) = '1' AND CONCAT( `waarde3` ) = '2' LIMIT 1 ;
dit is dus niet wat ik wil.. (maar deed me beseffen dat er waarschijnlijk niets anders op zit).
Gewijzigd op 01/01/1970 01:00:00 door Martijn Wieringa
Quote:
(Hoe) kan ik dan een specifiek record updaten in die tabel als de records precies dezelfde waarden hebben in elke kolom?
Leg mij eens uit wat er speciek is aan een record wanneer een ander record exact hetzelfde is.
Dit datamodel lijkt nergens op en is gedoemd te mislukken. Voeg nog even een kolom 'id' toe die je UNIQUE maakt en met auto_increment automatisch laat ophogen.
Wat je ook kunt doen, is de combinatie van de 3 kolommen UNIQUE maken. Dat betekent voor bovenstaand voorbeeld dat er diverse records moeten worden verwijderd. Maar dat is toch al een goed plan, het is volkomen zinloos om dezelfde gegevens meerdere keren op te slaan. Dat is ook niet het idee van een relationele database waar je data slechts 1x opslaat.
Ik heb geen controle over de opbouw van de tabel.. en in theorie kan een dergelijke opbouw voorkomen (of het slim is doet voor het betreffende script niet ter zake).
Het script zoekt nu eerst naar de primary key als reference, daarna naar een combinatie van alle unieke velden, maar als er ook geen unieke kolommen bestaan met ik een alternatief hebben.. en die probeer ik via deze vraag te vinden ;)
Gewijzigd op 01/01/1970 01:00:00 door Martijn Wieringa
Als ik geen 'ORDER BY' gebruik pakt MySQL standaard de volgorde van invoegen.
Als de tabel fungeert als een 'stack' volgens het FIFO of FILO princiepe (of dit wederom slim is valt buiten de scope van de vraag) maakt het wel degelijk uit welk record ik aanpas.. de eerste, laatste, of een record ergens in het midden..
Gewijzigd op 01/01/1970 01:00:00 door Martijn Wieringa
1
1
1
1
Hoe moet je nu weten van welke 1 een 2 moet worden gemaakt? Om even een voorbeeldje te geven.
'een script die records van onbekende tabellen moet kunnen updaten' klinkt mij uitermate vaag in de oren. Je maakt 1x een datamodel en je kent ieder tabel van voor naar achter en van links naar rechts. Daar is niets onbekends aan. Ik ben erg benieuwd wat je nu aan het maken bent, snap er niets van.
Ik wil bijvoorbeeld het '3e toegevoegde record' aanpassen.. mijn vraag is OF dat kan, en zo ja HOE :) (maar zoals ik al schreef vrees ik dat het niet kan..)
Maar 'onderwater' moet de engine van mysql toch soort van record references bijhouden die altijd uniek zijn.. kan ik die benaderen.. ik bedenk maar wat? :)
i'm all ears (a)
Ik heb het getest met deze tabel:
Code (php)
1
2
3
4
5
2
3
4
5
waarde 1 waarde 2 waarde 3
1 2 3
1 2 3
1 2 3
1 2 3
1 2 3
1 2 3
1 2 3
1 2 3
Ik klikte in de derde rij op edit en maakte van de 2 een 3
Phpmyadmin genereerde vervolgens deze code:
Code (php)
1
UPDATE `tabel` SET `waarde2` = '3' WHERE CONVERT( `waarde1` USING utf8 ) = '1' AND CONVERT( `waarde2` USING utf8 ) = '2' AND CONVERT( `waarde3` USING utf8 ) = '3' LIMIT 1 ;
En rij 1 werd ge-update
Toen was het dus
Code (php)
1
2
3
4
5
2
3
4
5
waarde 1 waarde 2 waarde 3
1 3 3
1 2 3
1 2 3
1 2 3
1 3 3
1 2 3
1 2 3
1 2 3
Conclusie: het is niet mogelijk en het slaat nergens op.
Tabel, kolom:
1
1
1
UPDATE tabel SET kolom = 2 WHERE kolom = 1
1x raden hoeveel records er worden bijgewerkt...
Zorg dus ALTIJD voor een uniek gegeven in een tabel, dan kun je records nog eens een keertje terug vinden en daar iets mee gaan doen.
Ik ga/ging er eigenlijk van uit dat op de achtergrond MySQL naar de records refereert met een voor de gebruiker 'onzichtbaar' id. (anders zou het voor de MySQL engine ook niet mogelijk zijn om 2 gelijke records van elkaar te onderscheiden).
Ik had gehoopt naar dit 'id' te kunnen verwijzen (o.i.d.) om zo onderscheid te kunnen maken tussen 'gelijke records'.
Er blijft een verschil tussen legitieme 'sql statements' en de mogelijkheden van de MySQL engine lijkt me ;)
Het lijkt me niet wenselijk dat als m'n script geen 'primary key' detecteerd deze a la brute force dan maar een kolom aanmaakt met een AUTO_INCREMENT PRIMARY KEY. Dat kan/mag ook niet de bedoeling zijn van een database beheer schilletje.