Nå man skal normalisere til 3.NF er der jo problemet med transitiv afhængighed, og det er der en del af i min tblFirm. Mit spørgsmål er derfor om det kan betale sig for mig ift opdatering af databasen at dele tblFirm op i de 6 tabeller der er mulighed for, for at opfylde 3.NF, eller om jeg skal lade den være på 2.NF.
Tjah normalt gør man det jo, men du må selv vurdere hvor meget det vil blive brugt. Flade strukturer er ikke nødvendigvis dårlige. Du kan dog få lidt problemer med historik ved adressekskift osv. hvis ikke du splitter op. Hvorfor har du en activeJob og en closedJob når du allerede har et statusfelt på activeJob? Det er måske overkill med mindre at performance i praksis viser sig at være for dårlig i activeJob.
Når databasen skal dække over flere lande (alle lande?), så har du jo ikke en reel chance for at få en komplet liste over zipkoder/postnumre, og skal zipcode->city tabellen opdateres ved kundernes indtastning får du slå- og stavefejl med. Og så mener jeg også at man fx i Tanzania ikke har (eller i praksis bruger) zipcodes.
Ideen er at jeg i ClosedJob kopiere data fra de ActiveJob's der er udført, for derved at slette disse fra ActiveJob. Grunden til at jeg gemmer dem i ClosedJob er at det skal være muligt at "åbne" lukkede opgaver igen. Derudover skal det være muligt at trække statistik.
Erik: Jeg m indrømme at jeg ikke har den store erfaring ud i webservices, for slet ikke at tale om PDA'er og WS's sammen, men mit scenarie er at hvis jeg bryder tabellen tblFirm op, vil jeg ligeledes skulle lave væsentlig flere kald for at få den information jeg skal bruge, og hvis dette skal gøres af fx. 50-100 PDA'er samtidig, ville det resultere i lange svartider.
Siger du derved at jeg kun burde normalisere videre hvis jeg vil have en "pæn" database? Det skal måske lige siges at jeg til enhver tid vil vægte performance frem for videre normalisering i og med at det miljø jeg arbejder i er en smule ukendt.
så vidt jeg ved er der ikke noget som udelukker at 2 countries kan have et county med samme navn, ditto med alle de andre bortset fra zipcode-city (forudsat at zipcode indeholder country code altså DK-6000)
Arne_V: I teorien har du selvfølgelig ret, men uanset hvad vil det forekomme ufatteligt sjældent at fx. 2 countrys har et county med samme navn, og på den måde vil der være transitiv afhængighed. Derudover er Phone - country vel transitiv afhængig hvis du skal have landekode med.
" Siger du derved at jeg kun burde normalisere videre hvis jeg vil have en "pæn" database? "
Nej, jeg siger du kun skal normalisere videre hvis du har strukturerede data, og zipcode->by kan være struktureret hvis du kun har byer i Danmark, men ikke hvis du skal medtage Tanzania og Tonga-tongaøerne.
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
