Virusscanner tips?
Met 1 script 2 kolommen uit verschillende tabellen aanpassen
De titel zegt het eigenlijk al, is het mogelijk om met 1 script 2 kolommen uit verschillende tabellen aan te passen.
Bijvoorbeeld kolom ID staat in tabel 1 en
kolom ID staat in tabel 2.
Is het dan dus mogelijk als ik kolom ID uit tabel 1 aanpas, dat dan ook kolom ID uit tabel 2 mee veranderd.
Code (php)
1
2
3
4
5
2
3
4
5
UPDATE tabel1 a
LEFT JOIN tabel2 b on a.id = b.id
SET a.name = 'boo',
b.name2 = 'boo'
WHERE a.id = 1;
LEFT JOIN tabel2 b on a.id = b.id
SET a.name = 'boo',
b.name2 = 'boo'
WHERE a.id = 1;
Toevoeging op 12/03/2014 15:46:32:
Of, extra optie die je mogelijk bedoelt, als het puur om het id gaat (een key dus), dan kan je er een foreign key op plaatsen. Als je dan het id in de ene verandert en de foreign key op CASCADE hebt gezet, dan gaan gelinkte records in de andere tabel mee.
http://www.mobilefish.com/developer/mysql/mysql_quickguide_foreign_keys.html
met deze settings kan je in ieder geval met een simpele UPDATE op je parent-table de data in je child-table al aanpassen.
Gewijzigd op 12/03/2014 15:59:18 door - Ariën -
het gaat om een code, als je inlogt ziet het systeem welke code je hebt (0,1,2,3,4,9) deze kolom "code" staat in 2 verschillende tabellen.
Mij lijkt nu de oplossing om een join te gebruiken.
De gebruiker logt in met een gebruikersnaam en wachtwoord.
De code is dus puur voor wat de gebruiker/supervisor kan en mag.
Een update met een left join? Ik vraag me af of het kan.
Eigenlijk kan je gewoon beter stellen dat je nooit joins moet gebruiken in write query's
Gewijzigd op 13/03/2014 09:44:23 door Ger van Steenderen
Wat als er in de tweede tabel geen matchend record gevonden wordt?
@Michael
Omdat één vergissing er toe kan leiden, dat je gegevens wijzigt of wist die niet gewijzigd of gewist zouden moeten worden.
Ik gebruik zelf bij uitzondering ook wels een join update, maar alleen daar waar het geen kwaad kan (lees in een testomgeving).
Wat betreft je opmerking over vergissingen, dat is natuurlijk je eigen verantwoordelijkheid. Doe je het los van elkaar dan krijg je weer andere zaken waar je over na moet gaan denken, bijvoorbeeld dat de ene update wel lukt en de andere niet. Naast overigens het feit dat ook dan je te veel of te weinig records kunt updaten.
Om eerlijk te zijn zie ik het grote bezwaar dus niet.
Ik niet, en zouden er situaties zijn waarbij je twee of meerdere query's om kan zetten naar één met joins, dan heb je met meerdere quey's veel meer controle op waar het fout gaat.
Kortom, jouw mening is jouw mening, maar ik heb er zeer grote bezwaren tegen, ik vind het niet thuishoren in transactional db systemen.
Ik ken wel praktijk voorbeelden overigens, maar het komt ook bij mij niet vaak voor. De enige die ik nu direct kan zeggen is een situatie waarin ik een tabel had waar nog een andere tabel aan gekoppeld was met extra gegevens. Omdat die extra gegevens nogal eens verschilde (in aantal gegevens die moesten worden opgeslagen) stond dat dus in een tabel met alleen id, kolom nummer en kolom waarde. De gebruiker kon echter het hele record tegelijk aanpassen. Daarbij dus in 1 update gegevens in de hoofd tabel en direct ook in de extra tabel. Dat kan je dan in meerdere queries doen, maar via een join ook in 1. Omdat je op id de join maakt, zie ik niet zozeer hoe dat fout zou kunnen gaan. In elk geval niet 'meer' fout dan wanneer je het in meerdere queries doet.
Gewijzigd op 15/03/2014 09:04:50 door Erwin H
Ik vind het in een aantal situaties belangrijk om generieke SQL te kunnen schrijven, en join updates werken niet in de meeste databasesystemen.
Maar het is gewoon heel onlogisch om met een left join update een waarde aan een kolom mee te geven terwijl die kolom niet bestaat. Als ie niet bestaat hoef je um ook niet te te updaten.
Toevoeging op 15/03/2014 22:20:39:
Auto increment is een DDL ding, dus wat mij betreft geen argument om mij een zwakte bod te verwijten.
Ik vind het in een aantal situaties belangrijk om generieke SQL te kunnen schrijven, en join updates werken niet in de meeste databasesystemen.
Maar het is gewoon heel onlogisch om met een left join update een waarde aan een kolom mee te geven terwijl die kolom niet bestaat. Als ie niet bestaat hoef je um ook niet te te updaten.
In een DML kun je het ware probleem nooit oplossen, maar doe je slechts aan symptoombestrijding. De discussie gaat dan niet over de beste oplossing, maar over de minst slechte oplossing.