[BoXon]

Hej!

Antagligen var det något fel på whiskyn, jag får nämligen inte till detta:

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`

Utan får
#1054 - Unknown column 'web_customers.co-number' in 'field list'

Någon som vet vad fan jag gör fel?

[abergman]

Ursprungligen postat av BoXon

Hej!

Antagligen var det något fel på whiskyn, jag får nämligen inte till detta:


Utan får
#1054 - Unknown column 'web_customers.co-number' in 'field list'

Någon som vet vad fan jag gör fel?

Heeeelt 100 på att du har rätt på namnet? och att det ska vara co-number och inte co_number?

[BoXon]

Japp, co-number & co-number.

[abergman]

Ursprungligen postat av BoXon

Japp, co-number & co-number.

Då vet jag tyvärr inte

[bhumibol]

Hej,

Skulle du kunna posta resultaten av dessa två frågor:

describe web_customers;

describe Logg;

Blir lättare att svara på din fråga om vi kan se vilken struktur dina tabeller har.

[Conny Westh]

Ursprungligen postat av BoXon

Japp, co-number & co-number.

Jag vill bidra med några tips:

- Justera längden på columnerna till "rimliga" nivåer enligt nedan
- Använd aldrig "döda" tecken (som '_' eller '-') i tabell eller kolumnnamn
- Kolumnnamn bör vara i singularis ej plural
- Datum och tid finns det bätrr datatyper för än varchar
- var mer noggrann i valet av datatyp, allt passar inte superbra som varchar

Customers:

CREATE TABLE IF NOT EXISTS `customer` (
`conumber` varchar(10) NOT NULL,
`pnumber` varchar(10) NOT NULL,
`firstname` varchar(25) NOT NULL,
`lastname` varchar(25) NOT NULL,
`address` varchar(36) NOT NULL,
`postcode` varchar(10) NOT NULL,
`countrycode` varchar(2) NOT NULL,
`city` varchar(25) NOT NULL,
`email` varchar(80) NOT NULL,
`cellphone` varchar(15) NOT NULL,
`homephone` varchar(15) NOT NULL,
`password` varchar(32) NOT NULL,
`registered` varchar(12) NOT NULL,
`package` varchar(1) NOT NULL,
`active` varchar(1) NOT NULL,
PRIMARY KEY (`conumber`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;

Country:

CREATE TABLE IF NOT EXISTS `country` (
`countrycode` varchar(2) NOT NULL,
`country` varchar(36) NOT NULL,
`phonecode` varchar(3) NOT NULL,
PRIMARY KEY (`countrycode`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;

Logg

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

[Clarence]

Ursprungligen postat av ConnyWesth

Jag vill bidra med några tips:

- Justera längden på columnerna till "rimliga" nivåer enligt nedan
- Använd aldrig "döda" tecken (som '_' eller '-') i tabell eller kolumnnamn
- Kolumnnamn bör vara i singularis ej plural
- Datum och tid finns det bätrr datatyper för än varchar
- var mer noggrann i valet av datatyp, allt passar inte superbra som varchar

Jag tror att det inom PHP/MySQL-lägret är extremt mycket vanligare att separera ord med _ istället för att skriva ihop orden som namngivningskonvention. Och det hoppas jag vi kan vara överens om, att man när man skriver applikationer med MySQL följer namngivningskonventioner som dominerar för sådana. Sen tycker jag förvisso också själv att ihopskrivning utan camelcase aldrig är att föredra, vare sig det gäller databaser eller klasser/funktioner/variabler då jag tycker det blir mycket mer svårläst.

Skulle också föredra att lägga en varchar(127) på t ex namnen istället. Då den enda skillnaden för MySQL är begränsningen i max antal tecken. För varchars längre än 127 kan det dock bli 1-2 bytes overhead per rad. Dessutom får man in väldigt långa namn och slipper problemet med väldigt långa dubbel/trippel-efternamn (förvisso inte vanliga i Sverige, men vill man ha internationell kompatibilitet så) som inte kan läggas in.

Ursprungligen postat av bhumibol

Postcode... antar att det bara ska vara siffror här? Lämpligare med en INT(5) isåfall.

Att spara postkoder som int(5) är inte vidare lyckat om man vill ha någon internationell kompatibilitet (se exempelvis Storbritannien där de både har bokstäver och upp till 7 tecken).

[bhumibol]

Ursprungligen postat av Clarence

Att spara postkoder som int(5) är inte vidare lyckat om man vill ha någon internationell kompatibilitet (se exempelvis Storbritannien där de både har bokstäver och upp till 7 tecken).

Eftersom det inte ens finns någon kolumn för landtillhörighet så antog jag att det gällde Sverige, för vilket int(5) känns lämpligare än varchar(5). Finns många olika svar i den här frågan som alla kan vara rätt... ville bara hinta om att tänka till från början, innan det blir svårt att hantera.

[Conny Westh]

Ursprungligen postat av bhumibol

Eftersom det inte ens finns någon kolumn för landtillhörighet så antog jag att det gällde Sverige, för vilket int(5) känns lämpligare än varchar(5). Finns många olika svar i den här frågan som alla kan vara rätt... ville bara hinta om att tänka till från början, innan det blir svårt att hantera.

Man bör aldrig använda int för värden som är koder. man kan exempelvis inte göra en summering på postnr, det skulle helt sakna relevans, bland annat därför bör man använda varchar. Vidare så är det vanligt att man utökar koder med ett förled som är en bokstav, har man då byggt upp sitt system så att det alltid måste vara numeriskt så kommer systemet inte klara att lagra korrekta data.

[Conny Westh]

Ursprungligen postat av Clarence

Jag tror att det inom PHP/MySQL-lägret är extremt mycket vanligare att separera ord med _ istället för att skriva ihop orden som namngivningskonvention. Och det hoppas jag vi kan vara överens om, att man när man skriver applikationer med MySQL följer namngivningskonventioner som dominerar för sådana. Sen tycker jag förvisso också själv att ihopskrivning utan camelcase aldrig är att föredra, vare sig det gäller databaser eller klasser/funktioner/variabler då jag tycker det blir mycket mer svårläst.

Skulle också föredra att lägga en varchar(127) på t ex namnen istället. Då den enda skillnaden för MySQL är begränsningen i max antal tecken. För varchars längre än 127 kan det dock bli 1-2 bytes overhead per rad. Dessutom får man in väldigt långa namn och slipper problemet med väldigt långa dubbel/trippel-efternamn (förvisso inte vanliga i Sverige, men vill man ha internationell kompatibilitet så) som inte kan läggas in.


Att spara postkoder som int(5) är inte vidare lyckat om man vill ha någon internationell kompatibilitet (se exempelvis Storbritannien där de både har bokstäver och upp till 7 tecken).

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.

Postnr och ort inkl landskod har också maxlängden 36 tecken. Detta gäller alltså när man skriver ut adressen för exempelvis utskick. Det är sällan meningsfullt att lagra överdrivet många tecken för atomära columner, då bör man kanske fundera en gång till på att dela upp det i fler columner elelr kanske till och med bryta ut till egen tabell.

Ett exempel:

Kalle Pettersson (max 36 tecken)
c/o Lena Svensson (max 36 tecken)
Kallhamrastigen 345 (max 36 tecken)
SE-123 45 FARSTA (max 36 tecken)

När man delar upp dessa i mindre komponenter i databasen så informationen blir atomär så brukar man regelmässigt använda 25 tecken för förnamn, efternamn samt ort.

Postnr brukar man använda 10 tecken (brittiska postnr kan vara långa).
Det finns även de som delar upp gatuadressen så själva gatunamnet är för sig och nummret är för sig. Ytterligare finfördelning förekommer där antal trappor anges eller om det är ö.g. (dvs över gården).

Själv brukar jag lägga förnamn (varchar(25)), efternamn (varchar(25)), coadress (varchar(36)), gatuadress inkl gatunummer (varchar(36)), landskoden (varchar(2)), postnr (varchar(10)), ort (varchar(25)) i egna kolumner.

Land (varchar 36) kan man med fördel lägga i en egen tabell där landskoden är PK. Det förekommer att man lägger Land i samma tabell som adressen men man drabbas då av mycket onödig redundans.

Jag har arbetat med applikationer där man gått längre i sin normalisering till atomära värden.

Landskoden kan man hämta på Tullverkets webbplats för att få alla 2 ställiga landskoder som använd vid postbefordran.

När man har med större företag att göra som kunder så kan de kräva att man skiljer på Beställare, leveransmottagare, fakturamottagare och ibland även betalaren som alla kan ha helt olika adresser. Som leverantör till dessa kunder måste man kunna hantera dessa olika adresser annars får man inte betalt (om du skickar fakturan till fel mottatgare, eller leveransen till factoringfirman exempelvis).

Ju mer atomärt man lagrar sina data desto lättare har man att göra anpassningar, utbyggnad och nya lösningar som man inte tänkt på när man började bygga sytemet. Man har dessutom lättare att integrera med externa system om man följer folkbokföringsregistrets och postens normalisering av adressdata.

Ovanstående är en väl vedertagen konvention (som det finns varianter av) men om man skulel göra en fullständig normalisering enligt tredje normalformen skulle man bryta ut alla förnamn respektive efternamn i egna tabeller och bygga upp "person"-tabellen med en PK som är personnr och en länktabell med namn i en med status för namn om det är tilltalsnamn, men det har man oftast kompromissat bort för att förenkla användningen för programmeraren. Så förnamn och efternamn är i högsta grad redundanta i de flesta databaser. Men man får göra en del genomtänkta kompromisser vid modelleringen.

Adress har jag dock sett allt oftare förekommer i en egen tabell. Just eftersom samma företag eller privatperson har ett antal olika adresser som man behövr hålla koll på, men det beror på hur databasen ska användas hur man väljer att lösa detta.