[Disc/SQL] Welke naamgeving van velden gebruiken?

[pjonk]

Momenteel zit ik met een dilemma over de naamgeving van velden in mijn tabellen.
Aan de ene kant wil ik veldnamen niet onnodig lang maken om de SQL queries overzichtelijk te houden. Ean de andere kant wil ik wel dat de velden een duidelijke naam hebben, voornamelijk om velden uit elkaar te houden bij JOINS.

Nu heb ik de volgende varianten bedacht:

Variant 1: lange veldnamen

code:

CREATE TABLE producten (
  ProductID    smallint     UNSIGNED NOT NULL auto_increment,
  CategorieID  smallint     UNSIGNED NOT NULL,
  ProductNaam  varchar(50)  NOT NULL,
  PRIMARY KEY(ProductID)
);

CREATE TABLE categorie (
  CategorieID   smallint     UNSIGNED NOT NULL,
  CategorieNaam varchar(50)  NOT NULL,
  PRIMARY KEY(CategorieID)
);

code:

SELECT ProductNaam,CategorieNaam FROM producten
INNER JOIN categorie USING(CategorieID)

Variant 2: korte veldnamen in beide tabellen hetzelfde

code:

CREATE TABLE producten (
  ProductID    smallint     UNSIGNED NOT NULL auto_increment,
  CategorieID  smallint     UNSIGNED NOT NULL,
  Naam         varchar(50)  NOT NULL,
  PRIMARY KEY(ProductID)
);

CREATE TABLE categorie (
  CategorieID   smallint     UNSIGNED NOT NULL,
  Naam          varchar(50) NOT NULL,
  PRIMARY KEY(CategorieID)
);

code:

SELECT p.Naam,c.Naam FROM producten AS p
INNER JOIN categorie AS c USING(CategorieID)

Dit gaat helaas niet werken, omdat ik hier maar 1 veld terug krijg (in MySQL).
Een alternatieve oplossing:

code:

SELECT p.Naam AS ProductNaam,c.Naam AS CategorieNaam FROM producten AS p
INNER JOIN categorie AS c USING(CategorieID)

Variant 3: velden prefixen

code:

CREATE TABLE producten (
  ProductID    smallint     UNSIGNED NOT NULL auto_increment,
  CategorieID  smallint     UNSIGNED NOT NULL,
  pdtNaam      varchar(50)  NOT NULL,
  PRIMARY KEY(ProductID)
);

CREATE TABLE categorie (
  CategorieID   smallint     UNSIGNED NOT NULL,
  ctgNaam       varchar(50)  NOT NULL,
  PRIMARY KEY(CategorieID)
);

code:

SELECT pdtNaam,ctgNaam FROM producten
INNER JOIN categorie USING(CategorieID)

Welke naamgeving gebruik je zelf en zou je tevens kunnen beargumenteren waarom je die naamgeving gebruikt?

[Janoz]

Ikzelf gebruik gewoon korte namen. Prefixes vind ik persoonlijk redundante gegevens die in de query zelf wel naar voren komen (nu krijg je categorie.categorieID en categorie.ctgNaam). Het staat er dus dubbel in. Verder noem ik het id gewoon id. Hierdoor kan ik makkeliujker een super class voor mijn dataaccess schrijven omdat ik overal van id uit kan gaan (standaar insert (key generatie) en update functionaliteit).

Wat je zegt over die twee dezelfde namen is neit helemaal waar. Je resultaat heeft gewoon twee kolommen. PHP weet echter niet welke hij moet nemen (is niet een php ding hoor, dat is overal zo waar kolommen via de naam worden opgevraagd). Dit is inderdaad te omzeilen door as te gebruiken of door fetch_row gebruiken en dan de index te gebruiken. Beiden vind ik niet een onoverkomenlijk probleem.

[djluc]

Voorbeeldje2 zonder het woord product voor de id. Het is logisch dat een veld id de primary key is en dat je deze aanroept met products.id imo.

[Maasluip]

Ik ben zelf (bij mijn vorige baas) opgevoed met prefixes. Voor de veldnaam stond een 2-4 letterige prefix met een underscore. In jouw geval:

CREATE TABLE PRODUCTEN (
  PROD_id    smallint     UNSIGNED NOT NULL auto_increment,
  CAT_id     smallint     UNSIGNED NOT NULL,
  PROD_naam  varchar(50)  NOT NULL, PRIMARY KEY(ProductID)
);

CREATE TABLE categorie (
  CAT_id     smallint     UNSIGNED NOT NULL,
  CAT_naam   varchar(50)  NOT NULL, PRIMARY KEY(CategorieID)
);

Zoals je ziet, keys van andere tabellen (CAT_id) worden met dezelfde overgenomen. Op die manier heb je een duidelijk beeld wat tot de tabel hoort en wat ergens anders een key is. Ook in selecties is e.e.a. direkt duidelijk.

Je moet je wel goed afvragen wat goede afkortingen zijn. Zo kwamen er in latere versies van onze database steeds meer samengestelde tabellen bij (combinatie tussen tabel 1 en tabel 2) en de prefixes daarvan werden ook steeds wilder. LRPPLI_ voor de tabel LRP_POINT_LINE, waarbij de LRP in die tabelnaam ook al stond voor LROUTE_PLAN.
En na verloop van tijd refereer je niet meer naar de tabel met zijn naam maar met de prefix. Dat scheelt altijd een beetje tijd.

Oh ja, wat er bij ons ook nog in zat: er waren een paar verschillende pakketten met elk hun eigen databank. In elke databank begonnen de tabellen met de eerste letter van dat pakket. De produkt tabel in de ene databank was LPRODUCT, in de andere DPRODUCT en in een derde MPRODUCT. Die L/D/M komt dus ook weer terug in de prefix.

Geloof me: voor grote databanken maakt het dit een stuk overzichtelijker. Maar het is maar net wat je prettig en mooi vindt. Ik vind tegenwoordig tabellen waarvan niet 90% van de velden met dezelfde lettercombinatie beginnen erg rommelig.

Voor kleine databanken zou ik voor lange veldnamen gaan.

[ Voor 4% gewijzigd door Maasluip op 12-08-2004 11:27 ]

[pjonk]

Zelf gebruikte ik altijd variant 1, maar het voorkomen van redundantie is idd een goede reden om variant 2 te gaan gebruiken.
Bij primary keys gebruik ik liever volledige namen, omdat ik bij tabellen met foreign keys dan naar hetelfde veld kan verwijzen. Zo kan ik ook USING gebruiken in SQL.

Maar als ik het goed begrijp doen jullie liever het volgende:

code:

CREATE TABLE producten (
  ID           smallint     UNSIGNED NOT NULL auto_increment,
  CategorieID  smallint     UNSIGNED NOT NULL,
  Naam         varchar(50)  NOT NULL,
  PRIMARY KEY(ProductID)
);

CREATE TABLE categorie (
  ID   smallint     UNSIGNED NOT NULL,
  Naam varchar(50) NOT NULL,
  PRIMARY KEY(CategorieID)
);

code:

SELECT p.Naam,c.Naam FROM producten AS p
INNER JOIN categorie AS c ON (p.CategorieID = c.ID)

Ik heb echter ook tabellen met gecombineerde PRIMARY Keys, bijvoorbeeld:

code:

CREATE TABLE product_content (
  ProductID  smallint UNSIGNED NOT NULL,
  LanguageID smallint UNSIGNED NOT NULL,
  Content    TEXT,
  PRIMARY KEY(ProductID,LanguageID)
);

Dat vind ik persoonlijk duidelijker dan:

code:

CREATE TABLE product_content (
  ID         smallint UNSIGNED NOT NULL,
  LanguageID smallint UNSIGNED NOT NULL,
  Content    TEXT,
  PRIMARY KEY(ID,LanguageID)
);

[Janoz]

Bij de laatste is er niet een kolom die de identifier is van elk record in die tabel. Bij verwijzingen staat altijd de tabelnaam van die verwijzing ervoor. Een koppel tabel is dus inderdaad bij mij altijd

ProductID
LanguageID

Verder gebruik ik voor de 'as' vaak wat langere namen dan 1 letter of schrijf alles uit. Zolang je meerdere regels voor je query gebruikt is dat geen enkel probleem voor de overzichtelijkheid.