Hej.

Jag sitter och klurar på hur man bäst presenteras information i databasen på flera språk. Säg att jag har en produkt. Denna produkt kan ha en färg, Blå. Jag vill kunna presentera min produkt på flera olika språk och kan därför inte skriva Blå i databasen, utan skapar en ColorTabell som innehåller ett ID och i min produkt tabell så spara jag ner id på färgen.

<code>
Product
==============
ID | ColorID | ....


Color
==============
ID |
</code>

Nu kommer då frågan, hur spara jag undan de olika färg namnet för olika språk, bör jag ha med ett LanguageId i min Colortabell, eller skall jag lägga till en speciell LanguageColorTabell. För min Color tabell kan ju innehålla annan information som är samma för alla språk och om jag inte flyttar ut namnet till färgen så blir det ju dubbellagrad information, men om jag gör det så blir det en extra tabell som man måste göra en Joins emot för att hämta ut data, samt att det blir ju riktigt många tabeller. En produkt har ju mer information än färg: Material, kategori, serie, osv osv...

<code>
Color
==============
ID | LangID | Name | ....
</code>

Eller

<code>
Color
==============
ID | ....

ColorLanguage
==============
ID | LangID | Name
</code>

Funderade på ha någon speciellt matchningstabell där det typ står Blå = BLUE men visa poster kommer kräva mer text, typ beskrivning och det blir ju lite jobbigt att ha en matchnings tabell mot det.

Någon som har gjort något liknande och har ett tips.

- M

Just för färgerna hade jag gjort följande:

1 tabell som heter language
languageid int
languagename varchar(50)

1, Engelska
2, Svenska

1 tabell som heter color
colorid int (ej unikt)
languageid int
colorname varchar(50)

1, 1, Black
1, 2, Svart

Sen om du använder en tabell som lagrar färg så lagrar du colorid 1, och i selectsatsen när du sen plockar ut detta så kollar du vilket språk du skall använda

select colorname
from mytable m, color c
where m.colorid = c.colorid
and c.languageid = 1

vilket ger dig "Black"

eller så skriver du en user defined function och då blir din sqlfråga om du vill välja det engelska ordet:

select dbo.getcolor(colorid, 1) from mytable

En user defined function är smidig ibland om det används samma beräkningar eller frågor på många ställen och i många procedurer.

Ja för sådan enkel tabel som färg så är det inte så svårt, men säg att om man väljer en vis färg så skall det ske ett påslag med 10% på priset, denna information skall ju sparas tillsammans i färgtabellen, denna information kommer ju så fall att dubbellagras för att ta ditt exempel.

<code>
COLOR
===========
ID | LangID | Name | PriceAdjust | ...
_1 | ______1| ___Blå |________10 | ...
_1 | ______2| __Blue |________10 | ...
_1 | ______3| __xxx |________10 | ...
</code>

Här har jag ju lagrat prispålägget 3 gånger, vilket jag skulle slippa om jag istället hade gjort så här:

<code>
COLOR
===========
ID | PriceAdjust | ...
_1 | ________10 | ...

COLORLANGUAGE
====================
COLORID | LANGID | NAME
________1 | ______1| Blå
________1 | ______2| Blue
________1 | ______3| xxx
</code>

Och för varje extra information som är samma för de olika språken så blir det ju ännu mer dubbellagrad information, men den sista lösningen blir det en j-vla massa tabeller....

- M

Massa tabeller ;-)

Jag hade nog to m gjort fler tabeller där jag har priceAdjust i en annan tabel som är kopplad till ex kund där varje färg har ett artikel ID med ett fast pris. där man sedan frågar kunden vad han/hon har för specialpris och i min businesslogik hantera detta påslag med artikelns grundpris.

typ...

Mvh Johan

Jag misstänker att du tycker alternativ 2 är bäst så fall. :) Jag har kollat på den lösningen och om man vill plocka fram lite mer information om produkten på en gång, säg att du vill ha ut färgen, material, kategori och serie vilka alla ligger i seperata tabeller till produkten och dessa sedan har sina languagetabeller så blir det ju upp mot 9 joins som måste göras.

Någonstans har jag för mig att jag läst att om man har många joins så kommer det påverka prestandan negativt, men det kanske inte stämmer?

- M

Följdfråga till dig ang. din fråga är:
Hur många samtliga användare kommer använda ditt system?

Många fokuserar idag på prestanda, man är livrädda att applikationen skall gå långsam m.m.
Man spenderar ca 80% på kodoptimering under kodandet innan man ens vet om det behövs.
En skicklig programmerare är ca 1280% bättre än genomsnitt. Detta för att man oftast struntar i att lägga tid på optimering och fokuserar på ett fungerande system med bra koddesign istället. När han/hon är klar är det dags att testa om prestandakraven uppfylls. Först då kan du mäta och se om du har flaskhalsar eller om dina funktioner inte håller de prestanda krav man har satt upp. För det har du va? eftersom du pratar om prestanda?
Mitt tips är att strunta i prestanda om du inte redan känner till självklara saker som inte tar för mycket av din tid. Deadline, bra kod, underhållsam och förändringsbar kod är viktigare än att råka få ett komplext och risk till spagettiliknande system.

Ang din fråga med joins; ja joins är ju långsammare än att inte ha joins, men det ger en bättre modell samt ökar förståelse över hur det skall användas och ger ett mer självdokumenterande system. Det ger dig även flexibilitet och förändringsmöjlighet m.m. Ticken för en join vs icke join är så liten så du kommer nog knappt märka av den, om du inte har över 1000 samtliga användare och sunkig server.
Så bry dig inte om det, gör bra kod, snygg kod, du skall älska din kod, din modell och din lösning, gör du inte det är du redan på hal is... Du kan då räkna med att din produkt inte kommer bli så bra om du inte kan älska den.

När du är klar, kör prestanda tester, hitta flaskhalsar. Du kommer märka stor skillnad i både kod, tid och resultat genom att göra på detta sätt. En förändringsbar design gör att du t.o.m. enklare kan optimera i efterhand än justera något du trodde var optimerat men som gav flaskhals istället.

Det låter lite som du vill ha en PDM (Product data management) databas. http://en.wikipedia.org/wiki/Product_Data_Management
Det finns en del bra info på nätet om just detta som säkert kan ge dig idéer och tips ang hur du vill ha din databas.

mvh johan

Den tabellen du pratar om borde rimligen heta colorprice och ha samma pris oavsett om det är den svenska eller engelska färgen tycker jag..

> En skicklig programmerare är ca 1280ggr bättre än genomsnitt.

Riktigt så illa är det inte, utan den exakta :-) siffran är 28.
(och då gäller det inte heller en jämförelse mot den genomsnittliga utan en jämförelse mellan den sämsta och bästa)

Källa:
Facts and Fallacies of Software Engineering
http://www.amazon.com/gp/reader/0321117425/

Hehe...

Menade inte ggr utan %... Sorry...

Mvh Johan

Det går att få bra prestanda även i en mycket normaliserad databas, men det kräver mer av SQL-utvecklaren. Även om man har stora tabeller med miljontals rader så går det att plocka ut poster snabbt. En del av lösningen är att att använda temptabeller eller tabellvariabler och inte göra en select med nio joins rakt upp och ner. Om man istället först skapar en temptabell och sedan kör update joins på denna temptabell kan man få mycket bättre prestanda. Man kan också lägga index på temp-tabeller. Man ska inte heller förkasta denormaliserade tabeller som ett komplement.