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

[BoXon]

Customers:

CREATE TABLE IF NOT EXISTS `web_customers` (
`co-number` varchar(10) NOT NULL,
`pnumber` varchar(10) NOT NULL,
`firstname` varchar(250) NOT NULL,
`lastname` varchar(250) NOT NULL,
`address` varchar(250) NOT NULL,
`postcode` varchar(5) NOT NULL,
`city` varchar(250) NOT NULL,
`email` varchar(250) NOT NULL,
`cellphone` varchar(15) NOT NULL,
`homephone` varchar(15) NOT NULL,
`password` varchar(32) NOT NULL,
`registered` varchar(100) NOT NULL,
`package` varchar(1) NOT NULL,
`active` varchar(1) NOT NULL,
PRIMARY KEY (`co-number`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;

Logg

CREATE TABLE IF NOT EXISTS `Logg` (
`co-number` varchar(10) NOT NULL,
`time` varchar(100) NOT NULL,
`action` varchar(500) NOT NULL,
`ip` varchar(100) NOT NULL,
PRIMARY KEY (`co-number`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;

[bhumibol]

Den verkar inte gilla "fnuttarna" på:

PHP-kod:

FROM `web_customers`, `Logg` 


Egentligen kan du rensa bort många av fnuttarna, de behövs endast i fallen där du använder "co-number" eftersom bindestrecket tolkas som operationen minus annars. Så du bör undvika kolumnnamn med bindestreck.

Den här frågan ska funka:

PHP-kod:

SELECT 'web_customers.co-number', web_customers.package, 
'Logg.co-number', Logg.time, Logg.ip
FROM web_customers, Logg
WHERE 'web_customers.co-number'='PR-59867' AND 'web_customers.co-number' = 'Logg.co-number'; 


[BoXon]

Inget error iaf, men inget resultat heller. Trots att både web_customers & Logg innehåller en rad med samma co-number.

[bhumibol]

Säker på att båda villkoren uppfylls?

Testa att bryta ner villkoren för att minimera den felkällan, får du rader returnerade för dessa två frågor:

PHP-kod:

SELECT 'web_customers.co-number', web_customers.package, 
'Logg.co-number', Logg.time, Logg.ip
FROM web_customers, Logg
WHERE 'web_customers.co-number' = 'Logg.co-number'; 


PHP-kod:

SELECT 'web_customers.co-number', web_customers.package
FROM web_customers
WHERE 'web_customers.co-number'='PR-59867'; 


[BoXon]

Nopp, inget resultat alls. Noll rader.

[bhumibol]

Jag fick fnuttarna om bakfoten jag med...

Så här ska det vara:

PHP-kod:

SELECT `web_customers`.`co-number`, web_customers.package, 
`Logg`.`co-number`, Logg.time, Logg.ip
FROM web_customers, Logg
WHERE `web_customers`.`co-number`='PR-59867' AND `web_customers`.`co-number` = `Logg`.`co-number`; 


Men om jag var du så skulle jag göra så här istället (på båda tabellerna):

PHP-kod:

ALTER TABLE `dbname`.`web_customers` 
CHANGE COLUMN `co-number` `co_number` 
VARCHAR(10) NOT NULL , DROP PRIMARY KEY 
, ADD PRIMARY KEY (`co_number`) ; 


Varför har du valt att definiera alla kolumner som varchars? Om det är tänkt att tabellerna ska växa sig stora så kan det vara bra att redan från början tänka till lite, så att det inte blir svårarbetat för databasen i framtiden. Postcode... antar att det bara ska vara siffror här? Lämpligare med en INT(5) isåfall.

[BoXon]

Tack det verkar löst problemet!

Databasen är bara ett litet test, så kommer optimera så snart vi ser att allt funkar som det ska.

[Conny Westh]

CamelCase och lowerCamelCase är ganska nya som som defactostandard så den har inte hunnit sprida sig till alla utvecklare ännu. Men den härstammar från Pascal-världen där den förekommit sedan början av 1970-talet (om jag inte minns helt fel). Sen har den smittat av sig på C-kodare, C++ och så vidare, enligt den historik jag följt.

Jag är hellre utförlig och pedagogisk än låter missförstånd escalera. Jag visar hellre med exempel vad jag menar så att inte människors olika redan gjorda ställningstaganden till vad som är bra/dåligt färgar en saklig diskussion.

Jag har använt "_" i många applikationer både programkod och databas inom MIcrosoft och T-SQL världen oxo, men eftersom världen föärändras (förhoppningsvis till det bättre) så har även denna värld gått från att använda just s.k. döda tecken (ex: "_" eller "-") vid namngivnivningskonventioner av identifierare. Undantag är när man tydligt markera s.k. "interna" identifierare som inte bör användas av den normale programmeraren då man gärna sätter "_" (en eller flera i följd) i början av identifieraren som i C/C++: "__extern".

Oracle-världens konventioner vet jag är mer konsevativa mot nymodigheter men det brukar smitta av sig till dem också.

Bra konventioner (som upplevs som bra av de flesta utvecklare) brukar segra hos massorna så småningom, då det helt enkelt tränger ut mindre bra konventioner.

[tartareandesire]

Conny:

I princip håller jag med dig om det mesta du skrivit här men i ett par avseenden så anser jag att du har lite fel.

Att använda en avskiljare som "_" gör att det blir tydligare och mer lättlästa tabellnamn. De bör givetvis inte användas i onödan men de fyller en viktig funktion om de används på ett logiskt och lämpligt vis. Det används med all säkerhet av en ganska övervägande majoritet av världens webbutvecklare idag.

Det går heller inte att generalisera vad gäller fältlängder på det viset du gör. Det finns en rad ortnamn världen över som har mer än 25 tecken, liksom det finns långa för- och efternamn samt olika system och konventioner i olika länder. I spansktalande länder har man exempelvis två efternamn och när det gäller arabiska namn finns det en rad olika kombinationer av flera patronymikon, tillnamn, stamnamn etc. I officiella eller internationellt anpassade system bör man tänka efter betydligt mer än vad man gör idag. Officiella system måste i princip vara internationellt anpassade för att fungera bra. "Effektivisering" är inte samma sak som att utesluta viss information bara för att spara lite utrymme.

Däremot har du givetvis helt rätt vad gäller principerna om atomisering och normalisering.