WN - Databasdesign

Sidan 2 av 2

Visa 40 inlägg från det här ämnet på en sida

WN (https://www.wn.se/forum/index.php)

- Serversidans teknologier (https://www.wn.se/forum/forumdisplay.php?f=4)

- - Databasdesign (https://www.wn.se/forum/showthread.php?t=9003)

eg0master

2005-07-23 10:10

Citat:

Originally posted by Susanne@Jul 23 2005, 04:12
Nu upptäckte jag att jag tolkat det som skrivits lite fel. Det jag menade var att man kan ju döpa tabellnamnen case sensitive, inte att all data i databasen behöver vara det också.
Tycker du att det är en dålig idé det med?

Kärnpunkten i artikeln ang. case i databasen (som tar upp både data & tabell/SP/funktion/vy namn) är att om man är case sensitive så minst fördubblar du komplexiteten i koden eftersom myTable och MYtable blir två helt olika saker. Just tabellnamn spelar detta kanske mindre roll på eftersom man sällan skapar nya tabeller speciellt ofta. Däremot kan SPs, vyer, temptabeller mm som man kanske skapar fler av (och för enskilda specifika syften) potentiellt orsaka problem.
Ex:
UTV 1 skapar FUNC1 som kräver en vy han kallar vyn
UTV 2 skapar FUNC2 som kräver en vy han kallar Vyn
UTV 2 råkar sedan längre ner i koden i FUNC2 av misstag skriva vyn

Nackdelen med att utnyttja case sensitivity är att denna typ av misstag kan få oanade effekter.
Case är dock (oavsett om koden är case sensitive eller inte) är dock att läsbarheten av koden kan bli bättre (myLongSpecialFunction vs mylongspecialfunction).
Om koden tolkas case sensitive tvingar man utvecklarna att skriva namn på det mer läsbara sättet (vilket ju är bra), medans det får den nackdelen att man av misstag pga fel case använder fel variabel/tabell/objekt.

Så egentligen är det en smaksak och visst tycker jag man skall använda sig av upper/lower case för att göra koden mer lättläst, men det betyder inte att man måste tvinga fram rätt case eftersom det kan leda till problem. Det beror på hur mkt man litar på de inblandade utvecklarna (inkl sig själv).

Robert

2005-07-23 14:19

Citat:

Originally posted by eg0master@Jul 23 2005, 01:16

Citat:

Citat:

Sedan tycker jag att eftersom man ändå kör case INsesitive i databasen så är det skitsamma med case (se fler artiklar i länken ovan).

Men man kan ju köra Case Sensitive i databasen.

Läs denna i samma serie som ovan för fler synpunkter på case sensitive databaser.
http://www.sqlservercentral.com/columnists...iveoranythi.asp
Bara för att man kan innebär inte att det är lämpligt. Min bil kan köras i 250km/h. Det är kanske inte lämpligt. Man kan som man klä sig i rosa klänning innan en anställningsintervju, men det är inte lämpligt. :P

Citat:

Det finns tillfällen då man måste ha alla kolumnnamn unika per databas för att undvika diverse strul. Men som sagt, alla har ju inte det behovet.

Kan du ge ett exempel?

I det projekt jag sitter på nu har man ca 137tabeller, 685sp's, och ett snitt på 15kolumner per tabell. Många av sp'arna genereras av ett verktyg som verkligen uppskattar att en kolumn kan visa vilken tabell den härör ifrån ELLER vilken tabell den pekar på. Att förklara detta fullt ut kräver en mindre novell men du får lite på mig! Att tex ha 137 tabeller där varje unik id-kolumn heter 'id' är inte skojj, speciellt inte när en tabell har en fk som ska peka mot en annan tabells id... då ska det synas vilken tabell den ska peka mot genom att läsa på kolumnnamnet.

eg0master

2005-07-24 00:59

Citat:

Originally posted by Robert@Jul 23 2005, 14:19
I det projekt jag sitter på nu har man ca 137tabeller, 685sp's, och ett snitt på 15kolumner per tabell. Många av sp'arna genereras av ett verktyg som verkligen uppskattar att en kolumn kan visa vilken tabell den härör ifrån ELLER vilken tabell den pekar på. Att tex ha 137 tabeller där varje unik id-kolumn heter 'id' är inte skoj, speciellt inte när en tabell har en fk som ska peka mot en annan tabells id... då ska det synas vilken tabell den ska peka mot genom att läsa på kolumnnamnet.

Inte ska du behöva skriva en novell...
Och ang användandet av verktyg så kan jag tänka mig att ett verktyg (eftersom den som gjorde verktyget var lat) genererar/kräver att kolumnnamn innehåller tabellnamn. Men eftersom det då handlar om autogenererad kod så är det ju inte mycket att göra åt. Dock så är ju inte det ett argument för att man skall använda den typen av konventioner generellt eftersom jag antar att verktyget du syftar på används av en specifik anledning och inte något som man generellt skulle dra nytta av (för om det är ett generellt verktyg skulle man ju vilja ha ett verktyg som var bättre skrivet och klarade av att hantera kolumnnamn oavsett vad de egentligen heter).

Ang namnsättning på ID så har du helt missförstått vad jag (och andra i denna tråd) sagt. Vi pratar ID kolumnen i en tabell, inte eventuellt FK.
Exempel på hur jag menar:

Kod:

CREATE TABLE Customer (

ID INT AUTO_INCREMENT PRIMARY KEY,

Name VARCHAR(50));



CREATE TABLE CustomerContact (

ID INT AUTO_INCREMENT PRIMARY KEY,

Name VARCHAR(50),

CustomerID INT NOT NULL /* References Customer.ID */);



SELECT Contact.ID, Customer.ID, Contact.Name, Customer.Name

FROM CustomerContact AS Contact, Customer AS Customer

WHERE Contact.CustomerID = Customer.ID;

För jag hoppas du är medveten om att kolumner som är FK inte behöver ha samma namn som PK kolumnen...

Robert

2005-07-24 13:36

Verktyget och ramverket är skrivet av oss, koden har gått sina turer till en person på MS som i sin tur har gett oss värdefull feedback från sina kollegor. Verktyget tillverkar även .net klasser för access till varje tabell, och då är det jäkligt bra för utvecklaren att, utan att behöva veta allt om databasmodellen, kunna skicka in ett visst id till en viss klass och få ut ett resultat. Vad ska den metoden döpas till? Få se nu, vi kanske ska ha fem metodnamn som alla heter "ID"... eller så kan vi vara smarta och bara ange tabellnamn + kolumnnamn och på så vis kunna ange en metod som automatiskt populerar sqlfrågan med korrekt referens till en kolumn. Vi vill ju gärna ha samma namn på metoderna (eller "propertys" beroende på hur man ser det) i datalagret som kolumnnamnen, annars så blir det ju att hålla reda på dubbelt så många namn, kanske tom behöver dokumentation över varje klass.

Nej, verktyget använder sig av en tabell med info över tabellerna i databasen, exempelvis tabellprefix, klassnamn i singular och plural etc (det skapas singel och multiklasser för varje tabell)

Det här pratade vi om, quote "- fält döps till tabellnamn_fältnamn", inte specifikt pk'n

eg0master

2005-07-24 14:07

Robert ett exempel skulle vara värdefullt för jag förstår fortfarande inte hur ditt ramverk är tänkt att användas?
Om man har en access klass per tabell borde det ju bara bli en enda metod som heter "ID" per klass, eller?
Det låter på ditt resonemang som om du har en klass som används för att söka ut flera olika saker ur olika tabeller.

Ett enkelt exempel behövs för att vi skall kunna föra diskussionen vidare. Jag kan bara gissa hur ni gjort ert ramverk och i alla fall jag kan kan komma på är bara "tabellnamn_kolumnnamn" en genväg och inget som skulle behövas.

Du skrev själv tidigare: "då ska det synas vilken tabell den ska peka mot genom att läsa på kolumnnamnet" - något som ju framgår tydligt i mitt exempel utan att ha Customer_ID som kollumnnamn i Customer tabellen.

Robert

2005-07-24 19:13

Citat:

Originally posted by eg0master@Jul 24 2005, 14:07
Robert ett exempel skulle vara värdefullt för jag förstår fortfarande inte hur ditt ramverk är tänkt att användas?
Om man har en access klass per tabell borde det ju bara bli en enda metod som heter "ID" per klass, eller?
Det låter på ditt resonemang som om du har en klass som används för att söka ut flera olika saker ur olika tabeller.

Ett enkelt exempel behövs för att vi skall kunna föra diskussionen vidare. Jag kan bara gissa hur ni gjort ert ramverk och i alla fall jag kan kan komma på är bara "tabellnamn_kolumnnamn" en genväg och inget som skulle behövas.

Du skrev själv tidigare: "då ska det synas vilken tabell den ska peka mot genom att läsa på kolumnnamnet" - något som ju framgår tydligt i mitt exempel utan att ha Customer_ID som kollumnnamn i Customer tabellen.

Jo visst, ditt exempel visar åtminstonde för en människa att dina kolumner hör ihop, men idén från min sida är att ett kolumnnamn ska vara unikt per databas, alltså tex kategori_id ska det heta oavsett om det är en pk för tex en tabell med kategorier eller om det är en fk i en annan tabell som pekar mot kategoritabellen. Om vi antar att vi har 2 olika tabeller med prefixen "cus" (som i customer) och "cem" (som i customer employee) så skulle det kunna se ut såhär:

tabell 1: tblCustomers
-------------------------------
nCusID
sCusName
dCusCreatedDate

tabell 2: tblCustomerEmplyees
-------------------------------
nCemID
nCusID <--- koppling med samma namn som för fältet i tabell tblCustomer!!!
sCemFirsname
sCemLastname
dCemEmployeeDate

Och ang. klasserna, nja det genereras även klasser som kan hämta data beroende på fk, dvs den hämtar inte bara data ifrån samma tabell. Nu är jag inte någon databasexpert och behöver inte vara det heller med det fina sällskap jag sitter med här på jobbet, men jag litar på att dom har 100% koll på vad dom gör.

Jag försökte bara förklara varför det kan vara en bra idé att döpa kolumnerna till annat än bara "id" för pk's. Kan någon berätta motsatsen, varför man INTE ska göra så, utan behålla sina "id" (bortsett från "det är jobbigt att skriva" och "jag har artros i fingerlederna" eller "mitt tangentbord saknar vissa tangenter") :)

eg0master

2005-07-24 21:26

Citat:

Originally posted by Robert@Jul 24 2005, 19:13
Jag försökte bara förklara varför det kan vara en bra idé att döpa kolumnerna till annat än bara "id" för pk's. Kan någon berätta motsatsen, varför man INTE ska göra så, utan behålla sina "id" (bortsett från "det är jobbigt att skriva" och "jag har artros i fingerlederna" eller "mitt tangentbord saknar vissa tangenter") :)

haha, jag ger upp. :D
Ni har uppenbarligen valt att gå en väg som jag inte tror att jag själv skulle valt någonsin. Men ni har valt en namnstandard som säger att nCusID ska vara namnet på Customer ID oavsett tabell. Fortsatt diskussion blir bara ett religionskrig.
Bortsett ifrån sjukdomar i fingrarna så är det kortare "ID" för primärnyckeln just det att det blir tydligt vad som är en typisk primärnyckel. Om jag gör en select med en massa tabeller (med alias på tabellerna) så kanske det blir otydligt vilken som är PK och vilken som är FK om de har samma namn. men som sagt, detta kommer bli ett religionskrig om vi fortsätter.

Jag tror dina databasexperter är tacksamma för ditt förtroende. Själv blir jag misstänksam mot folk som namger kolumner som i ditt exempel... <_<

och hur gör ni om ni har en relationstabell? säg att ni vill ha en relation mellan två customers?

tblCustomerRelation
--------------------------
nCusID
nCusID
nRelTypeID

Ert sätt att namnge kolumner utesluter ju denna typ av tabeller om jag förstår dig rätt.

Alla tider är GMT +2. Klockan är nu 10:48.

Sidan 2 av 2

Visa 40 inlägg från det här ämnet på en sida