Lite nyfiken om ni har någon bra fältnamnsstandard?

Min har jag komit på själv eller har tagit lite här och var.
Fördelar:
+ Unika fältnamn.
+ Lätt att se relationer i fältnamn

Nackdelar:
- Långa fältnamn!!!

Reglerna(Som jag kommer ihåg just nu).
* Alla namn: Använd Engelska ord i största möjliga grad
* Inga mellanslag: Ordavskiljning görs med Versal.
* TabellNamn: Vad tabeller innehåller för information. Skrivs i blural form (Ex. Customers, Orders, Employees, Categories, Products)
* Fältnamn: Skall ha tabellensnamn som prefix i singular form.
* Skall vara korta och beskrivande (Ex. CustomerID, CustomerName, EmployeeID, EmployeeFirstName, EmployeeLastName, CategoryID, CategoryName, ProductId, ProductName)
* För relationer(ForiegKeys) till andra tabeller skall fältnamnet vara tabellnamnet i singular (Ex. OrderCustomer, OrderEmployee, ProductCategory)

Klart intressant. Satt senast idag och funderade på en databas,

Håller med dig i dina punkter (stjärnor...) förutom några små detaljer.

När det gäller tabellnamn så sätter jag tbl som prefix, tex tblCustomers.

Jag undviker länga fältnamn och förkortar gärna tex Förnamn blir FName, Efternamn till LName. Är det många tabeller som används samtidigt så lägger man ändå till tblCustomers.FName.

Jag har sätt att det finns dom som vill sätta prefix på fältnamnen tex intMittTal, dteDatum, strFName osv men jag har aldrig känt att det ger något mervärde.

Jag har tidigare kört med svengelska men har ändrat till enbart (om möjligt) engelska och då för att slippa åäö.

Om det finns ID så änvänder jag tabellnamnet utan tbl tex CustomerID och om detta ID finns med i andra tabeller (relationer) så får den samma namn.

Mera såna inlägg!

/Janne

>Lite nyfiken om ni har någon bra fältnamnsstandard?
Ja, samma som din men jag kallar tabellerna vid "kortnamn" och alla nycklar ges namnet KORTNAMN_ID.
Ex:
Tabell:
Per_PERSONS
Fält:
Per_ID
Per_FirstName
Per_LastName

Relationer är mycket enkla att se, och man behöver inte använda tre tecken man kan anpassa sig (dela upp databasen på mindre domäner och använda ett eller två tecken). Sedan att det blir enkelt att välja alias för tabellerna i frågor också är ju inget minus...

Att göra Vyer som innehåller många tabeller tjänar också på det då man kan slänga in alla förkortningarna på tabellerna i vynamnet.
Samma sak med sp's.

Vad är poängen med att använda tbl på en tabell????
Det är ungefär lika meningslöst som att använda fld på fält...

Undrar Trash

Det kom från när jag höll kurser. Kursdeltagarna fick bättre grepp på vad som var databasen och vad som var tabell. Sen har det vart kvar och personligen trivs jag med det.

När jag skriver kod så vill jag att det ska "lysa" mot mig dvs jag ska kunna se ett eller flera ord och förstå vad det är utan att behöva sätta det i ett sammanhang.

/Janne

Ok jag förstår din poäng, men jag upplever det ändå som meningslöst, ungefär lika meningslöst som dom som envisas med att presentera datatyper och långa beskrivande fältnamn inne i databasen.

När jag modellerar något lite större (50+ tabeller) då brukar jag dokumentera hela modellen i en databas (i access) som jag sen kan använda för att konstruera frågeinnehåll ifrån. På så vis kan man också dra ut rapporter som beskriver den befintliga databasen och ha på ett papper vid sidan av tangentbordet. Det gör också att den oläsbarheten som min lösning inbjuder till försvinner...

Att du upplever något meningslöst betyder inte att det är meningslöst.

/Janne

Jag brukar använda tbl på tabellnamnet för att särskilja tabellerna från frågorna (qry) i Access. Kanske inte är ett stort problem, men i alla fall...:)

/Johan

En stor fördel med att inte döpa tabeller till tblXYZ är att om man senare vill ändra den till exempelvis en vy, eller distribuera tabellen till flera servrar och lägga en distribuerad vy över dem, men inte vill/kan ändra funktionalitet i applikationen som accessar den, så behöver man inte döpa vyn till något med tbl, vilket skulle verka förvirrande. Samma princip som att inte prefixa kolumner, för att slippa döpa om dem om man ändrar datatyp i dem. Prefix av denna typ är i mina ögon aldrig bra och ger framförallt aldrig ett nödvändigt mervärde. Det finns andra, bättre, sätt att ta reda på vad för datatyp eller typ av objekt etc någonting är än att läsa namnet på det. Det bäddar helt enkelt för trubbel.

I övrigt så håller jag med om att förkortningar är helt OK _om_ man använder SAMMA förkortningar ÖVERALLT i databasen, och då ALDRIG skriver ut hela namnet. Man får aldrig blanda. Dessutom ser jag ingen anledning att inte använda engelska till 100%. Mellanslag etc är totalt förbjudet.

Jag arbetar till 80% i access så därför har jag använt tbl. Ska förmodligen omvärdera min åsikt om detta när det gäller SQL-server.

/Janne

Här är den namnstandard jag brukar köra med:

table = t_<TAB>_<table name> ex. t_CUS_Customer
column = <TAB>_<column name> ex. CUS_Name
view = v_<view name> ex. v_MyCustomer
Stored procedure = p_<procedure name> ex. p_GetCustomer
System Stored procedure = sp_<procedure name> ex. sp_ListTempTables
Trigger = i_<i/u/d>_<table name> ex. t_i_Customer
Primary Key = pk_<TAB>_<key name> ex. pk_CUS_id
Foreign Key = fk_<TAB>_<TAB2>_<key name> ex: fk_CUS_ADR_id
Unique Constraint = u_<TAB>_<column name> ex. u_CUS_Name
Check Constraint = c_<TAB>_<column name> ex. c_CUS_Name
Default Constraint = d_<TAB>_<column name> ex. d_CUS_Name

Sen finns det några regler till detta som tex. max 30 tecken, inga blanks,
inga reserverad t-sql ord, inga svenska tecken, tabell namn skall vara i singularis.

jag håller med Trash på detta
varför vara jobbig å köra
tblTabell
å
fltFält
man _VET_ ju vad som är vad...
kan man inte det så får man ju läsa på lite..


Jag har itne heller fattar meningen med att köra så...

>Jag har itne heller fattar meningen med att köra så...

Varför hack upp sig på tre bostäver? Tar det en gång till så även Furious_Rage fattar varför: :-)

"Det kom från när jag höll kurser. Kursdeltagarna fick bättre grepp på vad som var databasen och vad som var tabell. Sen har det vart kvar och personligen trivs jag med det."

JohanD hade också en poäng med frågorna i Access dvs qry. Då är prefixet bekvämt.

Att koda tydligt dvs så andra kan läsa koden snabbt och enkelt är aldrig fel. Hux-flux ska en kod ändras och det är någon som kanske har programmerat mycket men knapp med SQL som ska titta i koden. Har man då skrivit den tydlig så blir den lättare att förstå. Jag har själv fått gå in i gamla koder som ser fär jävliga ut pga att personen som har skrivit koden använt prefix lite hur som helst. Att vara konsekvent är för det mesta aldrig fel när det gäller programmering eller har jag fel?

/Janne

Ska dra lite av mina slutsatser.

Finns många olika standarder folk använder. Vilken som är bra är ju svårt att avgöra. Inget jag tänker göra.

Fråga dig själv vilken du skulle föredra om du skulle börja redigera i ett befintligt projekt. Utan någon kunskap om projektet. För det är för andra programmerar som ska arbeta på ditt projekt som kommer ha mest gjädje av en bra namnstandard.

Någon mer som har något att säga om vårt ämne?

Japp, jag har en sak till i ämnet:
Var ytterst nogrann med att vara konsekvent när du modellerar och försök alltid att namnge sakerna ändamålsenligt dvs:
Tabell: Personer (det lär finnas fler än en person i den)
Nyckel: PersonID (Det lär bara vara en person per rad)
Främmande nycklar: FöretagsID (Nyckeln bör inte het ngt i stil med Arbetar_På bara för att vi har bytit tabell, då beskriver man ett sammanhang och inte en relation)

Japp, jag har en sak att tillägga (eller egentligen förtydliga). Precis som du säger ska man skriva kod och namnge saker för de som i ett senare skede kommer att underhålla koden. Därför använder jag aldrig ungersk notation (eller andra prefixvarianter) på exempelvis tabbeller, vyer, kolumner etc. Det är i min erfarenhet en av de största källorna till buggar som är halvt omöjliga att hitta i en applikation. Eftersom man (normalt sett) inte har möjlighet att ändra i en massa kod där man refererar till dessa objekt så kan man inte döpa om dem om man skulle exempelvis ändra datatyp, och allstå sitter man plötsligt med felaktiga prefix på sina objekt. Hur kul är det att ge sig in i en sådan kod och försöka fixa?