[PHP/MySQL] Meerdere records updaten probleem

[Yoram]

Hallo allemaal,

Ik heb een probleem waar ik al een lange tijd mee ben aan het stoeien.
Ik ben bezig met een redelijk simpel CMS systeem, nu werkt dat bijna helemaal. Alleen, ik krijg één ding niet voor elkaar.

Je kan pagina's toevoegen en verwijderen enzo, die pagina's staan in een mysql tabel met het ID, de titel, de content, wat voor type pagina is, en het nummer waarop ze zijn gesorteerd.
Nu ben ik bezig met een stukje code waar je dat nummer kan veranderen.
Het lukt me om alle records tevoorschijn te halen, het lukt me om één record aan te passen. Maar ik krijg het echt niet voor elkaar om doormiddel van één submit knop alle records aan te passen.

Op internet staan echt een hoop voorbeelden waarvan ik er een hoop heb gelezen en uitgeprobeerd.
Op deze site staat een kant en klaar voorbeeld: http://www.phpeasystep.com/mysqlview.php?id=10 .
Deze heb ik gekopieerd en zo aangepast dat hij mijn tabel kan updaten. Zo ook te zien zijn er superglobals gebruikt, ik gebruik die optie niet dus ik heb dat al aangepast.

Mijn code tot nu toe:

PHP:

<?php
//include config
include("config.php");

mysql_connect("localhost",$username,$password)  or die( "Can't connect to database!");
@mysql_select_db($database) or die( "Unable to select database!");

$sql="SELECT * FROM content";
$result=mysql_query($sql);

// Count table rows
$count=mysql_num_rows($result);
?>

<form name="form1" method="post" action="">

<?php
while($rows=mysql_fetch_array($result)){
  $id[]=$rows['id']; echo $rows['id']; ?>
<input name="title[]" type="text" id="title" value="<?php echo $rows['title']; ?>">
<input name="order[]" type="text" id="order" value="<?php echo $rows['order']; ?>"><br>
<?php
}
?>
<input type="submit" name="Submit" value="Submit">

<?php

if($_SERVER['REQUEST_METHOD'] == 'POST'){
for($i=0;$i<$count;$i++){
$title = $_POST['title'];
$order = $_POST['order'];
$sql1="UPDATE content SET title='$title[$i]', order='$order[$i]' WHERE id='$id[$i]'";
$result1=mysql_query($sql1);
}
}
mysql_close();
?>
</form>

Als ik hier een van de cijfers verander en op submit klik gebeurt en niks, ook geen foutmelding of iets dergelijks.

Ik weet echt niet wat ik fout doe.
Wie o wie kan mij helpen?
Alvast onwijs bedankt

[StephanVierkant]

Als je je databeest niet vraagt om een foutmelding, gaat 'ie hem ook niet geven:

PHP:

<?php $result1=mysql_query($sql1) or die(mysql_error()); ?>

'WHERE id='$id[$i]' lijkt me ook niet helemaal de bedoeling. Moet dat niet gewoon 'id = '$i' zijn? Bovendien begin je je for-loop met $i = 0, terwijl 'id = 0' me niet helemaal logisch lijkt.

[Yoram]

Ah okee, ik heb even dat error report ertussen gezet en hij zegt dat dit niet goed is: 'order='2' WHERE id='23'' at line 1.

Die WHERE id='$id[$i] lijkt mij wel te kloppen omdat elk record een unieke ID heeft, anders geeft hij 1. en dat komt niet overeen met me tabel.

Dit zijn de waardes in me tabel, even voor de duidelijkheid:

code:

ID  Title        Content                                                 Order  Type

23  Nieuws       null                                                    2      blog
8   Contact      <p>Hier de contact gegevens</p>                         999    text
65  Kerdos       <p style="text-align: left;">Vul hier u tekst in</p>    3      text
62  Home         <p style="text-align: left;">Vul hier u tekst in.</p>   1      text
64  Referenties  null                                                    4      blog

En waar haal je id = 0 vandaan ?

[RobIII]

Yoram schreef op maandag 13 oktober 2008 @ 02:16:
Ah okee, ik heb even dat error report ertussen gezet en hij zegt dat dit niet goed is: 'order='2' WHERE id='23'' at line 1.

order is een reserved word
_{Alhoewel ik niet weet of MySQL daar over valt; zou niet voor 't eerst zijn als MySQL dat soort dingen doodleuk vreet}

[ Voor 107% gewijzigd door RobIII op 13-10-2008 02:21 ]

[Yoram]

wtf, dat meen je niet...
Ik heb het aangepast en het werkt !!!

Onwijs bedankt man!

[RobIII]

Yoram schreef op maandag 13 oktober 2008 @ 02:23:
wtf, dat meen je niet...
Ik heb het aangepast en het werkt !!!

WTF dat dat zelf niet in je opgekomen was! Je bent bekend met SQL?

Yoram schreef op maandag 13 oktober 2008 @ 02:23:
Onwijs bedankt man!

Desalniettemin graag gedaan

[Yoram]

ben er 3 kwart jaar geleden ooit mee begonnen. Dusch weet niet veel van SQL/PHP .

[RobIII]

Yoram schreef op maandag 13 oktober 2008 @ 02:46:
ben er 3 kwart jaar geleden ooit mee begonnen.

Dus je hebt driekwart jaar met SQL gewerkt zonder gehoord te hebben van een "order by" clause? Hoe sorteer je je resultsets dan?

[NMe]

RobIII schreef op maandag 13 oktober 2008 @ 02:19:
_{Alhoewel ik niet weet of MySQL daar over valt; zou niet voor 't eerst zijn als MySQL dat soort dingen doodleuk vreet}

MySQL mag dan gekke dingen doen, maar reserved words pakken als identifiers is niet één van die gekke dingen. Dit is in elk geval de reden dat ik zelf altijd netjes backticks ( ` ) om mijn identifiers heen zet.

[Verwijderd]

Reserved words mag je gewoon gebruiken hoor. Maar je moet ze wel escapen met `backticks` (niet verwarren met 'single quotes').

nme...

[ Voor 11% gewijzigd door Verwijderd op 13-10-2008 03:45 ]

[pedorus]

-NMe- schreef op maandag 13 oktober 2008 @ 03:36:
MySQL mag dan gekke dingen doen, maar reserved words pakken als identifiers is niet één van die gekke dingen. Dit is in elk geval de reden dat ik zelf altijd netjes backticks ( ` ) om mijn identifiers heen zet.

De MySQL-gekte houdt niet op. Zie hier:

MySQL allows some keywords to be used as unquoted identifiers because many people previously used them. Examples are those in the following list:

• ACTION
• BIT
• DATE
• ENUM
• NO
• TEXT
• TIME
• TIMESTAMP

Vanwege de leesbaarheid en compatibiliteit zijn die backticks eigenlijk ook niet geweldig. Net zoals de suggestie in de manual:

At some point, you might upgrade to a higher version, so it's a good idea to have a look at future reserved words, too. You can find these in the manuals that cover higher versions of MySQL.

Vreemd, ik kan de manual van 7.0 nog niet vinden...

[Voutloos]

pedorus schreef op maandag 13 oktober 2008 @ 09:51:
Vreemd, ik kan de manual van 7.0 nog niet vinden...

Pfff, alsof er uberhaupt iemand al 6.0 in productie draait.

[NMe]

Pedorus: "time" mocht ik in MySQL 4 in elk geval nog niet als identifier gebruiken. Verder: wat is er mis met de leesbaarheid van identifiers tussen backticks? Ik vind dat wel duidelijk. Goed, het is anders dan de brackets die je in T-SQL gebruikt, maar maakt dat zoveel verschil in leesbaarheid?

[pedorus]

-NMe- schreef op maandag 13 oktober 2008 @ 13:11:
Pedorus: "time" mocht ik in MySQL 4 in elk geval nog niet als identifier gebruiken.

Ik had het ook niet verwacht, maar het werkt perfect:

mysql> create table time(time int);
Query OK, 0 rows affected (0.05 sec)

mysql> insert into time values (1);
Query OK, 1 row affected (0.00 sec)

mysql> select time from time where time=1;
+------+
| time |
+------+
|    1 |
+------+
1 row in set (0.00 sec)

Verder: wat is er mis met de leesbaarheid van identifiers tussen backticks? Ik vind dat wel duidelijk. Goed, het is anders dan de brackets die je in T-SQL gebruikt, maar maakt dat zoveel verschil in leesbaarheid?

Tsja, dat is een kwestie van smaak natuurlijk; ik hou niet zo van backticks Ik sta niet helemaal alleen in deze strijd, en het is in ieder geval geen ANSI SQL.

[RobIII]

RobIII schreef op maandag 13 oktober 2008 @ 02:19:
[...]


order is een reserved word
_{Alhoewel ik niet weet of MySQL daar over valt; zou niet voor 't eerst zijn als MySQL dat soort dingen doodleuk vreet}

-NMe- schreef op maandag 13 oktober 2008 @ 03:36:
MySQL mag dan gekke dingen doen, maar reserved words pakken als identifiers is niet één van die gekke dingen. Dit is in elk geval de reden dat ik zelf altijd netjes backticks ( ` ) om mijn identifiers heen zet.

pedorus schreef op maandag 13 oktober 2008 @ 14:18:
Ik had het ook niet verwacht, maar het werkt perfect:
[...]

I rest my case
Maar ik ben het wel eens dat je gewoon netjes je identifiers moet specificeren met backticks danwel blokhaken danwel ... afhankelijk van je RDBMS natuurlijk

[ Voor 8% gewijzigd door RobIII op 13-10-2008 14:22 ]

[pedorus]

RobIII schreef op maandag 13 oktober 2008 @ 14:21:
Maar ik ben het wel eens dat je gewoon netjes je identifiers moet specificeren met backticks danwel blokhaken danwel ... afhankelijk van je RDBMS natuurlijk

Waarom zou je dat dan niet uitbreiden naar andere talen? Dus in c# doen we dan bijvoorbeeld dingen als:

C#:

//(we gebruiken altijd @ bij identifiers, wat normaal niet nodig is:)
for (int @i = 0; @i < 10; @i++)
    Console.WriteLine(@i);
for (int @for = 0; @for < 10; @for++)
    Console.WriteLine(@for);

want je weet natuurlijk nooit of "i" ooit een reserved word gaat worden, en reserved words kun je gewoon gebruiken...

Gelukkig hebben ze voor c# het volgende bedacht:

Generally, as new keywords are added to the C# language, they are added as contextual keywords in order to avoid breaking programs written in earlier versions.

En dat zouden ze ook bij MySQL eens moeten bedenken, dan heb je echt geen backticks meer nodig.

[RobIII]

pedorus schreef op maandag 13 oktober 2008 @ 15:20:
Waarom zou je dat dan niet uitbreiden naar andere talen? Dus in c# doen we dan bijvoorbeeld dingen als:

"i" zal niet snel een reserved word worden en, hoe mooi je suggestie ook is, het is al 'eeuwen' goed gebruik om gewoon je fields netjes met backticks/blokhaken te specifyen als je zeker wil weten dat er niets mis gaat. Daarbij kun je natuurlijk ook wel ruiken dan CarDealerID nooit een reserved word zal worden maar iets generieks als "time" dat wel kan worden, danwel zeer grote kanshebber is om al reserved te zijn.

Dat ze by MySQL backticks gebruiken en ergens anders weer blokhaken... tja, da's details; het gaat om het principe.

[.oisyn]

pedorus schreef op maandag 13 oktober 2008 @ 14:18:
Tsja, dat is een kwestie van smaak natuurlijk; ik hou niet zo van backticks Ik sta niet helemaal alleen in deze strijd, en het is in ieder geval geen ANSI SQL.

Sorry hoor, maar die artikelen die je aanhaalt komen geen van allen met valide argumenten waarom dan niet. Nooit gebruiken omdat je ze eventueel kunt vergeten en je dus een gevaarlijke query krijgt (SELECT detele FROM tabel) is kul. Vooral omdat je nu niet weet wat voor keywords er in de toekomst gebruikt gaan worden, dus als je er nu voor kiest om geen keywords als tabel/veldnamen te gebruiken kun je bij de volgende MySQL versie alsnog in de problemen raken. En dat ze het persoonlijk lelijk vinden is nog geen valide reden waarom anderen het niet zouden mogen gebruiken. Future compatibility vind ik best belangrijk.

Kijk, als ze dan zouden zeggen dat ze eigenlijk quotes moesten gebruiken ipv backticks omdat dat meer compatible zou zijn, daar kan ik het dan wel weer mee eens zijn. Maar niemand zegt dat. Ze zeggen allemaal slechts "niet gebruiken", en een enkeling noemt daarbij dan nog "ik vind het lelijk". Ja, lekkere argumentatie weer .

Dus, leuk dat jij er niet alleen in staat, maar de bronnen die je aanhaalt overtuigen me niet bepaald...

offtopic:
en die Herglotzmultimedia blog heeft m'n icon gejat

[ Voor 4% gewijzigd door .oisyn op 13-10-2008 16:11 ]

[pedorus]

.oisyn schreef op maandag 13 oktober 2008 @ 16:09:
dus als je er nu voor kiest om geen keywords als tabel/veldnamen te gebruiken kun je bij de volgende MySQL versie alsnog in de problemen raken.

Daar zouden ze bij MySQL dus iets aan moeten doen, zoals dat bij c# wel gedaan wordt. Nu refereren ze naar nog niet bestaande manuals, daar heb dus je helemaal niks aan...

En dat ze het persoonlijk lelijk vinden is nog geen valide reden waarom anderen het niet zouden mogen gebruiken.

Mee eens. Aan de andere kant vinden dus meer mensen het moeilijker lezen of zien ze andere nadelen. Als ik naar mijn eigen stukje c#-code hierboven kijk, dan denk ik ook eerst van WTF. Gelukkig is dat soort c#-code niet nodig.

Future compatibility vind ik best belangrijk.

Ik ook, daarom vind ik het ook erg jammer dat je bij MySQL backticks nodig hebt om dat met volledige zekerheid te bereiken. In de toekomst krijg je daar dan misschien juist weer problemen mee omdat dat niet standaard is... Kortom, er is nu geen eenduidige goede oplossing voor dit probleem.

Kijk, als ze dan zouden zeggen dat ze eigenlijk quotes moesten gebruiken ipv backticks omdat dat meer compatible zou zijn, daar kan ik het dan wel weer mee eens zijn. Maar niemand zegt dat.

pedorus schreef op maandag 13 oktober 2008 @ 14:18:
alleen

[NMe]

pedorus schreef op maandag 13 oktober 2008 @ 16:36:
[...]

Daar zouden ze bij MySQL dus iets aan moeten doen, zoals dat bij c# wel gedaan wordt. Nu refereren ze naar nog niet bestaande manuals, daar heb dus je helemaal niks aan...

Hee, wat gek nou...zouden ze misschien daarom die backticks verzonnen hebben?

Ik ook, daarom vind ik het ook erg jammer dat je bij MySQL backticks nodig hebt om dat met volledige zekerheid te bereiken. In de toekomst krijg je daar dan misschien juist weer problemen mee omdat dat niet standaard is... Kortom, er is nu geen eenduidige goede oplossing voor dit probleem.

De kans dat MySQL support voor backticks weghaalt omdat het geen standaard is lijkt me nihil.

[pedorus]

-NMe- schreef op maandag 13 oktober 2008 @ 16:52:
Hee, wat gek nou...zouden ze misschien daarom die backticks verzonnen hebben?

Als ze echt willen dat je altijd backticks gebruikt, waarom zie je het dan niet in de manual, bijvoorbeeld bij de examples?

Dit hebben ze verzonnen voor het gebruik van reserved words als namen, niet voor future compatibility. Anders zouden ze dat toch wel in de manual hebben gezet, in plaats van te refereren naar toekomstige manuals?

De kans dat MySQL support voor backticks weghaalt omdat het geen standaard is lijkt me nihil.

Dat hoeft van mij ook niet. Ik vind alleen dat ze moeten stoppen met het verzinnen van nieuwe reserved words. Ze moeten gewoon over gaan naar contextual keywords. Het woord gereserveerd zegt het eigenlijk al. Slechte vergelijking: Als je in een hotel een kamer in gebruik hebt, dan sta je toch mooi te kijken als diezelfde kamer in planning 2.0 door iemand anders met hogere prioriteit gereserveerd wordt.

[Cartman!]

Nieuwe features brengen logischerwijs soms nieuwe reserved words met zich mee. Naar jou idee hadden ze bij MySQL na de eerste release moeten stoppen

[pedorus]

Cartman! schreef op maandag 13 oktober 2008 @ 17:45:
Nieuwe features brengen logischerwijs soms nieuwe reserved words met zich mee. Naar jou idee hadden ze bij MySQL na de eerste release moeten stoppen

Ik kan me niet herinneren dat de evolutie van c# gestopt is sinds ze gestopt zijn met het toevoegen van nieuwe reserved words... Een alsnog gereserveerd woord als "MASTER_HEARTBEAT_PERIOD" is echt niet nodig, dat kun je prima met een contextual keyword redden.

[RobIII]

pedorus schreef op maandag 13 oktober 2008 @ 18:06:
[...]

Ik kan me niet herinneren dat de evolutie van c# gestopt is sinds ze gestopt zijn met het toevoegen van nieuwe reserved words... Een alsnog gereserveerd woord als "MASTER_HEARTBEAT_PERIOD" is echt niet nodig, dat kun je prima met een contextual keyword redden.

C#:

int null;

Werkt niet. Lekker contextueel

quote: http://msdn.microsoft.com/en-us/library/x53a06bb.aspx

A contextual keyword is used to provide a specific meaning in the code, but it is not a reserved word in C#. Some contextual keywords, such as partial and where, have special meanings in two or more contexts.

[ Voor 23% gewijzigd door RobIII op 13-10-2008 18:16 ]

[NMe]

pedorus schreef op maandag 13 oktober 2008 @ 17:18:
[...]

Als ze echt willen dat je altijd backticks gebruikt, waarom zie je het dan niet in de manual, bijvoorbeeld bij de examples?

Omdat jij als developer ook moet kunnen verzinnen dat sommige dingen gewoon beter werken dan andere. Waarom moeten ze alles voorkauwen?

Dit hebben ze verzonnen voor het gebruik van reserved words als namen, niet voor future compatibility. Anders zouden ze dat toch wel in de manual hebben gezet, in plaats van te refereren naar toekomstige manuals?

Het is gewoon een bijkomend voordeel, intended of niet.

Dat hoeft van mij ook niet. Ik vind alleen dat ze moeten stoppen met het verzinnen van nieuwe reserved words. Ze moeten gewoon over gaan naar contextual keywords. Het woord gereserveerd zegt het eigenlijk al. Slechte vergelijking: Als je in een hotel een kamer in gebruik hebt, dan sta je toch mooi te kijken als diezelfde kamer in planning 2.0 door iemand anders met hogere prioriteit gereserveerd wordt.

Leuk ja. Alleen werkt dat niet zonder meer altijd, zoals RobIII ook al aangeeft. Er zijn altijd voorbeelden te bedenken waar een context ambigu is en je dus net zo goed vast zit aan een oplossing zoals met backticks. 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.

[RobIII]

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.

[ Voor 30% gewijzigd door RobIII op 13-10-2008 18:28 ]

[pedorus]

-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#:

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.

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

[NMe]

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#:

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.

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.

[winkbrace]

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

[RobIII]

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.

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

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.

[ Voor 21% gewijzigd door RobIII op 13-10-2008 22:25 ]

[winkbrace]

* winkbrace 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.

[RobIII]

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

Er is een edit knop ( ) bovenaan je post

[ Voor 17% gewijzigd door RobIII op 13-10-2008 23:05 ]

[winkbrace]

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

[RobIII]

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

[ Voor 16% gewijzigd door RobIII op 13-10-2008 23:25 ]

[pedorus]

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

[Alain]

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.

[NMe]

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.

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.

[Voutloos]

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

[Niekk]

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.

[NMe]

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.

[Alain]

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

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.

[pedorus]

@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.

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.

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.