[sql of php]

[ErwinPeters]

ik heb probleempje met een insert hier (lijkt het):

mijn code returned:

"Errant query: INSERT INTO phones (key, account_id, type) VALUES ('TheKey', 1, 1)"

de code die ik heb is:

PHP:

<?php session_start();

    $link = mysql_connect('localhost','xxxx','xxxx') or die('Cannot connect to the DB');

    mysql_select_db('xxxx',$link) or die('Cannot select the DB');
    $query = "SELECT cndts_id, cndts_email, cndts_passwd FROM candidates WHERE cndts_email = \"".$_POST['user']."\" ORDER BY cndts_id DESC";
    $result = mysql_query($query,$link) or die('Errant query:  '.$query);
    if(mysql_num_rows($result)) {
        
        $user = mysql_fetch_assoc($result);
    }

    if($user['cndts_email'] == $_POST['user'] && $user['cndts_passwd'] == md5($_POST['pass'])){
        mysql_select_db('xxxx',$link) or die('Cannot select the DB');
        $query = "INSERT INTO phones (key, account_id, type) VALUES ('".$_POST['key']."', ".$_POST['account_id'].", ".$_POST['type'].")";
        mysql_query($query,$link) or die('Errant query:  '.$query);
        
        //response
        $response = array(
            1 => 1,
            2 => "Het apparaat is nu gekoppeld aan uw account.",
            3 => "Ok"
        );
        
        header('Content-type: application/json');
        echo json_encode($response);
    
    }else{
        $response = array(
            1 => 2,
            2 => "Er is geen geldige gebruikersnaam en wachtwoord opgegeven",
            3 => "Ok"
        );
        
        header('Content-type: application/json');
        echo json_encode($response);
    }
?>

Ik heb geen idee wat ik fout doe en zou graag jullie input waarderen. Mijn query lijkt in orde (zelfde resultaat als ik deze uitwissel met die uit phpmyadmin met hardcoded values) en de informatie in $link lijkt ook niet fout te zijn omdat die het bij de authenticatie wel doet.

Heeft iemand gedachtes, ideeën of ziet die meteen mijn fout? Ik hoor het graag.

[orf]

Zet even [code=php][/] om je PHP code heen. Dat maakt het wat leesbaarder.

Al vast wat punten:
- je escaped je input niet
- je doet een echo van je query bij een fout en toont die dus aan je bezoeker.

Voor jezelf kun je beter even (tijdens het testen) even de mysql error tonen in plaats van alleen de query.

[MetalfanBlackness]

Ik zou in ieder geval gebruik maken van prepared statements gebruken voor je queries, want dit geeft veel ruimte voor SQL injection.

[Hydra]

Als je die query uitvoert via de mysql command line tool / een GUI SQL tool, werkt hij dan wel? Normaal staat er in een foutmelding ook wat er fout is aan een query.

[Reinier]

Je mist volgens mij een mysql_free_result vóór je tweede query. Nouja, dan gaat het nog niet werken, maar het is volgens mij een hint in de goede richting

[ Voor 42% gewijzigd door Reinier op 02-01-2014 13:56 ]

[Merethil]

Misschien een uppercase/lowercase probleem? Ik weet dat MySQL case-sensitive is, misschien daar een probleem?
Of is het gewoon dat je in je INSERT INTO ([parameters]) deze `` haakjes mist?

[jarrin]

Vervang eens

PHP:

$result = mysql_query($query,$link) or die('Errant query: '.$query);

naar

PHP:

$result = mysql_query($query,$link) or die(mysql_error());

[Verwijderd]

Ik zou in ieder geval al gebruik gaan maken van Prepared Statements, dan zal je die onzin in verband met aanhalingstekens al niet meer tegen komen.

offtopic:
Hoe sla je je wachtwoorden op? Enkel een md5 hash maken is niet voldoende hoor

[NMe]

Key is een reserved word.

[HuHu]

Verwijderd schreef op donderdag 02 januari 2014 @ 13:54:
Ik zou in ieder geval al gebruik gaan maken van Prepared Statements, dan zal je die onzin in verband met aanhalingstekens al niet meer tegen komen.

offtopic:
Hoe sla je je wachtwoorden op? Enkel een md5 hash maken is niet voldoende hoor

Lost dat het probleem op van het gebruiken van een reserved word in de query? Volgens mij niet.

[Hydra]

HuHu schreef op donderdag 02 januari 2014 @ 14:07:
Lost dat het probleem op van het gebruiken van een reserved word in de query? Volgens mij niet.

Want jij had 'em wel door voordat NME 'em spotte?

[basst85]

Ik zou dan de kolomnamen veranderen in bijvoorbeeld PhoneKey, PhoneAccountId, en PhoneType.

[HuHu]

Hydra schreef op donderdag 02 januari 2014 @ 14:15:
[...]


Want jij had 'em wel door voordat NME 'em spotte?

Ik vermoedde het, want ik heb die fout zelf ook wel eens gemaakt en ben er sindsdien wat alerter op. Ik dacht alleen ook dat "type" een reserved word was, maar dat is niet zo zag ik.

basst85 schreef op donderdag 02 januari 2014 @ 14:22:
Ik zou dan de kolomnamen veranderen in bijvoorbeeld PhoneKey, PhoneAccountId, en PhoneType.

Dat vind ik stom. Het zit al in de tabel "phones", dan hoef je niet ook nog overal het woord "phone" te gaan vermelden. Dat is nogal dubbelop. Het toevoegen van backticks ( ` ) om de kolomnamen verhelpt het probleem.

[ Voor 37% gewijzigd door HuHu op 02-01-2014 14:24 ]

[Verwijderd]

HuHu schreef op donderdag 02 januari 2014 @ 14:07:
[...]

Lost dat het probleem op van het gebruiken van een reserved word in de query? Volgens mij niet.

Neen, maar ik probeer advies te geven zodat andere fouten vermeden kunnen worden.

[Verwijderd]

Kijk eens naar http://dev.mysql.com/doc/...ble-reserved-words-5.5.36
Daar vind je alle keywords van MySQL

Het is zoiezo een goed idee om de tabel- en kolomnamen in backticks te zetten, vind ik althans.

<rant>
Ik zou wel kijken naar PDO of MySQLi. Little Bobby Tables komt anders misschien op bezoek.
</rant>

[NMe]

Sowieso is dat "or die" niet echt handig. Er zijn maar héél weinig problemen waar je acuut wil stoppen met het uitvoeren van je pagina. Het mislukken van een connect met de DB of het selecten van een catalog valt daar IMO niet onder: als je databaseserver down is hoor je een error 500 te gooien.

Verwijderd schreef op donderdag 02 januari 2014 @ 14:37:
Het is zoiezo een goed idee om de tabel- en kolomnamen in backticks te zetten, vind ik althans.

Ik niet. Als je ooit je systeem omzet van MySQL naar een ander DBMS kun je al je query's na gaan lopen. Ik vermijd backticks waar mogelijk en gebruik ze alleen waar er geen alternatieve naamgeving mogelijk is binnen mijn naming scheme.

<rant>
Ik zou wel kijken naar PDO of MySQLi. Little Bobby Tables komt anders misschien op bezoek.
</rant>

Hoewel je advies goed is, is er ook prima tegen SQL-injectie te beveiligen zonder PDO, MySQLi, enz.

[Verwijderd]

NMe schreef op donderdag 02 januari 2014 @ 14:41:
Hoewel je advies goed is, is er ook prima tegen SQL-injectie te beveiligen zonder PDO, MySQLi, enz.

Dat is zeker zo, het is echter wel een goed idee dat hij dat doet gezien de MySQL extensie deprecated is per PHP 5.5 en die bescherming hoef je niet per se in te bouwen als je MySQLi of PDO hebt.

[HuHu]

NMe schreef op donderdag 02 januari 2014 @ 14:41:

[...]

Ik niet. Als je ooit je systeem omzet van MySQL naar een ander DBMS kun je al je query's na gaan lopen. Ik vermijd backticks waar mogelijk en gebruik ze alleen waar er geen alternatieve naamgeving mogelijk is binnen mijn naming scheme.

Dat is wel een hele specifieke use-case. Als je daar rekening mee wilt houden, dan kun je volgens mij beter een query-builder gebruiken. Dan hoef je (bijna) niets aan te passen als je van DBMS veranderd.

[basst85]

HuHu schreef op donderdag 02 januari 2014 @ 14:23:
[...]
[...]

Dat vind ik stom. Het zit al in de tabel "phones", dan hoef je niet ook nog overal het woord "phone" te gaan vermelden. Dat is nogal dubbelop. Het toevoegen van backticks ( ` ) om de kolomnamen verhelpt het probleem.

Dat kun je stom vinden, maar zulke kolom "prefixes" worden wel vaker gebruikt.
Ook handig om te achterhalen welke kolommen gebruikt worden binnen een FK's, want dan krijg je bijvoorbeeld "PhoneBrandId" (welke verwijst naar de kolom BrandId binnen de tabel Brands) .

[HuHu]

basst85 schreef op donderdag 02 januari 2014 @ 14:59:
[...]


Dat kun je stom vinden, maar zulke kolom "prefixes" worden wel vaker gebruikt.
Ook handig om te achterhalen welke kolommen gebruikt worden binnen een FK's, want dan krijg je bijvoorbeeld "PhoneBrandId" (welke verwijst naar de kolom BrandId binnen de tabel Brands) .

Bij een FK is het dan ook logisch. Want het "id" is van de "brand" en niet van de "phone", dus "brand_id". Maar je gaat niet de tabel Phone een PK phone_id geven, en een phone_model, phone_name, phone_brand_id, enz... Dat worden dus id, model, name en brand_id. Zonder iedere keer "phone" te herhalen, want zo heet de tabel al.

[stane]

PHP:

$query = "INSERT INTO phones (key, account_id, type) VALUES ('".$_POST['key']."', ".$_POST['account_id'].", ".$_POST['type'].")";

naar

PHP:

$query = "INSERT INTO phones (key, account_id, type) VALUES ('".mysql_real_escape_string($_POST['key'])."', '".mysql_real_escape_string($_POST['account_id'])."', '".mysql_real_escape_string($_POST['type'])."')";

En die mysql_error() correct laten tonen zoals hierboven al staat.

[NMe]

Daarmee los je de foutmelding niet op, wél het gapende SQL-injectiegat.

Een nettere manier van foutafhandeling is trouwens iets als dit:

PHP:

class DatabaseConnectionException extends Exception { }
class DatabaseSelectionException extends Exception { }
class ContentNotFoundException extends Exception { }

// ...

try {
    if (!($link = mysqli_connect(...)))
        throw new DatabaseConnectionException();
    if (!mysqli_select_db(...))
        throw new DatabaseSelectionException();
    $result = mysqli_query('SELECT ... FROM ...');
    if (!($record = mysqli_fetch_object(...)))
        throw new ContentNotFoundException();
    // daadwerkelijke logica hier
} catch (ContentNotFoundException $e) {
    // zet 404-header en pass het errortemplate
} catch (DatabaseConnectionException $e) {
    // zet 500-header en pass het errortemplate
} catch (DatabaseSelectionException $e) {
    // zet 500-header en pass het errortemplate
} catch (Exception $e) {
    // pass het (generieke) errortemplate
}

Even uit de losse pols en natuurlijk niet helemaal zuiver opgezet, maar op deze manier kan je gewoon door blijven programmeren en het daadwerkelijk afhandelen van fouten doen op één plek.

[Hydra]

basst85 schreef op donderdag 02 januari 2014 @ 14:59:
Dat kun je stom vinden, maar zulke kolom "prefixes" worden wel vaker gebruikt.

Dat dingen in de PHP wereld vaak zo gedaan worden is geen argument waarom het tegen best practices in zou gaan

[PatrickH89]

Hydra schreef op donderdag 02 januari 2014 @ 15:46:
[...]


Dat dingen in de PHP wereld vaak zo gedaan worden is geen argument waarom het tegen best practices in zou gaan

Maar daar heb je natuurlijk gelijk in

[ Voor 8% gewijzigd door PatrickH89 op 02-01-2014 15:50 ]

[NMe]

Hydra schreef op donderdag 02 januari 2014 @ 15:46:
[...]

Dat dingen in de PHP wereld vaak zo gedaan worden is geen argument waarom het tegen best practices in zou gaan

Heeft niks met PHP te maken (if anything, eerder met MySQL). Een specifieke soort naamgeving best practice noemen vind ik trouwens wat overdreven. Ik herhaal de tabelnaam ook niet graag in veldnamen maar soms heb ik daar een goede reden voor, bijvoorbeeld als ik weet dat ik continu twee tabellen met elkaar loop te joinen en dan twee velden nodig heb die beiden eenzelfde naam zouden hebben volgens jouw "best practice". Ik doe dan liever op tabelniveau wat aan de naamgeving dan dat ik steeds moet lopen aliassen. Nouja, tegenwoordig lost Doctrine dat voor me op, maar dat is een ander verhaal.

[kluyze]

Een andere tip, de TS doet het niet maar andere voorbeelden in het topic wel. Mijn ervaring leert me dat het niet altijd een goed idee is om in een (mysql) database gebruik te maken van camelcase. Het probleem zit er in dat niet elk OS/filesystem case sensitive is en bv. bij migreren van een (locale) development omgeving in Windows naar een productieomgeving in Linux kan dit problemen geven.

[MueR]

HuHu schreef op donderdag 02 januari 2014 @ 14:23:
Dat vind ik stom. Het zit al in de tabel "phones", dan hoef je niet ook nog overal het woord "phone" te gaan vermelden. Dat is nogal dubbelop. Het toevoegen van backticks ( ` ) om de kolomnamen verhelpt het probleem.

Leesbaarheid van je code is nogal wat waard imho. Liever PhoneId, PhoneName en PhoneAccountId (ok, deze vind ik dubieus), dan in 30 tabellen een "id" en "name" veld. Dat maakt joins een nachtmerrie, helemaal voor een ander die even in dat stuk code moet zijn.

[ Voor 5% gewijzigd door MueR op 03-01-2014 00:31 ]

[HuHu]

MueR schreef op vrijdag 03 januari 2014 @ 00:31:
[...]

Leesbaarheid van je code is nogal wat waard imho. Liever PhoneId, PhoneName en PhoneAccountId (ok, deze vind ik dubieus), dan in 30 tabellen een "id" en "name" veld. Dat maakt joins een nachtmerrie, helemaal voor een ander die even in dat stuk code moet zijn.

Dan verschillen we van mening. Bedoel je met "code" overigens iets als PHP-code of een SQL-query?

In het eerste geval werk je (gokje) vaak met objecten en heb je dus dingen als: $phone->id, $phone->name en $phone->account->id. Dat vind ik zelf beter dan $phone->phoneId, $phone->phoneName en $phone->phoneAccount->accountId.

In het geval van een SQL-query zet je gewoon overal de tabelnaam voor: SELECT phone.id, phone.name FROM phone. Lijkt me net zo leesbaar als SELECT phoneId, phoneName FROM phone en beter dan SELECT phone.phoneId, phone.phoneName FROM phone.

[Hydra]

MueR schreef op vrijdag 03 januari 2014 @ 00:31:
[...]

Leesbaarheid van je code is nogal wat waard imho. Liever PhoneId, PhoneName en PhoneAccountId (ok, deze vind ik dubieus), dan in 30 tabellen een "id" en "name" veld. Dat maakt joins een nachtmerrie, helemaal voor een ander die even in dat stuk code moet zijn.

Ja, want phone.id is natuurlijk niet te onderscheiden van person.id.

Oftwel: onzin Zowel in m'n huidige als m'n vorige baan gaat dit ook tegen de afspraken die we daarover gemaakt hebben in. Zelfde geldt voor je objectstructuur; je gaat een Person class ook geen PersonName en PersonDob properties geven hoop ik?

[Woy]

Hoewel ik het zelf ook mooier vind om de tabelnaam niet te herhalen in de veldnamen is het natuurlijk maar afhankelijk van wat de conventies van het bedrijf zijn. Consistentie is het belangrijkste, dus niet in de ene tabel/veld het ene en bij de ander wat anders.

[MueR]

Hydra schreef op vrijdag 03 januari 2014 @ 09:34:
[...]


Ja, want phone.id is natuurlijk niet te onderscheiden van person.id. Oftwel: onzin

Als je dit in dezelfde query uit mysql haalt is het inderdaad niet te onderscheiden. Dan moet je al gaan aliassen. Dus nee, geen onzin

Zowel in m'n huidige als m'n vorige baan gaat dit ook tegen de afspraken die we daarover gemaakt hebben in.

Want zodra jij daar een afspraak over gemaakt hebt is het wet? Bij ons is het conventie om een id vooral niet "ID" te noemen in de database, maar altijd <tabelnaam>Id. Bij de overige velden is het over het algemeen vrije interpretatie.

Zelfde geldt voor je objectstructuur; je gaat een Person class ook geen PersonName en PersonDob properties geven hoop ik?

In objecten kan je dat allemaal netjes oplossen. In MySQL niet. Alle alternatieven zijn net zo prut. Aliassen is vervelend, de tabelnaam overal voor mikken is helemaal overbodig verbose.

Ik lees in SQL liever dit:

SQL:

SELECT [velden] FROM Phone p
JOIN Account a ON a.AccountId = p.AccountId

dan dit:

SQL:

SELECT [velden] FROM Phone
JOIN Account a ON Account.Id = Phone.Id

of dit (helemaal crap lezen):

SQL:

SELECT [velden] FROM Phone p
JOIN Account a ON a.Id = p.Id

[NMe]

kluyze schreef op vrijdag 03 januari 2014 @ 00:25:
Een andere tip, de TS doet het niet maar andere voorbeelden in het topic wel. Mijn ervaring leert me dat het niet altijd een goed idee is om in een (mysql) database gebruik te maken van camelcase. Het probleem zit er in dat niet elk OS/filesystem case sensitive is en bv. bij migreren van een (locale) development omgeving in Windows naar een productieomgeving in Linux kan dit problemen geven.

Dit heeft volgens mij niks met Windows of Linux te maken maar met de collatie van je database? Daarbij: hetzelfde kan gezegd worden over code; zelfs in PHP zijn een aantal dingen case sensitive. Zullen we dan maar alles in kleine letters schrijven om fouten te voorkomen?

Ik ben in elk geval heel blij dat wij op kantoor camelcasing gebruiken in onze SQL-namingconvention, want dat leest tien keer makkelijker.

Hydra schreef op vrijdag 03 januari 2014 @ 09:34:
[...]

Ja, want phone.id is natuurlijk niet te onderscheiden van person.id.

En vervolgens mag je aliassen gaan gebruiken in elke query waar je meer dan één ID gaat ophalen.

[Woy]

Ik snap jullie aversie tegen het gebruik van aliassen niet echt. Ik persoonlijk gebruik sowieso altijd aliassen, dat voorkomt bijvoorbeeld ook fouten als er later nog eens een veld in een tabel toegevoegd word ( Die dezelfde naam heeft als een ander veld ). Tevens ziet het er IMHO consistenter uit dan wanneer je soms wel en soms geen aliassen gebruikt.

Ook het wisselend gebruiken van table prefixen komt mij als nogal inconsistent over. Voor het ID veld kan ik er nog wel in meegaan ( Hoewel ik het zelf niet doe ), maar arbitrair kiezen of een veld wel of geen prefix krijgt vind ik een minder goede conventie

[ Voor 33% gewijzigd door Woy op 03-01-2014 13:55 ]

[HuHu]

NMe schreef op vrijdag 03 januari 2014 @ 13:45:

[...]

En vervolgens mag je aliassen gaan gebruiken in elke query waar je meer dan één ID gaat ophalen.

Ik gebruik liever één keer een (nodige) alias, dan talloze keren een (onnodige) prefix.

[Hydra]

NMe schreef op vrijdag 03 januari 2014 @ 13:45:
En vervolgens mag je aliassen gaan gebruiken in elke query waar je meer dan één ID gaat ophalen.

En?

[NMe]

HuHu schreef op vrijdag 03 januari 2014 @ 13:52:
[...]

Ik gebruik liever één keer een (nodige) alias, dan talloze keren een (onnodige) prefix.

Bij vaak voorkomende joins is het precies andersom.

Hydra schreef op vrijdag 03 januari 2014 @ 15:36:
[...]

En?

En ik vind dat vervelend, en met mij nog een aantal andere mensen. Ik zeg ook niet dat je het op mijn manier moet doen, ik verzet me alleen tegen het feit dat je beweert dat het best practice is om het op jouw manier te doen, en dat is gewoon niet zo. Naming schemes zijn persoonlijk en dus per persoon, team of bedrijf anders.

[Creepy]

NMe schreef op vrijdag 03 januari 2014 @ 13:45:
En vervolgens mag je aliassen gaan gebruiken in elke query waar je meer dan één ID gaat ophalen.

Ik snap deze opmerking totaal niet. Zelfs niet met een smiley erachter. Jij moet namelijk altijd de "alias" typen. Je noemt het alleen een prefix.

Maar inderdaad: het is gewoon persoonlijke voorkeur. Mij zal het een worst zijn verder welke van de twee ik moet gebruiken.

[ Voor 15% gewijzigd door Creepy op 03-01-2014 16:53 ]

[NMe]

Creepy schreef op vrijdag 03 januari 2014 @ 16:52:
[...]

Ik snap deze opmerking totaal niet. Zelfs niet met een smiley erachter. Jij moet namelijk altijd de "alias" typen. Je noemt het alleen een prefix.

Het verschil is dat je bij het gebruik van een alias hetzelfde veld de ene keer in je code aanspreekt met "Name" en de andere keer met "CompanyName" omdat je toevallig ook een "ContactName" of iets dergelijks hebt. Je loopt minder risico op inconsistenties als je dit in je naamgeving opvangt. Maar uiteraard wordt ook dat met goede ORM opgelost.

[Hydra]

NMe schreef op vrijdag 03 januari 2014 @ 15:58:
En ik vind dat vervelend, en met mij nog een aantal andere mensen. Ik zeg ook niet dat je het op mijn manier moet doen, ik verzet me alleen tegen het feit dat je beweert dat het best practice is om het op jouw manier te doen, en dat is gewoon niet zo. Naming schemes zijn persoonlijk en dus per persoon, team of bedrijf anders.

Ik heb nog geen enkel professioneel bedrijf alle kolommen zien prefixen met de tabelnaam. De naamgeving van objecten netjes doortrekken naar je tabel- en kolomnamen lijkt me hoe dan ook weldegelijk een "best practice". Daarbij heb ik ff zitten rondzoeken op o.a. SO en voor zover ik kan zien is het niet prefixen van kolomnamen een beetje de algemeen geaccepteerde standaard.

Maar als jij 't graag anders wil doen, be my guest. Wees dat speciale sneeuwvlokje!

NMe schreef op vrijdag 03 januari 2014 @ 17:18:
Het verschil is dat je bij het gebruik van een alias hetzelfde veld de ene keer in je code aanspreekt met "Name" en de andere keer met "CompanyName" omdat je toevallig ook een "ContactName" of iets dergelijks hebt. Je loopt minder risico op inconsistenties als je dit in je naamgeving opvangt. Maar uiteraard wordt ook dat met goede ORM opgelost.

Vind ik nog steeds nergens op slaan. In plaats van dat je de enkele keer dat er een conflict is een alias gebruikt, gebruik je in jouw geval altijd een alias, direct in de kolomnaam.

[ Voor 26% gewijzigd door Hydra op 03-01-2014 17:24 ]

[NMe]

Waar zeg ik precies "alle kolomnamen"? En kap eens met dat autoritaire gesneer van je, is je al vaker gezegd.

[Hydra]

NMe schreef op vrijdag 03 januari 2014 @ 17:23:
Waar zeg ik precies "alle kolomnamen"? En kap eens met dat autoritaire gesneer van je, is je al vaker gezegd.

Dus je gaat inconsequente naamgevingen hanteren? 'T wordt steeds beter

En dat van dat sneeuwvlokje was gewoon een geintje, komop man!

[Gomez12]

Hydra schreef op vrijdag 03 januari 2014 @ 17:25:
[...]


Dus je gaat inconsequente naamgevingen hanteren? 'T wordt steeds beter

En dat van dat sneeuwvlokje was gewoon een geintje, komop man!

Tja, wat noem je inconsequent wordt dan de vraag...

Persoonlijk prefix ik altijd id (dat is dus wel consequent) en afhankelijk van het model kan ik ook nog besluiten om (over het hele model) andere te prefixen (name is bijv eentje die ik bijna altijd prefix)

Dus jij kan het inconsequent vinden dat ik zeg : personname / firstname / lastname maar ik vind het consequent zolang ik het voor dat veld het maar doe binnen het hele domeinmodel.

Hoe zou jij bijv de volgende situatie doen :
- 1 persoons pagina
- 1 lijst met persoonsnamen en bedrijven
- 1 bedrijfspagina.

Ik heb hier geen probleem mee, omdat ik gewoon overal een personname / companyname heb dus ook binnen de lijst heten mijn velden nog hetzelfde. Hoe wil jij dit gaan doen zodat je het consequent houdt? Alles op een persoonspagina gaan aliassen zodat je overal in je code consequente namen hebt, of heb jij enkel in je dbase consequente namen en in je code gewoon een ratjetoe (net naargelang of er meerdere name-velden op een lijst moeten komen of niet)

Natuurlijk creeer ik ook een ratjetoe op een gegeven moment (zou ik dit niet willen dan moet ik alles prefixen en dat is me nu net even te veel onzinnig werk) alleen ik denk dat ik in beginsel >80% van mijn lijsten zou produceren zonder 1 alias nodig te hebben.
Zou kunnen produceren vanwege het feit dat er een ORM tussen zit waardoor ik er helemaal geen last van heb, maar oude gewoontes sterven moeilijk en ik vind het ook nog handig als ik even een handmatige sql query moet bouwen om iets te checken oid, dus we gaan uit van de situatie zonder ORM

[kluyze]

NMe schreef op vrijdag 03 januari 2014 @ 13:45:
[...]

Dit heeft volgens mij niks met Windows of Linux te maken maar met de collatie van je database?

http://dev.mysql.com/doc/...ier-case-sensitivity.html

In MySQL, databases correspond to directories within the data directory. Each table within a database corresponds to at least one file within the database directory (and possibly more, depending on the storage engine). Consequently, the case sensitivity of the underlying operating system plays a part in the case sensitivity of database and table names. This means database and table names are not case sensitive in Windows, and case sensitive in most varieties of Unix. One notable exception is Mac OS X, which is Unix-based but uses a default file system type (HFS+) that is not case sensitive. However, Mac OS X also supports UFS volumes, which are case sensitive just as on any Unix.

Net even getest, een schema 'test' met latin1 - latin1_general_cs en latin1_general_ci getest en een table 'testCamel' op zowel een ubuntu als windows mysql server.

SQL:

SELECT * FROM testcamel;

geeft op de windows mysql server een resultaat, op de ubuntu mysql server blijft deze aangeven dat de tabel niet bestaat.

[Creepy]

NMe schreef op vrijdag 03 januari 2014 @ 17:23:
Waar zeg ik precies "alle kolomnamen"?

He kom op, je begint zelf over inconsistenties en dan ga je van te voren gokken of een kolomnaam in de toekomst een keer gaat clashen en dus gaat prefixen. Sorry, maar dan snijd je argument tegen aliases niet echt veel hout.

Nogmaals: mij zal het een worst zijn maar ik zie een hoop argumenten over en weer gaann die niet kloppen of die opgaan voor beide oplossingen

[Janoz]

Ja, ik ga prefixen want PhoneId is veel makkelijker tikken dan Phone.id ... oh wacht......

MueR schreef op vrijdag 03 januari 2014 @ 13:09:
[...]

Als je dit in dezelfde query uit mysql haalt is het inderdaad niet te onderscheiden. Dan moet je al gaan aliassen. Dus nee, geen onzin

Tja, als je met select * werkt is dat zo . Benoem je alle kolommen dan staan ze precies in de volgorde die je verwacht en kun je in je rowmapper desnoods gewoon met index werken.

Ik lees in SQL liever dit:

SQL:

SELECT [velden] FROM Phone p
JOIN Account a ON a.AccountId = p.AccountId

dan dit:

SQL:

SELECT \[velden] FROM Phone
JOIN Account a ON Account.Id = Phone.Id

of dit (helemaal crap lezen):

SQL:

SELECT \[velden] FROM Phone p
JOIN Account a ON a.Id = p.Id

Doe mij maar gewoon de laatste. Met eventueel iets meer letters voor de tabel alias als het mogelijk onduidelijker wordt.

Maar goed, ik heb makkelijk praten. Mijn queries staan over het algemeen netjes bij elkaar in ormQueries.xml

[ErwinPeters]

Damn wat een rommel schreef ik vroeger. $_POST in de query echoen is echt not done. Blij dat ik nu beter weet. Mochten mensen hier nog nachtmerries van hebben, dit was maar voor een leerprojectje.

[Groentjuh]

ErwinPeters schreef op donderdag 17 mei 2018 @ 11:46:
Damn wat een rommel schreef ik vroeger. $_POST in de query echoen is echt not done. Blij dat ik nu beter weet. Mochten mensen hier nog nachtmerries van hebben, dit was maar voor een leerprojectje.

Toen ik het zag dacht ik gelijk: AAAAHHH! mysql_connect! Toen pas keek ik naar de datum en dacht ik, oh in 2014 was dat er nog wel misschien nog wel!

Ja, 4 jaar oude code is veelal troep. Hoewel als het 'goed' is geschreven hoeft het zelfs vandaag niet onveilig te zijn. md5 als password hash is natuurlijk not-done nu.

[RobIII]

We schreven vroeger allemaal bagger

Laat ik deze oude koe dan maar begraven voordat 'ie nog vaker uit de sloot getrokken wordt

Groentjuh schreef op donderdag 17 mei 2018 @ 11:52:
md5 als password hash is natuurlijk not-done nu.

Dat was 't in 2014 ook al

[ Voor 35% gewijzigd door RobIII op 17-05-2018 11:55 ]