MySQL Windows -&gt; Linux

dinsdag 29 januari 2008 20:04

Aangezien je toch moet migreren:
-Dump alles naar sql
-Voer wat find en replace dingen uit op je sql file
-Import sql file

Na betaling van een licentievergoeding van €1.000 verkrijgen bedrijven het recht om deze post te gebruiken voor het trainen van artificiële intelligentiesystemen.

Acties:

Y0ur1

Daarom is het altijd goed om dit soort dingen vooraf vast te leggen, best practice in een db is mijns inziens gewoon alles lower case.

dinsdag 29 januari 2008 20:37

Acties:

rogierslag

With ^^^^

Nu ben je namelijk helemaal niet voorbereid op een verandering van je omgeving.

Bij het programmeren is het heel belangrijk van tevoren hierover goed na te denken, dan loop je later niet tegen dergelijke problemen aan. Tip voor je volgende projectje ;p

woensdag 30 januari 2008 00:23

Acties:

woensdag 30 januari 2008 15:31

Y0ur1 schreef op dinsdag 29 januari 2008 @ 20:04:
Daarom is het altijd goed om dit soort dingen vooraf vast te leggen, best practice in een db is mijns inziens gewoon alles lower case.

Niet mee eens, als je een consistente tabelnaamgeving aanhoudt is camelcase juist veel overzichtelijker. Een probleem zou ik het al helemaal niet noemen, 't is een simpele config instelling.

Overigens knal ik die case sensitivity altijd uit, 't levert meer gezeur op dan nette code in mijn ervaring. Dan probeer ik liever mijn collega's zover te krijgen dat ze overal backticks omheen zetten

[ Voor 7% gewijzigd door FragFrog op 30-01-2008 00:24 ]

[ Site ] [ twitch ] [ jijbuis ]

Acties:

Y0ur1

FragFrog schreef op woensdag 30 januari 2008 @ 00:23:
[...]

Niet mee eens, als je een consistente tabelnaamgeving aanhoudt is camelcase juist veel overzichtelijker. Een probleem zou ik het al helemaal niet noemen, 't is een simpele config instelling.

Overigens knal ik die case sensitivity altijd uit, 't levert meer gezeur op dan nette code in mijn ervaring. Dan probeer ik liever mijn collega's zover te krijgen dat ze overal backticks omheen zetten

Tja als je je bedenkt dat alles in een beetje linuxomgeving case-sensitive is dan vind ik het wel ranzig

Ik gebruik ipv camelcase altijd underscores om het overzichtelijk te houden. Maarja het is allemaal maar net wat je afspreekt, het belangrijkste is dat je er over nadenkt, het vastlegt en het consistent in je code gebruikt

.

woensdag 30 januari 2008 15:42

Acties:

RemcoDelft

Ik zou het met find/sed oplossen door alle "table" te vervangen door "Table" of andersom.

Hint:
cat file | sed y/ABCDEFGHIJKLMNOPQRSTUVWXYZ/abcdefghijklmnopqrstuvwxyz/ > tempfile; mv tempfile file

[ Voor 13% gewijzigd door RemcoDelft op 30-01-2008 15:42 ]

woensdag 30 januari 2008 17:42

Acties:

woensdag 30 januari 2008 17:48

RemcoDelft schreef op woensdag 30 januari 2008 @ 15:42:
Ik zou het met find/sed oplossen door alle "table" te vervangen door "Table" of andersom.

Hint:
cat file | sed y/ABCDEFGHIJKLMNOPQRSTUVWXYZ/abcdefghijklmnopqrstuvwxyz/ > tempfile; mv tempfile file

Nee, dan zet je ook alle data in alle velden om naar lowercase.. wat waarschijnlijk niet is wat je wil.

Na betaling van een licentievergoeding van €1.000 verkrijgen bedrijven het recht om deze post te gebruiken voor het trainen van artificiële intelligentiesystemen.

Acties:

woensdag 30 januari 2008 17:49

FragFrog schreef op woensdag 30 januari 2008 @ 00:23:
[...]
Niet mee eens, als je een consistente tabelnaamgeving aanhoudt is camelcase juist veel overzichtelijker.

Het belangrijkste woord is consistentie, de rest is persoonlijke voorkeur.

Een probleem zou ik het al helemaal niet noemen, 't is een simpele config instelling.

Een oplossing zou ik het al helemaal niet noemen, 't is povere symptoombestrijding.

Overigens knal ik die case sensitivity altijd uit, 't levert meer gezeur op dan nette code in mijn ervaring.

Als je het altijd netjes doet (consistentie!) heb je nooit veel gezeur.

{signature}

Acties:

woensdag 30 januari 2008 17:57

Voutloos schreef op woensdag 30 januari 2008 @ 17:48:
Als je het altijd netjes doet (consistentie!) heb je nooit veel gezeur.

Convention over configuration.. gaat dat hier ook op

?

Na betaling van een licentievergoeding van €1.000 verkrijgen bedrijven het recht om deze post te gebruiken voor het trainen van artificiële intelligentiesystemen.

Acties:

donderdag 31 januari 2008 00:17

Voutloos schreef op woensdag 30 januari 2008 @ 17:48:
Een oplossing zou ik het al helemaal niet noemen, 't is povere symptoombestrijding.

Een symptoon waar je compleet geen last van hebt op andere besturingssystemen

Geef me 1 goede reden waarom het niet gebruiken van de case-sensitivity een probleem is. De enige reden ervoor is dat je dan meerdere tabellen kan hebben met dezelfde naam maar met andere hoofdletters. Dat is bijna per definitie zo ranzig dat je het als het goed is toch nooit doet.

Wat overblijft is een enkel geval waarin een hoofdletter vergeten je uren gezeur kan opleveren als je ooit je database overzet, ja, echt verschrikkelijk slecht om dan de case-sensitivity uit te zetten

Theorie is allemaal leuk maar als je met meerdere mensen aan een groot project werkt kan het nog wel eens voorkomen dat iemand iets anders omgaat met case gebruik. Dingen als XMLelement / XmlElement, Userdata / UserData, etc om er maar een paar te noemen. Als dan driekwart van de coders op een case-insensitive OS werkt zul je problemen pas tegenkomen zodra je't commit, ik heb persoonlijk wel wat beters te doen dan continue hoofdletters in gecomitte code gaan lopen controleren, zeker als het helemaal niet hoeft.

[ Voor 24% gewijzigd door FragFrog op 30-01-2008 18:01 ]

[ Site ] [ twitch ] [ jijbuis ]

Acties:

Gomez12

FragFrog schreef op woensdag 30 januari 2008 @ 17:57:
[...]

Theorie is allemaal leuk maar als je met meerdere mensen aan een groot project werkt kan het nog wel eens voorkomen dat iemand iets anders omgaat met case gebruik. Dingen als XMLelement / XmlElement, Userdata / UserData, etc om er maar een paar te noemen. Als dan driekwart van de coders op een case-insensitive OS werkt zul je problemen pas tegenkomen zodra je't commit, ik heb persoonlijk wel wat beters te doen dan continue hoofdletters in gecomitte code gaan lopen controleren, zeker als het helemaal niet hoeft.

Als je juist met meerdere personen aan een groot project werkt dan zou ik juist hameren op consistentie, als je ze aanleert dat het bij de dbase niet uitmaakt, dan maakt het zometeen ook niet meer uit bij de classes, dan maakt het nergens meer uit...

Als iemand pertinent niet case-sensitive kan werken volgens interne standaarden dan vermoed ik dat er ergens anders ook niet volgens interne standaarden gewerkt wordt en dan krijg je imho prutscode.

Dus daarom hier intern in test-omgeving case-sensitive aan. In productie case-insensitive ( Als er ergens 1 foutje doorsluipt mag dit niet gelijk de productie treffen en 1 naam mag gewoon maar 1x gebruikt worden ). Dan kom je zo af en toe wel eens in situaties dat je productie->test omgeving niet altijd werkt terwijl het in productie zelf wel werkt, maar dit duidt dan weer op iemand die onze interne conventies niet helemaal begrijpt...

donderdag 31 januari 2008 00:21

Acties:

RobIII

Admin Devschuur®

^ Romeinse Ⅲ ja!

Gomez12 schreef op donderdag 31 januari 2008 @ 00:17:
Dus daarom hier intern in test-omgeving case-sensitive aan. In productie case-insensitive ( Als er ergens 1 foutje doorsluipt mag dit niet gelijk de productie treffen en 1 naam mag gewoon maar 1x gebruikt worden ).

...of er gebeuren compleet andere dingen in productie dan in test

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Je eigen tweaker.me redirect

Over mij

donderdag 31 januari 2008 00:30

Acties:

Gomez12

RobIII schreef op donderdag 31 januari 2008 @ 00:21:
[...]

...of er gebeuren compleet andere dingen in productie dan in test

Ach tja, als je over dit soort risico's gaat vallen, deze houdt je altijd als je test niet 100% productie is. Wij hebben maar 2 omgevingen, test en productie. Dus er gebeuren zowieso andere dingen in test ( vb. emails lopen via een andere server, error logging staat hoger )

Als je de luxe hebt om een development omgeving, een staging omgeving, een test omgeving en een productie omgeving te hebben dan zou ik het zeker aanraden om het anders te doen ( testing moet dan 99,99% gelijk zijn aan productie, alleen extern verkeer moet gestopt kunnen worden ) maar zolang wij maar 2 omgevingen hebben moeten wij roeien met de riemen die we hebben.

En zolang testing stricter is en meer info geeft zie ik zo snel geen makkelijker oplossing...

donderdag 31 januari 2008 00:37

Acties:

farlane

FragFrog schreef op woensdag 30 januari 2008 @ 17:57:
Geef me 1 goede reden waarom het niet gebruiken van de case-sensitivity een probleem is.

Waarom zijn identifiers in (alle niet krabbel-)programmeertalen case sensitive?

Somniferous whisperings of scarlet fields. Sleep calling me and in my dreams i wander. My reality is abandoned (I traverse afar). Not a care if I never everwake.

donderdag 31 januari 2008 01:29

Acties:

donderdag 31 januari 2008 03:26

Gomez12 schreef op donderdag 31 januari 2008 @ 00:17:
Als je juist met meerdere personen aan een groot project werkt dan zou ik juist hameren op consistentie, als je ze aanleert dat het bij de dbase niet uitmaakt, dan maakt het zometeen ook niet meer uit bij de classes, dan maakt het nergens meer uit...

Absolute onzin. Het maakt niet uit bij de database omdat het standaard niet uitmaakt op windows bakken. Bij classes ed maakt het standaard wel uit. Als dan je productieomgeving strenger is dan je testomgeving krijg je gezeur, dat voorkom je door de case-sensitivity uit te zetten. Voor code staat'ie aan op zowel ontwikkel als productieomgeving dus is het helemaal niet aan de orde.

farlane schreef op donderdag 31 januari 2008 @ 00:37:
Waarom zijn identifiers in (alle niet krabbel-)programmeertalen case sensitive?

Nog zo'n absoluut non-argument. Enkel omdat in een andere situatie iets is wil niet zeggen dat het een goede reden is om het ook ergens anders te doen. Juist niet als je niet eens weet waarom in de eerste plaats.

Code conventies zijn niet hetzelfde als onnodig extra eisen toe gaan voegen. Zoals ik al liet zien kan iemand zich prima aan camelcase coding houden en alsnog op andere plekken hoofdletters gebruiken dan een collega, soit. Als ik zie wat hier op GoT gepost wordt aan afzichtelijk SQL zijn er wel belangrijkere dingen om op te letten dan casing. Pas als iedereen altijd keurig uitgelijnde SQL schrijft, op de juiste plaats backticks toepast, niet onnodig vertragende subqueries gebruikt en netjes overal z'n indexen goed heeft, dan kun je eventueel gaan zeuren over hoofdletters. Tot die tijd is het een grote non-discussie

[ Site ] [ twitch ] [ jijbuis ]

Acties:

Verwijderd

Ik zou als ik Windows zou gebruiken case-sensitivity gewoon aanzetten. Dat andere mensen er misschien een zooitje van maken is niet mijn probleem. Ik wil gewoon nette casing hebben, zodat ik zeker weet waar ik het over heb. Is het een MyClass, of een myVar? Is het een myFunction(), of een MY_CONSTANT? Daarbij horen dan de MyTable en de myField in SQL. Dat houdt het overzichtelijk. En mocht ik ergens een foutje maken, dan merk ik meteen dat het niet werkt. Als het wel zou werken zou het ongemerkt onoverzichtelijker worden, en dat is een ernstige bug i.v.m. onderhoudbaarheid. Nog afgezien van de verminderde portabiliteit, want ik kan me niet voorstellen dat het common practice is om case-sensitivity eruit te slopen.

donderdag 31 januari 2008 09:02

Acties:

donderdag 31 januari 2008 10:39

FragFrog schreef op donderdag 31 januari 2008 @ 01:29:
Code conventies zijn niet hetzelfde als onnodig extra eisen toe gaan voegen.

Voorbeeldje cognitieve dissonantie. Puur omdat jij gewend bent dat tabelnamen in je dev omgeving case insensitive zijn, noem je het opeens geen conventie en vind je consistentie opeens niet boeiend zodat je lekker lui kan zijn.

Zoals ik al zei, als je het altijd netjes doet, gaat het ook vanzelf zo goed als altijd goed, cq. kom je er gauw achter als er 1 ding niet klopt.

Als dan je productieomgeving strenger is dan je testomgeving krijg je gezeur, dat voorkom je door de case-sensitivity uit te zetten.

Nee nee nee, dan ga je strenger devven/testen. Je wil niet al te afhankelijk worden van settings die fouten verstoppen, aardig doen, of eigenlijk gewoon suffe workarounds zijn om een ander OS na te doen.

Je devt toch ook niet met error_reporting(0)? Ik wil best toegeven dat een keer Tabel ipv tabel schrijven niet de zwaarste fout is die je kan maken, maar als je altijd netjes en consistent werkt, maak je die fout ook gewoon minder snel.

Als ik zie wat hier op GoT gepost wordt aan afzichtelijk SQL zijn er wel belangrijkere dingen om op te letten dan casing

Eens, vmb is het niveau van sql (en php) niveaus hier ook wat aan de lage kant, maar je leert ook netter te werken door consistent en overzichtelijk te werken. Bovendien vallen heel wat afzichtelijke fouten op door dus je ontwikkelomgeving een beetje streng in te stellen. Streng == behulpzaam.

Pas als iedereen altijd keurig uitgelijnde SQL schrijft, op de juiste plaats backticks toepast, niet onnodig vertragende subqueries gebruikt en netjes overal z'n indexen goed heeft, dan kun je eventueel gaan zeuren over hoofdletters. Tot die tijd is het een grote non-discussie

Ah, dat verklaart dan waarom ik me zo druk maak om hoofdletters.

{signature}

Acties:

donderdag 31 januari 2008 10:45

Voutloos schreef op donderdag 31 januari 2008 @ 09:02:
Nee nee nee, dan ga je strenger devven/testen. Je wil niet al te afhankelijk worden van settings die fouten verstoppen, aardig doen, of eigenlijk gewoon suffe workarounds zijn om een ander OS na te doen.

Suffe workarounds zoals case sensitivity aanzetten om maar linux na te doen?

Eens, vmb is het niveau van sql (en php) niveaus hier ook wat aan de lage kant, maar je leert ook netter te werken door consistent en overzichtelijk te werken. Bovendien vallen heel wat afzichtelijke fouten op door dus je ontwikkelomgeving een beetje streng in te stellen. Streng == behulpzaam.

Je lijkt nog steeds niet in te willen zien dat consistent niet hetzelfde is als altijd op precies dezelfde manier werken als een collega. Geen idee of je uberhaupt wel ervaring hebt met werken in grote teams, maar als je 5 coders naast elkaar zet, ze allemaal dezelfde conventies geeft om aan te houden en vervolgens een maandje laat devven zul je altijd verschillen zien in code. Mensen zijn geen machines, daar kun je simpelweg niet omheen.

Ik kan prima 100% consistent zijn in mijn tabelnaamgeving en ze alsnog anders benoemen dan een collega, ondanks dat we ons beide volledig aan conventies houden. Ja, dan kun je een suffe workaround gebruiken om het te vereisen, je kan ook inzien dat er belangrijkere dingen zijn om op te letten

Ah, dat verklaart dan waarom ik me zo druk maak om hoofdletters.

Wellicht

Realiteit is helaas dat van alle PHP/SQL devvers die ik ken (en mee samengewerkt heb) maar een enkeling op een niveau zit waar ik me druk ga maken over hun hoofdlettergebruik. Je zei het zelf al, het niveau hier op GoT is in jouw opinie vrij laag, maar in mijn ervaring is het niet lager dan dat van ~95% van de PHP/SQL devvers. Iets met laagdrempeligheid enzo

[ Voor 13% gewijzigd door FragFrog op 31-01-2008 10:44 ]

[ Site ] [ twitch ] [ jijbuis ]

Acties:

donderdag 31 januari 2008 11:14

FragFrog schreef op donderdag 31 januari 2008 @ 10:39:
Ik kan prima 100% consistent zijn in mijn tabelnaamgeving en ze alsnog anders benoemen dan een collega, ondanks dat we ons beide volledig aan conventies houden. Ja, dan kun je een suffe workaround gebruiken om het te vereisen, je kan ook inzien dat er belangrijkere dingen zijn om op te letten

Dit is een van de redenen waarom ik zo blij met met Ruby On Rails. Table definitions worden allemaal gegeneerd. Heerlijk! Als er een bug optreed weet ik nu in 99% van de gevallen exact welke file / model / table het misgaat, ookal heeft mijn collega het gemaakt.

Na betaling van een licentievergoeding van €1.000 verkrijgen bedrijven het recht om deze post te gebruiken voor het trainen van artificiële intelligentiesystemen.

Acties:

donderdag 31 januari 2008 12:07

FragFrog schreef op donderdag 31 januari 2008 @ 10:39:Suffe workarounds zoals case sensitivity aanzetten om maar linux na te doen?

Goed punt, maar je hebt dan wel het voordeel dat je gewoon netter werkt en daarmee dus problemen voorkomt.

Je lijkt nog steeds niet in te willen zien dat consistent niet hetzelfde is als altijd op precies dezelfde manier werken als een collega.

Zelf consistent werken of je aan de conventie van het bvedrijf houden zijn uiteraad 2 aparte begrippen, maar als je er zelf een zooitje van maakt, gaat het met die conventie ook niets worden.

Geen idee of je uberhaupt wel ervaring hebt met werken in grote teams, maar als je 5 coders naast elkaar zet, ze allemaal dezelfde conventies geeft om aan te houden en vervolgens een maandje laat devven zul je altijd verschillen zien in code.

Ja, ik heb ervaring in teamverband (ik werk bij React).

Ik kan mij overigens ook afvragen of jij uberhaupt wel ervaring hebt in teams, maar laten we maar niet op die toer verder gaan.

Mensen zijn geen machines, daar kun je simpelweg niet omheen.

Gelukkig niet, maar je kan wel proberen om netjes te werken.

Maar goed, ik geef je gelijk dat als fout hoofdlettergebruik van tabelnamen in je scripts je grootste probleem is dat je jezelf rijk mag rekenen. Echter is het ook weer niet zo moeilijk om deze fout te elimeren als jij doet voorkomen.

FragFrog schreef op woensdag 30 januari 2008 @ 17:57:
Als dan driekwart van de coders op een case-insensitive OS werkt zul je problemen pas tegenkomen zodra je't commit, ik heb persoonlijk wel wat beters te doen dan continue hoofdletters in gecomitte code gaan lopen controleren, zeker als het helemaal niet hoeft.

Nee, als iedereen gewoon zijn zandbakje netjes inricht, hoef je je gecommite zaken niet op dit punt te controleren.

{signature}

Acties:

donderdag 31 januari 2008 13:32

Voutloos schreef op donderdag 31 januari 2008 @ 11:14:
Goed punt, maar je hebt dan wel het voordeel dat je gewoon netter werkt en daarmee dus problemen voorkomt.

Welke problemen precies?

Zelf consistent werken of je aan de conventie van het bvedrijf houden zijn uiteraad 2 aparte begrippen, maar als je er zelf een zooitje van maakt, gaat het met die conventie ook niets worden.

Dat probeer ik je nu al 3 posts lang duidelijk te maken: ook als zowel jij als je collega's netjes werken kun je verschillen krijgen! Andere hoofdletters dan je collega's != er een zooitje van maken!

Ja, ik heb ervaring in teamverband (ik werk bij React). Ik kan mij overigens ook afvragen of jij uberhaupt wel ervaring hebt in teams, maar laten we maar niet op die toer verder gaan.

Ik werk voor een bedrijf in een codeteam van een man of 10, hoef je je dat ook niet meer af te vragen

Nee, als iedereen gewoon zijn zandbakje netjes inricht, hoef je je gecommite zaken niet op dit punt te controleren.

En als je 1 server netjes inricht ook niet. Welke kans acht jij groter: dat een van de dozijn desktops niet goed ingesteld staat waardoor ongemerkt bugs erin sluipen, of dat de productieserver plotseling verkeerd ingesteld staat? Mensen werken hier op laptops, thuis soms, op een van dells die hier staan die zowel door designers als coders gebruikt worden, etc etc. Dat valt amper te controleren.

Overigens:

Value Meaning
0 Table and database names are stored on disk using the lettercase specified in the CREATE TABLE or CREATE DATABASE statement. Name comparisons are case sensitive. Note that if you force this variable to 0 with --lower-case-table-names=0 on a case-insensitive filesystem and access MyISAM tablenames using different lettercases, index corruption may result.

Dat alleen al is een reden het niet te forceren op windows.

Natuurlijk, uiteindelijk is het netter als iedereen precies dezelfde case gebruikt maar zolang het niet nodig is en het problemen oplevert zodra je het gaat vereisen vind ik het niet relevant. Bovendien heeft nog niemand hier een bevredigend antwoord gegeven op mijn vraag waarom het problemen voorkomt / beter is, afgezien van "anderen doen het ook" of "het is netter"

[ Voor 8% gewijzigd door FragFrog op 31-01-2008 12:22 ]

[ Site ] [ twitch ] [ jijbuis ]

Acties:

Verwijderd

FragFrog schreef op donderdag 31 januari 2008 @ 12:07:
Dat probeer ik je nu al 3 posts lang duidelijk te maken: ook als zowel jij als je collega's netjes werken kun je verschillen krijgen! Andere hoofdletters dan je collega's != er een zooitje van maken!

Jawel, bij elk project hoor je zoiets af te spreken. Als je met meerdere personen code aanlevert, en iedereen houdt er zijn eigen stijl op na, dan wordt het inderdaad een zooitje. Dat niet één specifieke persoon daar verantwoordelijk voor is, maakt het niet minder onoverzichtelijk, en dus aantrekkelijk voor insecten.

donderdag 31 januari 2008 14:26

Acties:

donderdag 31 januari 2008 15:02

FragFrog schreef op donderdag 31 januari 2008 @ 12:07:
[...]

Welke problemen precies?

Zie topicstart.

En als je 1 server netjes inricht ook niet. Welke kans acht jij groter: dat een van de dozijn desktops niet goed ingesteld staat waardoor ongemerkt bugs erin sluipen, of dat de productieserver plotseling verkeerd ingesteld staat?

Ja, als iemand het verkeerd instelt sluipt kan er een fout in de code sluipen. Maar als je je oogkleppen op zet heb je altijd die fout in de code.

Dat alleen al is een reden het niet te forceren op windows.

Ja, dat is stom.

Maar goed, als 1 vd productiesystemen van origine case sensitive is, is het gewoon good practice om dat ook op je ontwikkelsysteem te hebben. Mysql (en de rest) op je eigen bak draaien kan handig zijn (eigen debugsettings + geen zeurende collega's als je een keer een paar heftig grote tabellen gaat importeren/wijzigen), maar vaak genoeg bespaar je jezelf ook een hoop gerommel door gewoon met een centrale dbserver (oa) voor ontwikkeling welke enigszins op een live systeem lijkt te werken.

Natuurlijk, uiteindelijk is het netter als iedereen precies dezelfde case gebruikt maar zolang het niet nodig is en het problemen oplevert zodra je het gaat vereisen vind ik het niet relevant.

Netjes werken is in eerste instantie nog geen vereiste. Je bent actief bezig, alles vers in het geheugen en alles werkt. So far so good.
Enter real-life: de applicatie groeit, paar mensen erbij, paar weg, paar verschillende productiesites erbij, een rits net nieuw bedachte features erbij en dan ga je toch op een gegeven moment heel hard balen. Verder gaat het als je een beetje discipline hebt, toch vanzelf op een gegeven moment.

Bovendien heeft nog niemand hier een bevredigend antwoord gegeven op mijn vraag waarom het problemen voorkomt / beter is, afgezien van "anderen doen het ook" of "het is netter"

Zie topicstart, en woordenboek voor het verschil tussen probleemoorzaak en symptoom.

Maar goed, ik geef het op, wij gaan het toch nooit eens worden. Succes met het onder de vloer vegen van fouten.

{signature}

Acties:

farlane

FragFrog schreef op donderdag 31 januari 2008 @ 01:29:
Nog zo'n absoluut non-argument. Enkel omdat in een andere situatie iets is wil niet zeggen dat het een goede reden is om het ook ergens anders te doen. Juist niet als je niet eens weet waarom in de eerste plaats.

In hoeverre verschilt een identifier in een programmeertaal van een identifier van een tabel dan? Voor het gemak zie ik SQL als een programmeertaal.

Het idee erachter is (denk ik ) dat je software consistenter wordt als je een variabele ( of dat nu een tabelnaam of een bestandsnaam of een variabelenaam is ) altijd hetzelfde noemt.

Ik vraag me trouwens af waarom je het bij code zo logisch vind en als je het over tabelnamen hebt in een keer niet meer ..? Als de enige reden is dat het op een Windows systeem standaard case insensitive is vind ik je argumenten ook niet echt overtuigend.

Somniferous whisperings of scarlet fields. Sleep calling me and in my dreams i wander. My reality is abandoned (I traverse afar). Not a care if I never everwake.

donderdag 31 januari 2008 18:06

Acties: