[Clarence]

Ursprungligen postat av ConnyWesth

Det finns ingen anledning att följa en dålig konvention. I synnerhet inte när det finns en mainstream-konvention som har fungerat i minst 20 år och som är den som används av de som kan datamodellering.

Det finns en vettig standard för hur breda adressfält bör vara som bland annat skatteverket använder och som är på 36 tecken för både förnamn och efternamn tillsammans. Samma längd gäller då för själva raden med gatuadress.

Det finns olika standarder för längd på data från mängder länder och myndigheter. För att gå tillbaka till Storbritannien så ligger forename/surname på vardera 35 tecken i deras officiella standard - alltså nästan det dubbla av skatteverkets. Såvitt jag vet finns ingen ISO-standard som man bör följa utan det görs egna standarder i bästa fall per land.

Kan hålla med om de allra flesta av dina punkter för övrigt. Och en eloge ska du ha för energin att förklara både tydligt och utförligt.

Gällande namngivningskonventioner för databaser tog jag mig friheten att söka på de vanliga nämda rekommendationerna beroende på databassystem, så att det inte bara var min egen erfarenhet som är färgad av mina typer av projekt. Min uppfattning av resultatet var att inom Oracle och MySQL rådde i stort sätt konsensus om namngivning med ett case (upper/lower varierade) och underscore mellan ord. Inom T-SQL-lägret tyckte jag däremot att det var lite mer splittrat med för mig förvånande många (men ingen majoritet, tror jag inte) som förordade CamelCase och lowerCamelCase. För MySQL kan man nästan säga att underscore-namngivningen är helt standard då både en helt dominerande del av användare och den medföljande information_schema-databasen följer den.