[SQL] Waarom geeft MySQL een foutmelding?

[Verwijderd]

Beschouw heb de volgende tabellen:

code:

tweets:
-------------------------------------
id text        from_user_id from_user
-------------------------------------
1  Cool tweet! 13295354     tradeny
2  Tweeeeeeeet 43232544     bolleke
3  Yet another 13295354     tradeny
4  Something.. 53546443     janusz4

users:
---------------------------------------
uid screen_name num_tweets from_user_id
---------------------------------------
1   tradeny     2235       0
2   bolleke     432        0
3   janusz4     5354       0

Ik wil de tweets tabel normaliseren door de inhoud van tweets.from_user te vervangen door user ids (van users.uid). Ik heb de volgende query:

SQL:

UPDATE tweets
SET tweets.from_user = users.uid
FROM tweets
LEFT JOIN users ON tweets.from_user = users.screen_name

Maar de MySQL (5) server geeft een foutmelding: controleer systax rechts van "FROM". Maar ik zou niet weten wat er fout is. Wie ziet het wel?

[Jaap-Jan]

Basis SQL: FROM hoort niet in een UPDATE- statement. De naam van de tabel die je wilt aanpassen komt al na UPDATE. Ik denk dat je je SQL- kennis moet bijspijkeren.

[ Voor 51% gewijzigd door Jaap-Jan op 22-11-2011 12:44 ]

[Standeman]

UPDATE [LOW_PRIORITY] [IGNORE] table_reference
SET col_name1={expr1|DEFAULT} [, col_name2={expr2|DEFAULT}] ...
[WHERE where_condition]
[ORDER BY ...]
[LIMIT row_count]

Ik zie idd ook geen FROM erbij staan..

[NMe]

Die join mag toch ook niet zo in een updatequery?

[Verwijderd]

Poging 2:

SQL:

UPDATE tweets 
LEFT JOIN users ON tweets.from_user = users.screen_name
SET tweets.from_user = users.uid

Dit zou dan gewoon moeten werken

[Edit]
Deze werkt idd

[ Voor 55% gewijzigd door Verwijderd op 22-11-2011 13:13 ]

[Reinier]

Jaap-Jan schreef op dinsdag 22 november 2011 @ 12:44:
Basis SQL: FROM hoort niet in een UPDATE- statement.

Dat mag best, als je meerdere tabellen joint en een of meerdere van die tabellen wilt updaten. Moet werken, alleen is de syntax dan anders...

Wacht even, ik moet iets beter lezen geloof ik

[ Voor 8% gewijzigd door Reinier op 22-11-2011 13:08 ]

[.oisyn]

Nee, wat hij zegt klopt gewoon. Als jij dat interpreteert alsof hij zegt dat je geen meerdere tabellen kunt gebruiken, dan klopt jouw interpretatie niet

[Reinier]

.oisyn schreef op dinsdag 22 november 2011 @ 13:08:
Nee, wat hij zegt klopt gewoon. Als jij dat interpreteert alsof hij zegt dat je geen meerdere tabellen kunt gebruiken, dan klopt jouw interpretatie niet

Inderdaad, dat tweede is het geval. Never mind

Trouwens, in MSSQL kan het wel. In dit topic is dat weliswaar niet relevant, maar over Basis SQL: FROM hoort niet in een UPDATE- statement. kun je dus discussiëren

[ Voor 21% gewijzigd door Reinier op 22-11-2011 13:15 ]

[Standeman]

NMe schreef op dinsdag 22 november 2011 @ 12:57:
Die join mag toch ook niet zo in een updatequery?

In MySQL is het in iedergeval geen probleem.

MySQL supports the following JOIN syntaxes for the table_references part of SELECT statements and multiple-table DELETE and UPDATE statements:

[Nukar]

[quote]SET tweets.from_user = users.uid [/quote]

ik weet het niet hoor. Maar volgens mij ga je nu een ongewenste update uitvoeren. nog los van de bovengenoemde problemen natuurlijk

Als ik zo snel kijk wil je waarchijnlijk:
SET tweets.from_user_id = users.uid

of
SET tweets.from_user = users.screen_name
WHERE tweets.from_user_id = users.uid

duh thnx tweakerert weer een lesje lezen

[ Voor 7% gewijzigd door Nukar op 22-11-2011 13:20 ]

[Waking_The_Dead]

Een beetje OT misschien, maar waarom sla je zowel from_user_id als from_user op in de tweets tabel? Met het ID alleen heb je toch genoeg?

edit: oops, niet goed gelezen, je wil normaliseren...

[ Voor 17% gewijzigd door Waking_The_Dead op 22-11-2011 13:21 ]

[Verwijderd]

Nukar schreef op dinsdag 22 november 2011 @ 13:17:
[...]


ik weet het niet hoor. Maar volgens mij ga je nu een ongewenste update uitvoeren. nog los van de bovengenoemde problemen natuurlijk

Als ik zo snel kijk wil je waarchijnlijk:
SET tweets.from_user_id = users.uid

of
SET tweets.from_user = users.screen_name
WHERE tweets.from_user_id = users.uid

Verwijderd schreef op dinsdag 22 november 2011 @ 12:42:
Ik wil de tweets tabel normaliseren door de inhoud van tweets.from_user te vervangen door user ids (van users.uid).

[NMe]

Standeman schreef op dinsdag 22 november 2011 @ 13:14:
[...]

In MySQL is het in iedergeval geen probleem.

[...]

Hmm, nice. Ik heb het zelden nodig maar als het eens voorkwam heb ik altijd met subquery's gewerkt.

[Standeman]

NMe schreef op dinsdag 22 november 2011 @ 13:20:
[...]

Hmm, nice. Ik heb het zelden nodig maar als het eens voorkwam heb ik altijd met subquery's gewerkt.

Ik doe het meestal gewoon met transacties.. Maar ik ben ook niet zo'n sql guru.. een left outer join snap ik nog wel, maar als zodra er andere keywords staan moet ik wel heel diep gaan nadenken

[.oisyn]

Reinier schreef op dinsdag 22 november 2011 @ 13:09:
Trouwens, in MSSQL kan het wel. In dit topic is dat weliswaar niet relevant, maar over Basis SQL: FROM hoort niet in een UPDATE- statement. kun je dus discussiëren

Nice try, maar SQL is een standaard, dat is de basis. MSSQL voldoet op dat punt niet aan de standaard. Het heet dan ook T-SQL. Wmb geen discussie over mogelijk

[Reinier]

.oisyn schreef op dinsdag 22 november 2011 @ 14:27:
[...]

Nice try, maar SQL is een standaard, dat is de basis. MSSQL voldoet op dat punt niet aan de standaard. Het heet dan ook T-SQL. Wmb geen discussie over mogelijk

Je hebt uiteraard gelijk

[Remus]

.oisyn schreef op dinsdag 22 november 2011 @ 14:27:
[...]

Nice try, maar SQL is een standaard, dat is de basis. MSSQL voldoet op dat punt niet aan de standaard. Het heet dan ook T-SQL. Wmb geen discussie over mogelijk

Welke SQL variant voldoet volgens jou dan wel aan de standaard? Voor zover mij bekend is, voldoet namelijk geen enkele database volledige aan de SQL standaarden.

[.oisyn]

Verandert dat mijn punt dan?

[Remus]

.oisyn schreef op dinsdag 22 november 2011 @ 16:13:
Verandert dat mijn punt dan?

Het ging mij eigenlijk vooral om het 'daarom heet het T-SQL', maar ik was te lui.

Overigens is T-SQL bij mijn weten niet de naam van de SQL variant van MS SQL Server, maar van de procedural language extension (dus voor gebruik in oa triggers, procedures).

Zo onderscheid Firebird bijvoorbeeld ondermeer:
DSQL : dynamische SQL (eg voor interactief gebruik of via de API)
ESQL : embedded SQL (sommige - voornamelijk archaïsche - talen hebben language bindings zodat je SQL direct kan embedden
PSQL : procedural taal (voor gebruik in triggers en procedures)

Aan de andere kant noemt Oracle de query taal zelf simpelweg SQL (of evt Oracle SQL), en de procedural variant PL/SQL

[curry684]

.oisyn schreef op dinsdag 22 november 2011 @ 14:27:
[...]

Nice try, maar SQL is een standaard, dat is de basis. MSSQL voldoet op dat punt niet aan de standaard. Het heet dan ook T-SQL. Wmb geen discussie over mogelijk

Da's klassieke vee-is-geen-koe logica he? Dat een bepaald dialect van een gestandaardiseerde taal meer features biedt dan de standaard voorschrijft maakt het nog geen overtreding van de standaard, tenzij de standaard expliciet voorschrijft dat een FROM-clause niet in een UPDATE mag voorkomen. En het lijkt me sterk dat de SQL-standaarden enige "MUST NOT" uitspraken op dat gebied doen, ergo deze vendor specific extension in Transact-SQL vloekt niet de facto met de standaarden. Dat zou pas het geval zijn als T-SQL een feature zou introduceren die incompatible is met de standaard, of de standaard expliciet voorschrijft dat vendor specific extensions niet zijn toegestaan.

Volgens de logica die je hier presenteert ondersteunt Chrome ook geen CSS-standaarden omdat het -webkit-transition correct parset en toepast.

offtopic:
en ja ik ga hier vooral op in om de 'geen discussie over mogelijk', je kent me

Remus schreef op dinsdag 22 november 2011 @ 17:01:
[...]

Overigens is T-SQL bij mijn weten niet de naam van de SQL variant van MS SQL Server, maar van de procedural language extension (dus voor gebruik in oa triggers, procedures).

Incorrect.

quote: http://en.wikipedia.org/wiki/Transact-SQL

T-SQL expands on the SQL standard to include procedural programming, local variables, various support functions for string processing, date processing, mathematics, etc. and changes to the DELETE and UPDATE statements.

[ Voor 19% gewijzigd door curry684 op 23-11-2011 01:32 ]

[.oisyn]

Je praat poep. Een standaard beschrijft welke syntax hij ondersteunt. Hij gaat niet beschrijven welke syntax hij allemaal expliciet niet gaat ondersteunen - dat is implied

Ergo deze vendor specific extension in Transact-SQL vloekt niet de facto met de standaarden

Het vloekt idd niet in de zin dat hij incompatible is (als in, de FROM in een UPDATE zal niets in de weg zitten wat wel standaard is). Maar bottom line blijft dat het geen standaard SQL is.

Of laat ik het anders brengen. Je kan het denk ik wel met me eens zijn dat in C# bij een methode-aanroep je niet expliciet de types van de parameters hoort op te geven - dat doe je bij de definitie van de methode zelf. Je kunt dus zeggen: "Basis C#: bij een methode aanroep hoort geen typespecificatie". Toch zou iemand een C# dialect kunnen schrijven waarbij dat wel mogelijk is. Maakt dat het eerdere statement ineens onwaar? De C# standaard zegt nergens expliciet dat het niet mag. Het komt wel met een pseudo-EBNF notatie van de grammatica waaruit blijkt dat er geen productieregels voor een dergelijke syntax bestaan.

[ Voor 88% gewijzigd door .oisyn op 23-11-2011 12:50 ]

[Grijze Vos]

Volgens mij waren zo ongeveer alle database systemen knap waardeloos als ze niet een aantal van die zinnige extensions hadden gehad.

[.oisyn]

Dát is een heel ander verhaal, en uit een snelle search op UPDATE FROM blijkt dat zo'n beetje iedere SQL implementatie behalve MySQL het toestaat. Dat zeg ik echter niet graag omdat dat een beetje mijn punt onderuit haalt die ik hier krampachtig aan het verdedigen ben

[curry684]

.oisyn schreef op woensdag 23 november 2011 @ 12:41:
Je praat poep. Een standaard beschrijft welke syntax hij ondersteunt. Hij gaat niet beschrijven welke syntax hij allemaal expliciet niet gaat ondersteunen - dat is implied

[...]

Het vloekt idd niet in de zin dat hij incompatible is (als in, de FROM in een UPDATE zal niets in de weg zitten wat wel standaard is). Maar bottom line blijft dat het geen standaard SQL is.

Dat spreek ik ook nergens tegen. Jij zei echter "MSSQL voldoet op dat punt niet aan de standaard." Dat is wel absoluut poep, want het is helemaal niet implied dat iets dat conformeert aan een standaard geen extra syntax mag ondersteunen, voor het uitsluiten van mogelijkheden hebben standaarden perfecte syntactische middelen als "must not", "should not" en "will not". Een standaard die dat niet expliciet uitsluit geeft een implementor dus expliciet wel de mogelijkheden om een superset van de basisfeatures te implementeren en nog steeds te conformeren aan de standaard.

Dat "UPDATE FROM" geen standaard SQL is betwist ik niet, enkel jouw foute uitspraak dat MSSQL de standaard zou overtreden door het wel te ondersteunen. Een koe is wel vee, maar vee is geen koe.

[.oisyn]

Ah ok, ik dacht dat je een fundamentele discussie begon, terwijl je eigenlijk gewoon maar een semantische discussie wil hebben over de letterlijke betekenis van de combinatie van woorden die ik gebruikt heb om mijn punt over proberen te brengen. Zeg dat dan meteen

[curry684]

De offtopic tag in curry684 in "[SQL] Waarom geeft MySQL een foutmelding?" was niet duidelijk genoeg? Je weet toch dat ik liever op de man speel dan de inhoud?

Dat daargelaten is de semantiek hier imnsho wel van wezenlijk belang natuurlijk, als gezegd impliceerde je uitspraak ook dat Chrome lak heeft aan de webstandaarden door -webkit-transition te implementeren. Dat klopt simpelweg niet.