it-swarm-eu.dev

Proč lidé doporučují nepoužívat jméno „Id“ pro sloupec identity?

Naučil jsem se nepoužívat jméno Id pro sloupec identity v mých tabulkách, ale v poslední době jsem ho právě používal, protože je to jednoduché, krátké a velmi popisné o tom, co vlastně data jsou.

Viděl jsem, jak lidé navrhují předponu Id s názvem tabulky, ale zdá se, že to bude více práce pro osobu, která píše dotazy SQL (nebo programátora, pokud používáte ORM jako Entity Framework), zejména na delších názvech tabulek, například CustomerProductId nebo AgencyGroupAssignementId

Jeden dodavatel třetí strany, který jsme najali, abychom vytvořili něco pro nás, vlastně pojmenoval všechny své sloupce identity Ident, abychom se vyhnuli použití Id. Nejprve jsem si myslel, že to udělali, protože Id bylo klíčové slovo, ale když jsem se na to podíval, zjistil jsem, že Id není klíčové slovo v SQL Server 2005, což je to, co používáme .

Proč lidé doporučují nepoužívat jméno Id pro sloupec identity?

Úpravy: Abych to objasnil, neptám se, kterou pojmenovací konvenci použít, nebo na argumenty, aby používal jednu konvenci pojmenovávání nad druhou. Chci jen vědět, proč je doporučeno nepoužívat Id pro název sloupce identity.

Jsem jediný programátor, nikoli dba, a pro mě je databáze místem, kde lze ukládat moje data. Protože obvykle vytvářím malé aplikace a obvykle používám ORM pro přístup k datům, je běžný název pole pro pole identity mnohem snadnější. Chci tím vědět, na co mi chybí, a pokud existují nějaké opravdu dobré důvody, proč to neudělám.

69
Rachel

Zde je shrnutí všech odpovědí na výhody získané konvencí nepoužívat běžný název pro všechny primární klíče:

  • Méně chyb, protože pole identity nejsou pojmenována stejně

    Nelze omylem napsat dotaz, který se připojí na B.Id = B.Id Namísto A.Id = B.Id, Protože pole identity nebudou nikdy pojmenována přesně stejná.

  • Jasnější názvy sloupců.

    Pokud se podíváte na sloupec s názvem CustomerId, okamžitě víte, jaká data jsou v tomto sloupci. Pokud byl název sloupce něco obecného jako Id, musíte znát také název tabulky a zjistit, jaká data sloupec obsahuje.

  • Vyhýbá se zbytečným aliasem sloupců

    Nyní můžete napsat SELECT CustomerId, ProductId Z dotazu, který spojuje Customers s Products, místo SELECT Customer.Id as CustomerId, Products.Id as ProductId

  • Umožňuje syntaxi JOIN..USING

    Tabulky můžete spojit se syntaxí Customer JOIN Products USING (CustomerId), místo Customer JOIN Products ON Customer.Id = Products.Id

  • Klíč je snazší najít ve vyhledávání

    Pokud hledáte velké pole identity zákazníka, je hledání CustomerId mnohem užitečnější než hledání Id

Pokud si vzpomenete na další výhody, které má tato konvence pojmenování, dejte mi vědět a přidám ji do seznamu.

Zda se rozhodnete použít jedinečný nebo identický název sloupce pro pole identity, záleží na vás, ale bez ohledu na to, co si vyberete, buďte konzistentní :)

28
Rachel

Předpona názvu tabulky má velmi dobré důvody.

Zvážit:

TableA (id int identity, stringdata varchar(max))

TableB (id int identity, stringdata varchar(max))

Chceme DELETE ze záznamů TableA, které existují v obou tabulkách. Snadno, uděláme INNER JOIN:

DELETE a
FROM 
  TableA A
INNER JOIN 
  TableB B
    ON b.id = B.id

....a právě jsme vymazali všechny TableA. Neúmyslně jsme porovnali B's ID se sebou - každý záznam se shodoval a každý záznam byl vymazán.

Pokud byla pole pojmenována TableAId a TableBId, bylo by to nemožné (Invalid field name TableAid in TableB).

Osobně nemám problém s používáním jména id v tabulce, ale ve skutečnosti je lepší předmluvit jej s názvem tabulky (nebo jménem entity, pokud TableA byli lidé, pak PeopleId by také fungovalo dobře), aby se zabránilo náhodnému porovnání se špatným polem a něčeho vyhodit do vzduchu.

To také jasně ukazuje, odkud pocházejí pole v dlouhých dotazech se spoustou JOINs.

46
JNK

Většinou se jedná o to, aby se cizí klíče nestaly obrovskou bolestí. Řekněme, že máte dvě tabulky: Customer a CustomerAddress. Primární klíč pro oba je sloupec s názvem id, což je sloupec identity (int).

Nyní musíte mít zákaznické ID odkazováno z CustomerAddress. ID sloupce samozřejmě nemůžete pojmenovat, takže jdete s customer_id.

To vede k několika problémům. Nejprve si musíte důsledně pamatovat, kdy volat sloupec „id“ a kdy jej nazvat „customer_id“. A pokud to zkazíte, povede to k druhému problému. Pokud máte velký dotaz s asi tuctem spojení a nevracíte žádná data, bavte se hraním hry Where's Waldo a lovem tohoto překlepu:

ON c.id = ca.id

Jejda, měla být ON c.id = ca.customer_id. Nebo ještě lépe, pojmenujte své sloupce identity popisně, takže může být ON c.customer_id = ca.customer_id. Pokud tedy někde omylem použijete nesprávný alias tabulky, customer_id nebude sloupcem v této tabulce a zobrazí se vám chyba kompilace Nice, nikoli prázdné výsledky a následné zkrácení kódu.

Je pravda, že existují případy, kdy to nepomůže, například pokud potřebujete více vztahů s cizími klíči z jedné tabulky do jiné jediné tabulky, ale pojmenování všech primárních klíčů „id“ tam také nepomůže.

36
db2

Pro zkopírování mé odpovědi z propojené otázky:

Existuje situace, kdy nalepení „ID“ na každou tabulku není tím nejlepším nápadem: klíčové slovo USING, pokud je podporováno. Používáme jej často v MySQL.

Například pokud máte fooTable se sloupcem fooTableId a barTable s cizím klíčem fooTableId, pak mohou být vaše dotazy konstruovány takto:

SELECT fooTableId, fooField1, barField2 FROM fooTable INNER JOIN barTable USING (fooTableId)

To nejen šetří psaní, ale je mnohem lépe čitelné ve srovnání s alternativou:

SELECT fooTable.Id, fooField1, barField2 FROM fooTable INNER JOIN barTable ON (fooTable.Id = barTable.foTableId)
12
Izkata

Po normalizaci databázového schématu pro omezení redundance jsou tabulky rozděleny do menších tabulek s navázanými vztahy (jedna ku jedné, jedna k mnoha, mnoho k mnoha). V procesu se jednotlivá pole v původní tabulce mohou objevit ve více normalizovaných tabulkách.

Například databáze blogu by mohla vypadat takto ve své nenormalizované podobě, za předpokladu jedinečného omezení na jméno autora.

| Author_Nickname | Author_Email | Post_Title | Post_Body |
+-----------------+--------------+------------+-----------+
| dave            | [email protected]   | Blah       | Bla bla   |
| dave            | [email protected]   | Stuff      | I like    |
| sophie          | [email protected]     | Lorem      | Ipsum     |

Normalizace by poskytla dvě tabulky:

Autor:

| Author_Nickname | Author_Email |
+-----------------+--------------+
| dave            | [email protected]   |
| sophie          | [email protected]     |

Pošta

| Author_Nickname | Post_Title | Post_Body |
+-----------------+------------+-----------+
| dave            | Blah       | Bla bla   |
| dave            | Stuff      | I like    |
| sophie          | Lorem      | Ipsum     |

Zde by jméno_názevu bylo primárním klíčem pro tabulku autora a cizím klíčem v tabulce příspěvků. I když se jméno autora objeví ve dvou tabulkách, stále to odpovídá jediné informační jednotce, tj. každý název sloupce odpovídá jednomu poli.

V mnoha případech nemůže existovat jedinečné omezení na původní pole, takže jako primární klíč se místo toho používá numerické umělé pole. Tím se nezmění skutečnost, že každý název sloupce stále představuje jedno pole. V tradičním návrhu databáze odpovídají jednotlivé názvy sloupců jednotlivým polím, i když nejsou klíče. (např. jeden by používal part.partname a client.clientname než part.name a client.name ). Toto je důvod pro existenci INNER JOIN ... USING <key> a NATURAL JOIN syntaxe.

V dnešní době a s vrstvami ORM, které jsou snadno dostupné v mnoha jazycích, jsou však databáze často navrženy jako perzistenční vrstva pro OO jazyky), ve kterých je přirozené, že proměnné, které mají stejnou roli v různých třídách se nazývají stejné ( part.name a client.name , nikoli part.partname a client.clientname ). V takovém kontextu Mám tendenci používat 'ID' pro své primární klíče.

9
stilgar

Jeden dodavatel třetí strany, který jsme najali, abychom vytvořili něco pro nás, vlastně pojmenoval všechny své sloupce identity Ident jen proto, abychom se vyhnuli použití Id.

Použití „Ident“ namísto „Id“ ve skutečnosti nic neřeší, pokud se „Ident“ ve všech jejich tabulkách používá.

Existuje dobrý článek o konvence kódování SQL na webu Drupal site , který ukazuje dobrou praxi pro tuto situaci:

Je dobrým zvykem předponovat názvy tabulek názvem modulu, aby se zabránilo možným konfliktům v oboru názvů.

Z tohoto úhlu pohledu je vhodné používat CustomerProductId a AgencyGroupAssignment. Ano, je to docela výstižné. Dalo by se to zkrátit, ale největším bodem, který je třeba se zabývat, je , zda vývojář, který vás sleduje, bude rozumět tomu, co jste mysleli . IDS předsazené podrobnými názvy tabulek by neměly zanechávat dvojznačnost, co jsou to. A (pro mě) je to důležitější než uložení několika úhozů.

8
Aaron

Místo ID pojmenovávám sloupce ID zákazníka, takže při každém psaní

FROM dbo.Customers AS c JOIN dbo.CustomerOrders AS o

SQL Prompt okamžitě navrhuje následující

ON c.CustomerID = o.CustomerID 

Ušetří mi to pár úhozů. Přesto si myslím, že pojmenovací konvence jsou velmi subjektivní, a proto nemám silný názor tak či onak.

7
A-K

Je to stejný důvod, proč byste nechtěli pojmenovat všechna svá pole varcharů jako „UserText“ a „UserText1“, nebo proč byste nepoužívali „UserDate“ a „UserDate1“.

Obvykle pokud máte v tabulce pole identity, je to váš primární klíč. Jak byste vytvořili podřízenou tabulku s cizím klíčem k nadřazené tabulce, pokud byl primární klíč v obou tabulkách id?

Ne všichni souhlasí s touto metodologií, ale v mých databázích přiřazuji každé tabulce jedinečnou zkratku. PK pro tuto tabulku by měl být pojmenován PK_ [abbrv] ID. Pokud se používá jako FK kdekoli, pak bych použil FK_ [abbrv] ID. Teď mám nulovou odhad, jak zjistit, jaké jsou vztahy tabulky.

5
DForck42

V zásadě ze stejného důvodu obvykle nezadáváte parametry parametr1, parametr2 ... je to přesné, ale ne popisné. Pokud vidíte TableId, můžete pravděpodobně bezpečně předpokládat, že se používá k držení pk pro Table, bez ohledu na kontext.

Pokud jde o kohokoli, kdo použil Ident, zcela zmeškal tento bod, vzhledem k výběru mezi Ident a Id use Id. Ident je ještě více matoucí než Id.

Z kontextu lze Id považovat za primární klíč k nějaké tabulce (není to velmi užitečné, pokud id není vodítko), ale Ident to ani neřekne (nebo alespoň já), že. Nakonec bych zjistil, že Ident je krátký na identitu (tak či onak), ale čas, který jsem strávil přijetím na to, by byl zbytečný.

5
jmoreno

Použijte předponu, aby bylo možné použít stejný název v kontextu primárního i cizího klíče, takže můžete provést natural join/join ... using.

3
DrPizza