Jens Gyldenkærne Clausen <jens@gyros.invalid> skrev:
>Jesper Stocholm skrev:
>
>> Naturligvis kan det være en hjælp at gøre som du beskriver,
>> men det bør under alle omstændigheder undersøges, hvorfor der
>> kommer en uforståelig fejl.
>
>Bestemt. Jeg vil også til enhver tid anbefale at man
bruger "sikre"
>objektnavne så man slet ikke behøver at bruge klammer.
>
>
>> At sætte klammer om alle tabelnavne samt attributnavne
>> er efter min bedste overbevisning en "work-around" og ikke en
>> løsning.
>
>Det er ikke altid så let at rette et feltnavn i en færdig eller
>næsten færdig applikation.
Det er korrekt, jeg har fx selv haft problemer med et feltnavn,
der kom til at hedde intSomeName, da vi i starten af designet
regnede med, at feltet kun skulle indeholde tal. Dette viste sig
dog senere ikke at være tilfældet, men da var det for sent. Der
gik 3 måneder før vi i forbindelse med et større code-review og
skift af db-backend kunne få rettet fejlen "tilbage".
>I mine øjne er noget af det vigtigste i kodeskrivning at man er
>konsekvent. Derfor kan det være kønnere at skrive klammer alle
>steder i stedet for kun de steder hvor det er nødvendigt.
Eller ... imo smartere ... vælge attributnavne, der ikke kræver
klammer. Det gør også skift imellem forskellige db-systemer
nemmere. Jeg kan ikke se, hvad der kan retfærdiggøre at man bruger
navne på attributter, der kræver klammer. "Læsbarhed" er imo slet
ikke argument nok.
>> Det er klart, at resultatet er det samme - om man bruger
>> klammer eller ej, men det er imo meget dårlig kodeskik, da
>> koden ved introduktion af flere tegn sandsynligvis afvikles
>> langsommere.
>
>Det tror jeg ikke er mærkbart. SQL-sætningerne bliver marginalt
>større - og den ekstra datamængde skal selvfølgelig sendes til
>databasen. Men jeg tror ikke at databasen vil være spor
langsommere
>til at behandle en forespørgsel med klammer.
Måske ikke ... men jeg forsøgte også at fokusere på kodeskikken.
Som de fleste "øvede" herinde nok vil nikke genkendende til, så er
god kodeskik alfa og omega i programmering. Hvis man på et tidligt
tidspunkt introducerer dårlig skik som "jeg laver bare lige en
work-around i stedet for at finde fejlen", så har dette en tendens
til at gribe om sig.
Grunden til at det altid er en fornøjelse at læse dine svar til
andre er, at de altid er velovervejede i forhold til optimering af
den foreslåede kode. Dette er du heldigvis ikke ene om herinde, og
det er dette, der gør gruppen så nyttig - meget lig "tonen" i
dotnet-gruppen. Derfor var jeg blot overrasket over dit svar, der
kunne tolkes i retning af "lad være med at bruge tid på det - lav
en workarround og kom videre".
>> En analogi - der nok er sat lidt på spidsen - kunne være at
>> vælge Longtext/Notat-typen for alle felter i en tabel. Det har
>> nemlig den charmerende fordel, at stort set alle data kan
>> indsættes i det
>
>Det er sat *meget* på spidsen. Der er ingen sammenhæng mellem valg
>af datatyper og hvordan man skriver sql-syntaksen.
Nej, men der er sammenhæng imellem at vælge den "rigtige" vej og
den nemme vej. Jeg vil til enhver tid vælge den første. Jeg skal
dog erkende, at mit indlæg nok er farvet af, at jeg i de sidste
uger har arbejdet med nogle projekter, hvor performance og
optimering har været ekstremt vigtige. Her har udfordringen ikke
været at finde en løsning på et problem - opgaven var i princippet
triviel - men at finde den bedste løsning. Pludselig ses megen af
den kode man tidligere har lavet i et meget dårligt lys ... :)
>NB: Hvad er der sket med din ombrydning?
Spørg TDC ... jeg ved ikke helt, hvad der gik galt ... :)
--
* Jesper Stocholm *
*
http://stocholm.dk *
* Svar til gruppen og ikke til mig privat ! *
* Hvor svært kan det være ? *