Đặt tên cho các cột ID trong bảng cơ sở dữ liệu

Tôi đã tự hỏi ý kiến ​​của mọi người về việc đặt tên cho các cột ID trong bảng cơ sở dữ liệu.

Nếu tôi có một bảng được gọi là Hóa đơn với khóa chính của cột nhận dạng, tôi sẽ gọi cột đó là InvoiceID để tôi không xung đột với các bảng khác và rõ ràng đó là gì.

Nơi tôi đang làm việc hiện tại họ đã gọi tất cả các cột ID là ID.

Vì vậy, họ sẽ làm như sau:

Select  
    i.ID 
,   il.ID 
From
    Invoices i
    Left Join InvoiceLines il
        on i.ID = il.InvoiceID

Bây giờ, tôi thấy một vài vấn đề ở đây:
1. Bạn sẽ cần đặt bí danh cho các cột trên lựa chọn
2. ID = InvoiceID không phù hợp với não của tôi
3. Nếu bạn không đặt bí danh cho các bảng và tham chiếu đến InvoiceID thì rõ ràng là bảng nào. nó đang ở trên?

Những người khác nghĩ gì về chủ đề này?

ID là một phản vật chất SQL. Xem http://www.amazon.com/s/ref=nb_sb_ss_i_1_5?url=search-alias%3Dstripbooks&field-keywords=sql+antipatterns&sprefix=sql+a

Nếu bạn có nhiều bảng với ID là id, bạn đang làm cho việc báo cáo khó khăn hơn nhiều. Nó che khuất ý nghĩa và làm cho các truy vấn phức tạp khó đọc hơn cũng như yêu cầu bạn sử dụng bí danh để phân biệt trên chính báo cáo.

Hơn nữa, nếu ai đó đủ ngu ngốc để sử dụng một liên kết tự nhiên trong cơ sở dữ liệu mà họ có sẵn, bạn sẽ tham gia vào các bản ghi sai.

Nếu bạn muốn sử dụng cú pháp USING mà một số dbs cho phép, bạn không thể sử dụng ID.

Nếu bạn sử dụng ID, bạn có thể dễ dàng kết thúc với một kết hợp nhầm lẫn nếu bạn tình cờ sao chép cú pháp tham gia (đừng nói với tôi rằng không ai làm điều này!) Và quên thay đổi bí danh trong điều kiện tham gia.

Vì vậy, bây giờ bạn có

select t1.field1, t2.field2, t3.field3
from table1 t1 
join table2 t2 on t1.id = t2.table1id
join table3 t3 on t1.id = t3.table2id

khi bạn muốn nói

select t1.field1, t2.field2, t3.field3 
from table1 t1 
join table2 t2 on t1.id = t2.table1id
join table3 t3 on t2.id = t3.table2id

Nếu bạn sử dụng tablenameID làm trường id, loại lỗi ngẫu nhiên này ít có khả năng xảy ra hơn và dễ tìm hơn nhiều.

Tôi luôn ưu tiên ID cho TableName + ID cho cột id và sau đó TableName + ID cho khóa ngoại. Bằng cách đó, tất cả các bảng có cùng tên cho trường id và không có mô tả thừa. Điều này có vẻ đơn giản hơn với tôi vì tất cả các bảng có cùng tên trường khóa chính.

Vì việc nối các bảng và không biết trường Id thuộc bảng nào, theo tôi câu truy vấn nên được viết để xử lý tình huống này. Ở nơi tôi làm việc, chúng tôi luôn ưu tiên các trường chúng tôi sử dụng trong một câu lệnh có bí danh bảng / bảng.

Họ đã là một cuộc chiến của mọt sách về điều này trong công ty của tôi vào cuối năm. Sự ra đời của LINQ đã làm cho mẫu bảng tên + ID thừa trở nên ngớ ngẩn hơn trong mắt tôi. Tôi nghĩ rằng mọi người hợp lý nhất sẽ nói rằng nếu bạn đang viết SQL của mình theo cách mà bạn phải chỉ định tên bảng để phân biệt các FK thì nó không chỉ giúp tiết kiệm việc nhập mà còn bổ sung thêm sự rõ ràng cho SQL của bạn để sử dụng ID mà bạn có thể thấy rõ ràng đâu là PK và đâu là FK .

Ví dụ

TỪ Nhân viên e THAM GIA TRÁI Khách hàng c TRÊN e.ID = c.EFasteeID

không chỉ nói với tôi rằng cả hai được liên kết, mà còn là PK và đâu là FK . Trong khi ở kiểu cũ, bạn buộc phải nhìn hoặc hy vọng rằng chúng được đặt tên tốt.

Chúng tôi sử dụng InvoiceID, không ID. Nó làm cho các truy vấn dễ đọc hơn - khi bạn nhìn thấy IDmột mình, nó có thể có ý nghĩa gì, đặc biệt là khi bạn đặt bí danh cho bảng i.

Tôi đồng ý với Keven và một vài người khác ở đây rằng PK cho một bảng chỉ nên là Id và các khóa ngoại liệt kê OtherTable + Id.

Tuy nhiên, tôi muốn thêm một lý do mà gần đây đã tạo thêm sức nặng cho cuộc tranh luận này.

Ở vị trí hiện tại của tôi, chúng tôi đang sử dụng khung thực thể bằng cách sử dụng tạo POCO. Sử dụng quy ước đặt tên tiêu chuẩn của Id, PK cho phép kế thừa một lớp poco cơ sở với xác thực và như vậy đối với các bảng chia sẻ một tập hợp các tên cột chung. Việc sử dụng Tên bảng + Id làm PK cho mỗi bảng này sẽ phá hủy khả năng sử dụng lớp cơ sở cho các bảng này.

Chỉ là một số thức ăn để suy nghĩ.

Tùy chọn của tôi cũng là ID cho khóa chính và TableNameID cho khóa ngoại. Tôi cũng muốn có một cột "tên" trong hầu hết các bảng nơi tôi giữ mã định danh người dùng có thể đọc được (tức là tên :-)) của mục nhập. Cấu trúc này mang lại sự linh hoạt tuyệt vời trong chính ứng dụng, tôi có thể xử lý hàng loạt các bảng theo cách tương tự. Đây là một điều rất mạnh mẽ. Thông thường một phần mềm OO được xây dựng trên cơ sở dữ liệu, nhưng bộ công cụ OO không thể được áp dụng vì bản thân db không cho phép nó. Có id và tên cột vẫn chưa tốt lắm, nhưng đó là một bước.

Chọn
i.ID, il.ID Từ Hóa đơn tôi Còn lại Tham gia các Dòng Hóa đơn trên i.ID = il.InvoiceID

Tại sao tôi không thể làm điều này?

Select  
    Invoices.ID 
,   InvoiceLines.ID 
From
    Invoices
    Left Join InvoiceLines
        on Invoices.ID = InvoiceLines.InvoiceID

Theo tôi điều này rất dễ đọc và đơn giản. Nói chung, đặt tên cho các biến là i và il là một lựa chọn tồi.

Nó không thực sự quan trọng, bạn có thể gặp phải các vấn đề về simalar trong tất cả các quy ước đặt tên.

Nhưng điều quan trọng là phải nhất quán để bạn không phải nhìn vào định nghĩa bảng mỗi khi viết truy vấn.

Tôi mới bắt đầu làm việc ở một nơi chỉ sử dụng "ID" (trong các bảng cốt lõi, được tham chiếu bởi TableNameID trong các khóa ngoại) và đã tìm thấy HAI sự cố sản xuất do nó trực tiếp gây ra.

Trong một trường hợp, truy vấn đã sử dụng "... where ID in (CHỌN ID FROM OtherTable ..." thay vì "... where ID in (SELECT TransID FROM OtherTable ...".

Bất cứ ai có thể thành thật nói rằng sẽ không dễ phát hiện hơn nếu tên đầy đủ, nhất quán được sử dụng ở nơi mà câu lệnh sai sẽ đọc "... where TransID in (SELECT OtherTableID from OtherTable ..."? Tôi không nghĩ là vì thế.

Sự cố khác xảy ra khi cấu trúc lại mã. Nếu bạn sử dụng bảng tạm thời trong khi trước đó truy vấn đi ra khỏi bảng lõi thì mã cũ ghi "... dbo.MyFunction (t.ID) ..." và nếu điều đó không được thay đổi nhưng "t" bây giờ đề cập đến một bảng tạm thời thay vì bảng cốt lõi, bạn thậm chí không gặp lỗi - chỉ là kết quả sai.

Nếu tạo ra các lỗi không cần thiết là một mục tiêu (có thể một số người không có đủ công việc?), Thì loại quy ước đặt tên này là tuyệt vời. Nếu không, đặt tên nhất quán là cách để đi.

Để đơn giản, hầu hết mọi người đặt tên cho cột trên ID bảng. Nếu nó có tham chiếu khóa ngoại trên bảng khác, thì họ gọi nó là InvoiceID (để sử dụng ví dụ của bạn) trong trường hợp tham gia, dù sao thì bạn cũng đang đặt bí danh cho bảng nên inv.ID rõ ràng vẫn đơn giản hơn inv.InvoiceID

Cá nhân tôi thích (như đã nói ở trên) Table.ID cho PK và TableID cho FK . Ngay cả (xin đừng bắn tôi) Microsoft Access cũng khuyến nghị điều này.

TUY NHIÊN, TÔI CŨNG biết một thực tế là một số công cụ tạo ưu tiên TableID cho PK vì chúng có xu hướng liên kết tất cả tên cột có chứa 'ID' trong từ, BAO GỒM ID !!!

Ngay cả trình thiết kế truy vấn cũng thực hiện điều này trên Microsoft SQL Server (và đối với mỗi truy vấn bạn tạo, bạn sẽ cắt bỏ tất cả các mối quan hệ không cần thiết mới được tạo trên tất cả các bảng trên ID cột)

Vì vậy, nhiều khi OCD nội bộ của tôi ghét nó, tôi sử dụng quy ước TableID . Hãy nhớ rằng nó được gọi là Data BASE , vì nó sẽ là cơ sở cho hy vọng có nhiều ứng dụng trong tương lai. Và tất cả các công nghệ nên được hưởng lợi từ một Lược đồ mô tả rõ ràng và chuẩn hóa.

Không cần phải nói rằng tôi NÊN vẽ dòng của mình khi mọi người bắt đầu sử dụng TableName, TableDescription, v.v. Theo tôi, các quy ước nên làm như sau:

• Tên bảng: Đa dạng. Ví dụ. Nhân viên

• Bí danh bảng: Tên đầy đủ của bảng, số dị. Ví dụ.

  SELECT Employee.*, eMail.Address
  FROM Employees AS Employee LEFT JOIN eMails as eMail on Employee.eMailID = eMail.eMailID -- I would sure like it to just have the eMail.ID here.... but oh well

[Cập nhật]

Ngoài ra, có một số bài đăng hợp lệ trong chủ đề này về các cột trùng lặp do "loại mối quan hệ" hoặc vai trò. Ví dụ, nếu một Cửa hàng có EmployeeID , điều đó cho tôi biết là ngồi xổm. Vì vậy, đôi khi tôi làm một cái gì đó như Store.EaffeeID_Manager . Chắc chắn là nó lớn hơn một chút nhưng ở đó mọi người sẽ không phát điên khi cố gắng tìm ManagerID bảng hoặc những gì EmployeeID đang làm ở đó. Khi truy vấn là WHERE, tôi sẽ đơn giản hóa nó thành: SELECT EmployeeID_Manager làm ManagerID FROM Store

Đến đây từ quan điểm của một từ điển dữ liệu chính thức, tôi sẽ đặt tên cho phần tử dữ liệu invoice_ID. Nói chung, tên phần tử dữ liệu sẽ là duy nhất trong từ điển dữ liệu và lý tưởng là sẽ có cùng một tên trong suốt, mặc dù đôi khi các thuật ngữ đủ điều kiện bổ sung có thể được yêu cầu dựa trên ngữ cảnh, chẳng hạn như phần tử dữ liệu được đặt tên employee_IDcó thể được sử dụng hai lần trong biểu đồ tổ chức và do đó đủ điều kiện như supervisor_employee_IDvà subordinate_employee_IDtương ứng.

Rõ ràng, các quy ước đặt tên là chủ quan và là một vấn đề của phong cách. Tôi thấy các hướng dẫn ISO / IEC 11179 là một điểm khởi đầu hữu ích.

Đối với DBMS, tôi thấy các bảng là tập hợp các entite (ngoại trừ những bảng chỉ chứa một hàng, ví dụ bảng cofig, bảng hằng số, v.v.), ví dụ như bảng nơi tôi employee_IDlà khóa sẽ được đặt tên Personnel. Vì vậy, ngay lập tức TableNameIDquy ước không hiệu quả với tôi.

Tôi đã thấy TableName.ID=PK TableNameID=FKphong cách được sử dụng trên các mô hình dữ liệu lớn và phải nói rằng tôi thấy nó hơi khó hiểu: Tôi thích tên của một số nhận dạng giống nhau trong suốt, tức là không thay đổi tên dựa trên bảng mà nó xuất hiện. Một điều cần lưu ý là phong cách nói trên dường như được sử dụng trong các cửa hàng thêm IDENTITYcột (tự động tăng) vào mỗi bảng trong khi loại bỏ các khóa tự nhiên và khóa ghép trong các khóa ngoại. Những cửa hàng này có xu hướng không có từ điển dữ liệu chính thức cũng như không xây dựng từ các mô hình dữ liệu. Một lần nữa, đây chỉ là một câu hỏi về phong cách và một câu hỏi mà cá nhân tôi không đăng ký. Vì vậy, cuối cùng, nó không dành cho tôi.

Tất cả những gì đã nói, tôi có thể thấy một trường hợp đôi khi bỏ từ định nghĩa khỏi tên cột khi tên của bảng cung cấp bối cảnh để làm như vậy, ví dụ như phần tử được đặt tên employee_last_namecó thể trở thành đơn giản last_nametrong Personnelbảng. Cơ sở lý luận ở đây là miền là 'họ của mọi người' và có nhiều khả năng bị chỉnh sửa UNIONvới last_namecác cột từ các bảng khác hơn là được sử dụng làm khóa ngoại trong bảng khác, nhưng sau đó ... tôi có thể thay đổi ý kiến ​​của mình, đôi khi bạn không bao giờ có thể nói. Đó là vấn đề: mô hình hóa dữ liệu là một phần nghệ thuật, một phần khoa học.

Tôi nghĩ bạn có thể sử dụng bất kỳ thứ gì cho "ID" miễn là bạn nhất quán. Bao gồm cả tên bảng là quan trọng. Tôi khuyên bạn nên sử dụng một công cụ mô hình hóa như Erwin để thực thi các quy ước và tiêu chuẩn đặt tên để khi viết truy vấn, bạn có thể dễ dàng hiểu được các mối quan hệ có thể tồn tại giữa các bảng.

Ý tôi muốn nói trong câu lệnh đầu tiên là, thay vì ID, bạn có thể sử dụng một cái gì đó khác như 'recno'. Vì vậy, sau đó bảng này sẽ có PK của bill_recno, v.v.

Chúc mừng, Ben

Phiếu bầu của tôi là InvoiceID cho ID bảng. Tôi cũng sử dụng quy ước đặt tên tương tự khi nó được sử dụng làm khóa ngoại và sử dụng các tên bí danh thông minh trong các truy vấn.

 Select Invoice.InvoiceID, Lines.InvoiceLine, Customer.OrgName
 From Invoices Invoice
 Join InvoiceLines Lines on Lines.InvoiceID = Invoice.InvoiceID
 Join Customers Customer on Customer.CustomerID = Invoice.CustomerID

Chắc chắn, nó dài hơn một số ví dụ khác. Nhưng hãy mỉm cười. Điều này dành cho hậu thế và một ngày nào đó, một số lập trình viên kém cỏi sẽ phải thay đổi kiệt tác của bạn. Trong ví dụ này không có sự mơ hồ và khi các bảng bổ sung được thêm vào truy vấn, bạn sẽ biết ơn vì sự dài dòng.

Đối với tên cột trong cơ sở dữ liệu, tôi sẽ sử dụng "InvoiceID".

Nếu tôi sao chép các trường vào một cấu trúc không tên thông qua LINQ, tôi có thể đặt tên nó là "ID" ở đó, nếu đó là ID duy nhất trong cấu trúc.

Nếu cột KHÔNG được sử dụng trong khóa ngoại, để nó chỉ được sử dụng để xác định duy nhất một hàng để chỉnh sửa chỉnh sửa hoặc xóa, tôi sẽ đặt tên là "PK".

Nếu bạn đặt tên duy nhất cho mỗi khóa, ví dụ: "Chemicals.invoice_id" thay vì "Chemicals.id", thì bạn có thể sử dụng toán tử "tham gia tự nhiên" và "sử dụng" mà không cần lo lắng. Ví dụ

SELECT * FROM invoices NATURAL JOIN invoice_lines
SELECT * FROM invoices JOIN invoice_lines USING (invoice_id)

thay vì

SELECT * from invoices JOIN invoice_lines
    ON invoices.id = invoice_lines.invoice_id

SQL đủ dài mà không làm cho nó dài hơn.

Những gì tôi làm để giữ mọi thứ nhất quán cho bản thân (trong đó bảng có một khóa chính của cột duy nhất được sử dụng làm ID) là đặt tên cho khóa chính của bảng Table_pk. Bất kỳ nơi nào tôi có khóa ngoại trỏ đến khóa chính của bảng đó, tôi gọi là cột PrimaryKeyTable_fk. Bằng cách đó, tôi biết rằng nếu tôi có Customer_pkbảng Khách hàng của mình vàCustomer_fk trong bảng Đơn hàng của mình, tôi biết rằng bảng Đơn hàng đang tham chiếu đến một mục nhập trong bảng Khách hàng.

Đối với tôi, điều này có ý nghĩa đặc biệt đối với các liên kết mà tôi nghĩ rằng nó đọc dễ dàng hơn.

SELECT * 
FROM Customer AS c
    INNER JOIN Order AS c ON c.Customer_pk = o.Customer_fk

FWIW, tiêu chuẩn mới của chúng tôi (thay đổi, uh, ý tôi là "tiến hóa", với mọi dự án mới) là:

• Tên trường cơ sở dữ liệu chữ thường
• Tên bảng viết hoa
• Sử dụng dấu gạch dưới để phân tách các từ trong tên trường - chuyển chúng thành chữ hoa Pascal trong mã.
• pk_ tiền tố có nghĩa là khóa chính
• _id hậu tố có nghĩa là một số nguyên, ID tăng tự động
• fk_ tiền tố có nghĩa là khóa ngoại (không cần hậu tố)
• _VW hậu tố cho lượt xem
• is_ tiền tố cho boolean

Vì vậy, một bảng có tên NAMES có thể có các trường pk_name_id, first_name, last_name, is_alive,và fk_companychế độ xem được gọi làLIVING_CUSTOMERS_VW , được xác định như sau:

CHỌN first_name, last_name
TỪ CONTACT.NAMES
WHERE (is_alive = 'True')

Tuy nhiên, như những người khác đã nói, bất kỳ kế hoạch nào cũng sẽ hoạt động miễn là nó nhất quán và không làm xáo trộn ý nghĩa của bạn một cách không cần thiết.

Tôi chắc chắn đồng ý với việc bao gồm tên bảng trong tên trường ID, vì lý do chính xác mà bạn đưa ra. Nói chung, đây là trường duy nhất mà tôi sẽ bao gồm tên bảng.

Tôi ghét cái tên id đơn giản. Tôi thực sự muốn luôn sử dụng hóa đơn_id hoặc một biến thể của nó. Tôi luôn biết bảng nào là bảng có thẩm quyền cho id khi tôi cần, nhưng điều này khiến tôi bối rối

SELECT * from Invoice inv, InvoiceLine inv_l where 
inv_l.InvoiceID = inv.ID 
SELECT * from Invoice inv, InvoiceLine inv_l where 
inv_l.ID = inv.InvoiceLineID 
SELECT * from Invoice inv, InvoiceLine inv_l where 
inv_l.ID = inv.InvoiceID 
SELECT * from Invoice inv, InvoiceLine inv_l where 
inv_l.InvoiceLineID = inv.ID 

Điều tồi tệ nhất là sự kết hợp mà bạn đề cập, hoàn toàn khó hiểu. Tôi đã phải làm việc với một cơ sở dữ liệu mà hầu như luôn luôn là foo_id ngoại trừ một trong những id được sử dụng nhiều nhất. Đó hoàn toàn là địa ngục.

Tôi thích Tên miền hơn || 'TÔI'. (tức là Tên miền + ID)

DomainName thường, nhưng không phải lúc nào cũng giống TableName.

Bản thân vấn đề với ID là nó không mở rộng quy mô lên. Khi bạn có khoảng 200 bảng, mỗi bảng có một cột đầu tiên được đặt tên là ID, dữ liệu bắt đầu giống nhau. Nếu bạn luôn đủ điều kiện ID với tên bảng, điều đó sẽ giúp một chút, nhưng không nhiều.

Tên miền & ID có thể được sử dụng để đặt tên cho các khóa ngoại cũng như khóa chính. Khi các khóa foriegn được đặt tên theo cột mà chúng tham chiếu, điều đó có thể giúp ích cho việc ghi nhớ. Về mặt hình thức, việc gắn tên của khóa ngoại với khóa mà nó tham chiếu là không cần thiết, vì ràng buộc toàn vẹn tham chiếu sẽ thiết lập tham chiếu. Nhưng nó cực kỳ tiện dụng khi đọc các truy vấn và cập nhật.

Thỉnh thoảng, Tên miền || Không thể sử dụng 'ID', vì sẽ có hai cột trong cùng một bảng có cùng tên. Ví dụ: Nhân viên.EFasteeID ​​và Nhân viên.SupervisorID. Trong những trường hợp đó, tôi sử dụng RoleName || 'ID', như trong ví dụ.

Cuối cùng nhưng không kém phần quan trọng, tôi sử dụng các phím tự nhiên thay vì các phím tổng hợp khi có thể. Có những trường hợp khóa tự nhiên không khả dụng hoặc không đáng tin cậy, nhưng cũng có rất nhiều tình huống mà khóa tự nhiên là lựa chọn phù hợp. Trong những trường hợp đó, tôi để khóa tự nhiên lấy tên mà nó sẽ có. Tên này thường thậm chí không có các chữ cái, 'ID' trong đó. Ví dụ: OrderNo trong đó No là chữ viết tắt của "Number".

Đối với mỗi bảng, tôi chọn một chữ cái viết tắt (ví dụ: Nhân viên => Trống)

Bằng cách đó, khóa chính tự động đánh số bằng số sẽ trở thành nkEmp .

Nó ngắn gọn, duy nhất trong toàn bộ cơ sở dữ liệu và tôi biết chính xác các thuộc tính của nó trong nháy mắt.

Tôi giữ nguyên các tên trong SQL và tất cả các ngôn ngữ tôi sử dụng (chủ yếu là C #, Javascript, VB6).

Xem các quy ước đặt tên của trang web Interakt để biết hệ thống đặt tên bảng và cột được suy nghĩ kỹ lưỡng . Phương thức này sử dụng một hậu tố cho mỗi bảng ( _prdcho bảng sản phẩm hoặc _ctgcho một bảng danh mục) và thêm hậu tố đó vào mỗi cột trong một bảng nhất định. Vì vậy, cột nhận dạng cho bảng sản phẩm sẽ là id_prdvà do đó là duy nhất trong cơ sở dữ liệu.

Họ tiến thêm một bước nữa để giúp hiểu về các khóa ngoại: Khóa ngoại trong bảng sản phẩm đề cập đến bảng danh mục sẽ là idctg_prdvì vậy có thể rõ ràng nó thuộc về bảng nào ( _prdhậu tố) và nó đề cập đến bảng nào (danh mục) .

Ưu điểm là không có sự mơ hồ với các cột nhận dạng trong các bảng khác nhau và bạn có thể biết ngay cột nào mà truy vấn đang đề cập đến bằng tên cột.

cũng xem Quy ước đặt tên khóa chính / khóa ngoại

Bạn có thể sử dụng quy ước đặt tên sau. Nó có những sai sót nhưng nó giải quyết được các vấn đề cụ thể của bạn.

1. Sử dụng biệt hiệu ngắn (3-4 ký tự) cho tên bảng, tức là Invoice - inv, InvoiceLines -invl
2. Đặt tên cho các cột trong bảng bằng cách sử dụng những biệt danh, tức là inv_id,invl_id
3. Đối với các cột tham chiếu sử dụng invl_inv_idcho các tên.

theo cách này bạn có thể nói

SELECT * FROM Invoice LEFT JOIN InvoiceLines ON inv_id = invl_inv_id