Sollte ich generische Namen oder stark typisierte Namen für die Primärschlüssel und Fremdschlüssel in einer Datenbank bevorzugen?

Question

Angenommen, ich habe zwei Tabellen in einer Eltern-Kind-Beziehung. Nennen wir sie "Standorte" und "Gebäude", wobei ein "Standort" ein Elternteil eines oder mehrerer "Gebäude" ist. Ich möchte, dass die IDs über Datenbanken hinweg eindeutig sind, daher werde ich GUIDs für die IDs verwenden.

Sollte ich generische Namen für die ID-Felder in den Tabellen oder stark typisierte Namen bevorzugen und warum?

Beispiel 1 (Generic Names):

CREATE TABLE sites (
    id VARCHAR(38) NOT NULL, 
    -- other attributes 
); 

CREATE TABLE buildings (
    id VARCHAR(38) NOT NULL, 
    parent_id VARCHAR(38) NOT NULL, 
    -- other attributes 
); 

Beispiel 2 (stark typisierten Names):

CREATE TABLE sites (
    site_guid VARCHAR(38) NOT NULL, 
    -- other attributes 
); 

CREATE TABLE buildings (
    building_guid VARCHAR(38) NOT NULL, 
    site_guid VARCHAR(38) NOT NULL, 
    -- other attributes 
); 

Answer 1

Ich bevorzuge die Verwendung von building_id, site_id, so dass der Spaltenname seinen Inhalt mehr als nur "id" definiert.Dies macht es auch möglich, die ANSI Join zu verwenden „mit“ Syntax:

select site.site_id, building.building_id 
from building 
join site using (site_id); 

Ein weiterer Vorteil besteht darin, dass, wenn solche Spalten in Abfragen verwendet werden (oder Ansichten oder Subqueries), sie wieder Aliasing nicht brauchen so oft - wie folgt aus:

select site.id as site_id, building.id as building_id 
from building 
join site on site.id = building.site_id; 

Answer 2

Eine Konvention ist alle der Felder in dem Gebäude Tabelle Präfix mit " building_ ", also hätten Sie" building_id "," building_name "usw. Fremdschlüssel, wie zum Beispiel" site_id ", behalten ihren ursprünglichen Namen, was es völlig offensichtlich macht, was vor sich geht.

bearbeiten

Ich sollte erwähnen, dass ich „_id“ über „_uid“ oder „_GUID“ entschieden, weil es nur ein ID-Feld ist so habe ich keinen Grund, seinem Datentyp zu betonen.

Answer 3

ziehe ich einfach id, da dieser Standard Konventionen ist, ist hier ein großer Link für alles Datenbank-Namenskonventionen: http://weblogs.asp.net/jamauss/pages/DatabaseNamingConventions.aspx#Columns

„Rule 2a (Identität Primärschlüsselfelder) - Für Felder, die der Primärschlüssel sind Um eine Tabelle zu identifizieren und jeden Datensatz in der Tabelle eindeutig zu identifizieren, sollte der Name einfach "Id" lauten, da es sich um ein Identifizierungsfeld handelt. Dieser Name steht auch näher an einem Eigenschaftsnamen wie "Id" in Ihren Klassenbibliotheken. Ein weiterer Vorteil dieses Namens ist, dass Sie für Joins so etwas wie "Kunden JOIN Bestellungen ON Customer.Id = Orders.CustomerId" sehen, mit denen Sie das Wort "Customer" ag vermeiden können ain nach der Kundentabelle. "

Answer 4

Es ist hauptsächlich eine Frage des Geschmacks. Es sollte eine gewisse Konsistenz über das Projekt geben. Am wichtigsten sind:

• , die Sie erinnern die Namen repetitiver Spalten, die Sie brauchen nicht in Tabellendefinitionen schauen einfache SQL eingeben fragt
• , die Sie brauchen nicht in den Code suchen oder Dokumentation zu grob versteht die Bedeutung eine Spalte

persönlich bevorzuge ich Ids mit dem gleichen Namen in dem ganzen Projekt. Es ist auch einfacher, generischen Code zu schreiben, der unabhängig von einer bestimmten Tabelle ist.

Für Fremdschlüssel Normalerweise verwende ich die <ForeignTable>_FK Muster. Wenn in derselben Tabelle mehr als ein Fremdschlüssel vorhanden ist, verwende ich den Rollennamen, wie im objektorientierten Entwurf üblich, <Role>_FK, zum Beispiel CurrentUser_FK.