Met 1 script 2 kolommen uit verschillende tabellen aanpassen

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

Fol Effe

Fol Effe

12/03/2014 15:40:58
Quote Anchor link
Hallo allemaal,

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.
 
PHP hulp

PHP hulp

28/03/2024 15:28:49
 
Erwin H

Erwin H

12/03/2014 15:45:16
Quote Anchor link
Ja dat kan via een join:
Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
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;


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.
 
- Ariën  -
Beheerder

- Ariën -

12/03/2014 15:58:18
Quote Anchor link
Meer informatie en een voorbeeld over de ON UPDATE CASCADE vind je op:
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 -
 
Fol Effe

Fol Effe

12/03/2014 16:00:54
Quote Anchor link
Bedankt voor je snelle reactie,

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.
 
Erwin H

Erwin H

12/03/2014 16:03:05
Quote Anchor link
Hmm, dan zou je je alleen moeten gaan afvragen waarom het in 2 tabellen staat. Dat is dubbele info en 99 van de 100 keer te voorkomen (en beter).
 
Fol Effe

Fol Effe

13/03/2014 08:32:30
Quote Anchor link
Tjaa.. dat vraag ik mezelf ook af, ik heb de database niet zelf gemaakt.
 
Ger van Steenderen
Tutorial mod

Ger van Steenderen

13/03/2014 09:43:32
Quote Anchor link
Oei Erwin,

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
 
Erwin H

Erwin H

13/03/2014 09:51:30
Quote Anchor link
Ja Ger, het kan, zelf getest voor ik dit plaatste! Beide tabellen worden geupdate.
 
Michael -

Michael -

13/03/2014 10:06:17
Quote Anchor link
Ger, Zou je je antwoord kunnen toelichten? Bij een genormaliseerde database zal het niet (snel) nodig zijn, maar waarom zou het 'not done' zijn?
 
Ger van Steenderen
Tutorial mod

Ger van Steenderen

13/03/2014 11:01:03
Quote Anchor link
@Erwin

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).
 
Erwin H

Erwin H

13/03/2014 11:38:05
Quote Anchor link
Simpel ,je kent het vershil tussen een LEFT JOIN en een INNER JOIN. Dus bij een LEFT JOIN wordt de tabel wel geupdate als er in de andere tabel geen match is, bij een INNER JOIN wordt er in dat geval niets geupdate.

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.
 
Ger van Steenderen
Tutorial mod

Ger van Steenderen

13/03/2014 19:00:23
Quote Anchor link
Kan jij een praktijk situatie verzinnen waarbij het van toepassing is?

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.
 
Erwin H

Erwin H

13/03/2014 20:53:35
Quote Anchor link
Zondermeer is het een mening en meningen verschillen af en toe, uh, vaak :-)

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.
 
Ger van Steenderen
Tutorial mod

Ger van Steenderen

15/03/2014 09:00:06
Quote Anchor link
Ik zou zeggen, ga eens met een echt database systeem werken, en probeer het dan eens uit .....
 
Erwin H

Erwin H

15/03/2014 09:04:01
Quote Anchor link
Sorry Ger, maar dat is een zwakte bod. In veel andere systemen kan je ook niet met een auto increment werken en toch is dat een heel geaccepteerde feature van MySQL. Tot dusver heb ik je wel zien zeggen je er 'zeer grote bezwaren' tegen hebt maar heb ik die nog niet teruggevonden in je antwoorden. Leg het liever uit, dan kan ik er misschien ook nog iets van leren.
Gewijzigd op 15/03/2014 09:04:50 door Erwin H
 
Ger van Steenderen
Tutorial mod

Ger van Steenderen

15/03/2014 22:20:22
Quote Anchor link
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.



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.
 
Ward van der Put
Moderator

Ward van der Put

16/03/2014 06:59:38
Quote Anchor link
Er is hier wel een duidelijk causaal verband. Het datamodel deugt niet en daardoor moet je in de DML iets doen dat onlogisch lijkt (en dat feitelijk ook is). Eén code moet op twee plaatsen worden bijgewerkt, dus de UPDATE krijgt een vreemde constructie.

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.
 



Overzicht Reageren

 
 

Om de gebruiksvriendelijkheid van onze website en diensten te optimaliseren maken wij gebruik van cookies. Deze cookies gebruiken wij voor functionaliteiten, analytische gegevens en marketing doeleinden. U vindt meer informatie in onze privacy statement.