[PHP/MySQL] Meerdere records updaten probleem

Daarbij krijg ik al koppijn als ik denk aan de code die vol met contextual keywords staat waar X in het ene stuk eigenlijk Y betekent en in het andere stuk Z Liever gebruik je geen reserved words, maar als het dan toch moet, dan heb ik liever dat het duidelijk is zoals [object] of `object` ofzo.

RobIII wijzigde dit bericht 13-10-2008 18:28 (30%)

quote:

-NMe- schreef op maandag 13 oktober 2008 @ 18:20:
Leuk ja. Alleen werkt dat niet zonder meer altijd, zoals RobIII ook al aangeeft.

Bewijs met verkeerd voorbeeld? null was altijd al reserved, en niet contextual. Het volgende kan gewoon prima:
C#:

1 2	int from = 1; (from i in Enumerable.Range(0,10) select i).ToList();

en in VS.NET gaat zelfs de highlighting goed. Het is enkel nu niet meer aan te raden, nu we weten dat from een keyword is.

quote:

Als je die netjes gebruikt heb je nergens last van, en dan kun je wel roepen dat jij dat niet wil omdat het lelijk is, maar intussen is mijn code niet stuk in MySQL 7.0 en de jouwe potentieel wel.

Ik heb wel eens wat gebroken php+mysql code gehad door wijzigingen in hoe bepaalde dingen in PHP werken, maar nog nooit doordat MySQL een nieuw keyword toevoegde. Ik verwacht eigenlijk ook niet dat dit ooit gaat gebeuren. Sowieso moet je bij een nieuwe versie toch altijd testen of dingen nog wel goed gaan, en zouden dit zeer simpele wijzigingen zijn. Wel heb ik vaak genoeg MySQL-queries op een andere database gebruikt, zonder de backticks te hoeven weghalen. Ik geef toe: resultaten uit het verleden bieden geen garanties voor de toekomst...

quote:

pedorus schreef op maandag 13 oktober 2008 @ 18:43:
Bewijs met verkeerd voorbeeld? null was altijd al reserved, en niet contextual. Het volgende kan gewoon prima:
C#:

1 2	int from = 1; (from i in Enumerable.Range(0,10) select i).ToList();

en in VS.NET gaat zelfs de highlighting goed. Het is enkel nu niet meer aan te raden, nu we weten dat from een keyword is.

Ik heb het nooit gehad over zijn voorbeeld, ik doelde op de quote die Rob aanhaalt. Contextual keywords zijn potentieel ambigu en dus wat mij betreft niet fijn.

quote:

Ik heb wel eens wat gebroken php+mysql code gehad door wijzigingen in hoe bepaalde dingen in PHP werken, maar nog nooit doordat MySQL een nieuw keyword toevoegde. Ik verwacht eigenlijk ook niet dat dit ooit gaat gebeuren. Sowieso moet je bij een nieuwe versie toch altijd testen of dingen nog wel goed gaan, en zouden dit zeer simpele wijzigingen zijn. Wel heb ik vaak genoeg MySQL-queries op een andere database gebruikt, zonder de backticks te hoeven weghalen. Ik geef toe: resultaten uit het verleden bieden geen garanties voor de toekomst...

Bij het draaien van queries op andere DBMS'en krijg je sowieso veel meer gezeik dan alleen het simpel te vervangen gebruik van backticks. Wat te denken van LIMIT vs. TOP? Daarnaast: omdat jij niet expliciet wil aangeven of iets een identifier is of niet kun je je code identifiers gaan conformeren aan elk obscuur DBMS dat je denkt ooit nog eens te willen gebruiken. Doe je dat niet, dan ben je IMO een beetje dom bezig.

pff.. backticks danwel brackets danwel dubbele quotes zijn natuurlijk hartstikke teveel gedoe. En bovendien gruwelijk lelijk.

Ik heb slechts voor zeer weinig queries deze zaken nodig gehad en dat was bij gebruik van nummers als aliassen of spaties er in.
Bovendien zien mijn nicknames er veelal uit als: asn_id, lvg_opt_code, enz..

quote:

BazzPsychoNut schreef op maandag 13 oktober 2008 @ 22:16:
pff.. backticks danwel brackets danwel dubbele quotes zijn natuurlijk hartstikke teveel gedoe. En bovendien gruwelijk lelijk.

Lelijk misschien, maar 'teveel gedoe' is bull; als je app straks breekt omdat je te lam bent om ze te gebruiken piep je wel anders. En beide zijn geen argument om het niet te doen.

quote:

BazzPsychoNut schreef op maandag 13 oktober 2008 @ 22:16:
Ik heb slechts voor zeer weinig queries deze zaken nodig gehad en dat was bij gebruik van nummers als aliassen of spaties er in.

Nee, spaties of nummers in fieldnames zijn mooi Als er iets klinkt naar een slecht DB ontwerp is het nummers in fieldnames. Niet dat het per definitie zo is, maar het riekt er wel behoorlijk naar

quote:

BazzPsychoNut schreef op maandag 13 oktober 2008 @ 22:16:
Bovendien zien mijn nicknames er veelal uit als: asn_id, lvg_opt_code, enz..

Nicknames? En asn_bla en lvg_bla is niet veel gedoe? En dat is wel mooi? En als je tabel tbl_foo foreign keys heeft naar tbl_bar met daarin bar_foo_id (want dat krijg je dan...), wat doe je dan als je foo toch besluit een andere naam te geven? Ook alle foreign keys wijzigen van bar_foo_id naar bar_blah_id? Yeah, like that's gonna happen Ook prefixes zijn niet per definitie slecht, maar zonder onderbouwing zoals jij het nu post slaat het als een tang op een varken.

RobIII wijzigde dit bericht 13-10-2008 22:25 (21%)

* BazzPsychoNut mag niet editen?

Hehe, je hebt daar wel een paar mooie punten, ja.
Mijn queries schrijf ik normaal gesproken op slechts een paar grote databases en een datawarehouse, waarin de tabelnamen niet zullen veranderen.
Voor mijn eigen applicaties is dat overigens ook iets wat ik niet snel zou veranderen. Ik gebruik overigens altijd prefixes voor foreign keys.
Spaties is soms handiger in je field names aliassen als je een mooi excel export of rapportage voor de business wilt maken. Dus wat dat betreft heb ik inderdaad nog nooit field names met aliassen gebruikt. En alleen nummers voor een sudoku solver
Eigenlijk wilde ik alleen maar zeggen dat ik nog nooit backticks e.d. heb gebruikt, maar ook nog nooit een query of package heb hoeven aanpassen om die reden.

quote:

BazzPsychoNut schreef op maandag 13 oktober 2008 @ 23:03:
* BazzPsychoNut mag niet editen?

Er is een edit knop ( ) bovenaan je post

RobIII wijzigde dit bericht 13-10-2008 23:05 (17%)

Ik verzeker je dat die er niet staat. Helaas, want ook in mijn dubbelpost zitten nog te editen fouten...
Dus wat dat betreft heb ik inderdaad nog nooit field names met spaties gebruikt

quote:

BazzPsychoNut schreef op maandag 13 oktober 2008 @ 23:14:
Ik verzeker je dat die er niet staat. Helaas, want ook in mijn dubbelpost zitten nog te editen fouten...

Standaard template? Rechtsboven aan je post gekeken? Welke browser? En post even een screenshot? En zet even je DM aan zodat we deze discussie elders kunnen voeren

RobIII wijzigde dit bericht 13-10-2008 23:25 (16%)

quote:

RobIII schreef op maandag 13 oktober 2008 @ 22:20:
maar 'teveel gedoe' is bull; als je app straks breekt omdat je te lam bent om ze te gebruiken piep je wel anders. En beide zijn geen argument om het niet te doen.

Ik schat het risico dat er apps echt gaan breken hierdoor vrij laag in, op basis van de ervaringen. Het vreemde is ook dat MySQL veel voorkomende ambiguiteiten juist laat bestaan (en dus wel contextual keywords heeft), terwijl men keywords die minder vaak voorkomen wel problemen laat veroorzaken. En mocht het zich voordoen, dan nog is het een kleine moeite om het te fixen. De moeite om nu alles te backticken is waarschijnlijk een stuk hoger. En de problemen dat je ' en ` door elkaar haalt lijken me meer voor de hand liggend, als je tenmiste geen syntax highlighting gebruikt. Als je wel syntax highlighting hebt, dan kun je identifiers toch al zien, dus dan blijft volgens mij alleen de toekomst-gerichtheid versus compatibiliteit&mooiheid over. Dat van die toekomst-gerichtheid is dus een typisch theoretisch MySQL-probleem, wat zich bij andere talen waarbij iets soortgelijks kan niet voor doet.

Over database-overzettingen: Alle backticks verwijderen kost duidelijk toch wat zoek-en-vervang werk. En omzetten naar [] zeker. LIMIT/TOP en andere dingen even wijzigen moet vaak ook, maar dat is geen onnodig extra werk dat er nog bovenop komt. Zeker als je handmatig steeds backticks moet neerzetten wordt het er allemaal echt niet productiever op, vergeleken met de kleine kans op toekomstige problemen.

Als dat probleem met toekomst-gerichtheid er niet was, zouden jullie dan nog steeds backticks gebruiken?

offtopic:
Ik gok dat hij bijvoorbeeld tweakimg.net geblokkeerd heeft in Firefox. Tools->Options->Content->Exceptions naast Images. Vandaar toch deze post

Ik denk dat het probleem met reserved words zich in 99 van de 100 gevallen zelf oplost door logische namen te kiezen. Een kolomnaam als 'time' zou ik zelf nooit kiezen. In extreme gevallen kun je vaak uitwijken naar meervoud e.d.

Backticks standaard gebruiken is een goede gewoonte. Als je het doet zodat je gereserveerde woorden als 'time' kunt misbruiken als kolomnaam ben je imho niet goed bezig.

quote:

AlainS schreef op dinsdag 14 oktober 2008 @ 01:29:
Ik denk dat het probleem met reserved words zich in 99 van de 100 gevallen zelf oplost door logische namen te kiezen. Een kolomnaam als 'time' zou ik zelf nooit kiezen. In extreme gevallen kun je vaak uitwijken naar meervoud e.d.

Het eerste wat je aangeleerd wordt bij het opstellen van datamodellen is dat je consistent moet zijn in je naamgeving. Als alles enkelvoud is (wat wel de norm is, meestal) moet je niet ineens meervoud gaan gebruiken; dan vind ik het netter om een "reserved word" te gebruiken. Waarom de quotes? Omdat het daar geen reserved word ís, het is een identifier.

quote:

Backticks standaard gebruiken is een goede gewoonte. Als je het doet zodat je gereserveerde woorden als 'time' kunt misbruiken als kolomnaam ben je imho niet goed bezig.

Daar ben ik het niet 100% mee eens, en zelfs binnen jouw gedachtengang is het nog mogelijk dat je een reserved word wil gebruiken waarvan je niet weet dat het er een is in de SQL-variant die je gebruikt. Alles dat niet netjes in de SQL-standaard zit is daar een potentiële kandidaat voor.

quote:

pedorus schreef op dinsdag 14 oktober 2008 @ 00:13:
[small]Over database-overzettingen: Alle backticks verwijderen kost duidelijk toch wat zoek-en-vervang werk. En omzetten naar [] zeker.

Nou, inderdaad, dat kost in een goede editor toch al 3 hele minuten. Als het tegen zit zouden het er zelfs 5 kunnen zijn. Holy shit, dat is toch wel een noemenswaardige extra kostenpost bij het overstappen op een ander dbms...

Mensen zeggen hier wel heel makkelijk "ze moeten gewoon geen reserverd keywords" maken. Dit is natuurlijk makkelijker gezegd als gedaan; heel de query-engine zal dan herbouwd moeten worden, of in ieder geval, heeeel flink aangepast worden.
Zelf vind ik backticks lelijk. Maar ze zijn niet fout denk ik zo; je hoort van veel mensen "ze zijn fout", maar ik heb nog nooit een goed argument gehoord. Als ik een query maak en hij werkt niet, kijk ik even naar een reserved keywords list. Staatie daar in, dan neem ik een andere beschrijving voor mijn veld. Gewoon een synoniem nemen. Ik vind het persoonlijk te verwarrend om dan voor 1 enkel veld backticks te gaan gebruiken, dan ga je fouten maken.

quote:

Niekk schreef op dinsdag 14 oktober 2008 @ 09:12:
Ik vind het persoonlijk te verwarrend om dan voor 1 enkel veld backticks te gaan gebruiken, dan ga je fouten maken.

Daarom gebruik ik ze voor al mijn identifiers.

quote:

-NMe- schreef op dinsdag 14 oktober 2008 @ 03:14:
Het eerste wat je aangeleerd wordt bij het opstellen van datamodellen is dat je consistent moet zijn in je naamgeving. Als alles enkelvoud is (wat wel de norm is, meestal) moet je niet ineens meervoud gaan gebruiken;

In de cursus databases van de ou wordt de meervoud methode aangeleerd.

quote:

Daar ben ik het niet 100% mee eens, en zelfs binnen jouw gedachtengang is het nog mogelijk dat je een reserved word wil gebruiken waarvan je niet weet dat het er een is in de SQL-variant die je gebruikt. Alles dat niet netjes in de SQL-standaard zit is daar een potentiële kandidaat voor.

Ik bedoelde meer aan te geven dat ik time en date als kolomnaam niet erg geschikt vind.

@TS: Ik zie dat niemand het in dit draadje al over "SQL Injection" heeft gehad. En daarnaast raad ik sowieso "prepared statements" aan. "SELECT *" is meestal geen goed idee. Verder is de naamgeving een beetje gek, waardoor je op keywords uitkomt. Namen als content en order zeggen mij niks. In plaats van order zou ik bijvoorbeeld iets als sequenceNumber, of seqno gebruiken. En verder zou ik niemand aanraden om zijn eigen CMS te gaan maken, daar zijn er al genoeg van.

quote:

Voutloos schreef op dinsdag 14 oktober 2008 @ 08:04:
Nou, inderdaad, dat kost in een goede editor toch al 3 hele minuten. Als het tegen zit zouden het er zelfs 5 kunnen zijn. Holy shit, dat is toch wel een noemenswaardige extra kostenpost bij het overstappen op een ander dbms...

Een veelgebruikte truc. Pak het zwakste argument, ook al staat dat klein, en ga alleen daar op in

Als ik zo zie heeft altijd backticks(, of [], of "") gebruiken de volgende voordelen:

• De (afhankelijk van de naamgeving kleine) kans op problemen met nieuwe keywords wordt 0.

Ik zie de volgende nadelen:

• De leesbaarheid wordt er niet beter op. Zo is het verschil tussen strings en identifiers minder duidelijk te zien. In ieder geval neemt het ruimte in beslag.
• Het is een zelfverzonnen methode, en is niet standaard. Het wordt ook (bijna?) nergens zo aangeleerd.
• Aanleren en gebruiken kost wat extra moeite

Mocht het zich nu voordoen, dat in de toekomst je app breekt, dan valt dat waarschijnlijk prima uit te leggen ("incompatibele versie"). Daarnaast kost het weinig moeite om op te lossen (even zoeken naar de nieuwe keywords). Misschien is het zelfs een goede gelegenheid om andere dingen gelijk mee te pakken, en levert het meer werk op. Y2K heeft voor de IT-sector ook helemaal niet slecht uitgepakt..
De nadelen verdien je -denk ik- nooit meer terug. Ander onderhoud dat moet plaatsvinden wordt er zo niet makkelijker op, omdat nieuwe mensen aan deze 'standaard' moeten wennen.

quote:

AlainS schreef op dinsdag 14 oktober 2008 @ 18:36:
In de cursus databases van de ou wordt de meervoud methode aangeleerd.

Ik kan me dit nauwelijks voorstellen. Het is inconsistent (vb: stel title is een keyword. 1 article heeft 1 title, geen titles). En juist dat soort woorden maken meer kans om keywords te worden lijkt mij. Soms is het meervoud zelfs al geclaimd (vb: schema/schemas). Ik zou in zo'n geval waarschijnlijk een synoniem gebruiken, maar ik ben het eigenlijk nog nooit tegen gekomen. Over het algemeen zijn de keywords mij niet beschrijvend genoeg zijn om te gebruiken als identifier, vandaar.
En ik kan me al helemaal niet voorstellen dat alle identifiers tussen backticks zetten wordt aangeleerd als iets dat goed is, maar dat zei je ook niet.