SQL fråga
 

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?

Japp, co-number & co-number.

Då vet jag tyvärr inte:(

Hej,

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

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

Customers:
Logg

Den verkar inte gilla "fnuttarna" på:

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:

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

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:

Nopp, inget resultat alls. Noll rader. :(

Jag fick fnuttarna om bakfoten jag med...

Så här ska det vara:

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

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.

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.

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:

Country:


Logg

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

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.

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.

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.

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.

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.

Jag skulle önska att det finns en internationell standard som man kunde luta sig mot för att slippa alla dessa oräkneliga varianter och anpassningar för de mest grundläggande begreppen, jag känner inte till någon sådan standard idag. Det finns dock ett antal försök att stadardisera exempelvis olika meddelandeformat mellan företag.

Landstingsförbundet har gjort ett försök i Sverige att skapa en standardiserad datamodell för landstingen men den används inte generellt.

En internationell standard skulle underlätta utbytet av information mellan företag och myndigheter samt minska mängden onödigt dubbelarbete.

Även om man endast definierar en nomenklatur i form av namnsättning och definition av olika grundläggande begrepp skulle det underlättaoch förbilliga utvecklingen av olika system avsevärt. Alla skulle då ha en viss grund att utgå ifrån som är känd för alla parter.

Ett exempel är att i USA så är många system uppbyggda så att man måste ange Tilltalsnamn, mitteninitial och efternamn. För mig personligen stämmer inte det eftersom jag heter "Per Conny Mikael Westh", där Conny är tilltalsnamn och Westh Efternamn.

I vissa system så skriver man "efternamn, förnamn" då skulle det bli: "Westh, Per Conny Mikael".

I vissa system så skriver man "efternamn, förnamn" och att man sätter asterisker runt tilltalsnamnet då skulle det bli: "Westh, Per *Conny* Mikael".

Fler Exempel:

"Petterson-Berger, Karl *Sven-Ingvar* Oscar"
"Grönholm-de Geer, Karl *Sven-Ingvar* Oscar"

I Holland så har man "van", "van der" och andra komponenter i namnet som inte passar i den svenska modellen.

Håller absolut med dig. För Storbritannien finns dock en offentligt och nationell som innefattar adressbeskrivningar osv också - snäppet bättre än Sverige iallafall. Men helt klart att en internationell ISO-standard borde finnas, precis som för t ex landskoder (finns dock två välanvändna för landskoder, men väl mycket bättre än ingen). Jag tror problemet ligger mycket i att världen knappt kan enas om vad ett förnamn och ett efternamn är, än mindre om antalet eller tillåtna tilltals-varianter.

Gällande namngivningskonventionerna blir det helt klart rörigare om man tar med fler språk. Fördelen med databaserna är att de är rätt få och rätt konsistenta i namngivningen.

Ta t ex privata variabler eller metoder. För många är det givet att de har ett underscore som prefix. Men ta t ex Suns namngivningskonvention för Java där den har ett underscore som suffix istället. Lägg sen till Python där det per definition är dubbla underscores då det skapar en privat variabel eller Objective C där dubbla underscores ofta används för att någon mystisk typ fick för sig att reserva enkla understrecket.

Vad som däremot är gemensamt för i princip alla namngiviningskonvention är att ord separeras. Antingen med underscore eller med (lower)CamelCase. Se t ex konstanter i de allra flesta språk för något som nästan alltid separareras med underscore då de oftast är uppercase. I fallet SQL måste man dock bestämma dig för databasmotor innan man namnger sin data om man bestämmer sig för en namngivningskonvention som kräver case sensitivity (camelCase möjliggör överlappande namn för olikt namngivna tabeller vid case insensitivity).

Jag håller nog inte riktigt med er där om att en internationell standard är önskvärd eller ens möjlig i detta fallet vad gäller just namn. Det kommer snarare att försvåra utvecklingen för många. Man får helt enkelt anpassa systemet efter dess syfte.

Problemet när det gäller namn är framför allt att den vanliga uppdelningen på för- och efternamn som vi har inte fungerar på en global nivå. I vissa kulturer förekommer inte ens efternamn och på andra håll fyller givna tillnamn (t.ex. i Kenya) inte en funktion som efternamn.

Problem som dessa resulterar i att man genom att införa en standard med stor sannolikhet tvingar in folk i ett låst system. Ett exempel på detta är digitaliseringen av vår svenska folkbokföring som bland annat normaliserat Gustaf till Gustav. Detta är dock givetvis en petitess och inget jämfört med de problem som kommer uppstå om man försöker ställa upp en internationell standardmodell. Vi har flera olika skriftspråk i världen och många ljud som inte ens går att skriva på ett korrekt sätt med vårt latinska alfabet. Om vi nu hade en internationell standard, hur skulle detta underlätta samkörning av olika nationella system i dessa fall? Den enda godtagbara lösningen är att de nationella systemen blir mer flexibla och internationella, något som är genomförbart idag om bara viljan finns.

När jag pratar om "standard" menar jag inte att man ska ta bort något sätt att uttrycka namnuppgifterna utan att man internationellt definierar upp vad som gäller så man som utvecklare lätt kan hitat denna info.

Det finns ju flera olika sätt att använda en standard på, men just detta med global namn och adress-info är ett område som skulle vinna mycket på det. Det blir ju mer och mer vanligt att webbshoppar säljer globalt.

Jo, håller i princip med dig. Däremot har jag svårt att se hur en sådan standard skulle kunna se ut.

Man måste ju försöka för att misslyckas, ....
Försöker man inte så misslyckas man inte...

Det är inte heller meningen. Grekiska adresser exempelvis ska givetivis sparas i databasen med grekiska tecken. Du har väl inte glömt att använda unicode? ;-)

Ska man spara namn normaliserat så får man nog inse att saker som det holländska infixet, det ryska fadersnamnet och det kenianska tillnamnet får hamna i olika tabeller. Om man nu har behov av ett genuint internationellt lagringssystem. Det enda som verkar vara säkert att alla har ett namn åtminstone, förnamn kan man ju ha flera av och initialer har inte alla - dessutom kan man ha ett andra efternamn av modell Bengtson-Nilsson som kan lagras separat. Med andra ord, ska man nog vara riktigt noga så får man nog ha ett individ_id och en riktigt mustig join för att skopa upp det hela (som inte alltid behöver vara fullt så mustig eftersom man ofta vet på förhand om man söker en person i Kenia eller Holland).

En internationell standard som bestämmer hur man får heta är nog något som bara programmerare kan önska sig...