Tôi tự hỏi thực tiễn tốt nhất là đặt tên khóa chính/khóa duy nhất trong cơ sở dữ liệu với nhiều bảng. Bạn có nên luôn gọi mỗi khóa chính của mỗi bảng là id hoặc không được có trường id trong mỗi bảng và chỉ cần đặt tên cho mỗi bảng là something1_id, something2_id, v.v ...?Đặt tên khóa chính là "id" so với "something_id" trong SQL
Dù bạn làm gì, hãy chọn cái này hay cái kia và bám theo tiêu chuẩn đó. Có những ưu điểm và nhược điểm cho mỗi loại.
Tôi thích SomethingID nhưng những người khác chỉ thích ID. Trong hệ thống tôi làm việc với có hơn một nghìn bảng và có PK và FK có cùng tên chính xác làm cho mọi thứ trở nên dễ dàng hơn.
Xin chào KM, cảm ơn. Vì vậy, chỉ cần miễn là không có cách nào vượt trội rõ ràng, tôi nghĩ rằng tôi sẽ gắn bó với 'somethingID'. –
@tim peterson, tất cả phụ thuộc vào cách bạn sử dụng SQL và những gì phù hợp với bạn. Điểm mấu chốt của truy vấn là lấy lại thông tin nhanh và tên cột sẽ không ảnh hưởng đến điều đó, việc sử dụng chỉ mục sẽ. –
Điều tồi tệ nhất tuyệt đối là các DB sử dụng nhiều quy ước đặt tên. Tôi đã làm việc trên một hệ thống sử dụng 4 quy ước đặt tên khác nhau cho PK thay thế. –
Đó là sở thích cá nhân. Vào cuối ngày, nó hoàn toàn không có sự khác biệt. Cá nhân tôi thích sử dụng chỉ Id như tôi tìm thấy đề cập đến lĩnh vực này (giả sử Customer bảng và Id trường) Customer.CustomerId là cồng kềnh, nơi Customer.Id dường như có ý nghĩa hơn.
Tôi khuyên bạn nên sử dụng tên viết tắt cho tên dài và sử dụng (cái gì đó) Id (như user_id) cho các bảng thông thường. Vì vậy, đối với bảng customer_company_relation_metadata, hãy sử dụng ccm_id. Nhưng cũng tốt khi sử dụng id cũng như
Vui lòng không sử dụng các từ viết tắt trong ngữ cảnh này, nó chỉ làm xáo trộn mã của bạn và ít có thể đọc được đối với các thành viên mới (nhóm) vào nhóm/mã của bạn (và thậm chí sau khi nghỉ ngơi). Tài liệu đọc tốt: http://programmers.stackexchange.com/a/24083 – Styxxy
@Styxxy Tôi đã tìm thấy chúng là cách hữu ích nhất giữa việc có các tên cột dài (gây khó chịu trong các truy vấn dài hơn) và phải sử dụng 'người dùng. id' mọi lúc. Nhưng tất nhiên là vấn đề về hương vị. –
Tên rất dài có thể được viết tắt, có thể.Tôi sẽ không sử dụng nó cho người dùng mặc dù (những gì là những 2 chữ cái nếu bạn trả rất nhiều trong dễ đọc?). Nó thực sự là một phần sở thích của bạn, nhưng viết tắt để viết tắt chỉ là đồng bằng sai (tôi sẽ không muốn duy trì mã như thế). PS: Nếu bạn có một trình soạn thảo phong nha, ngay cả tên dài cũng không thành vấn đề. – Styxxy
id chỉ là một quy ước thuận tiện - bạn có thể gọi trường bất cứ điều gì miễn là bạn khai báo trường đó làm trường khóa.
Tiền tố id với ngữ cảnh có liên quan có thể hữu ích khi đọc và viết mã của bạn và đặc biệt cải thiện khả năng đọc khi bạn đang nối dữ liệu từ nhiều bảng và khóa ngoài.
(* Chỉ là một suy nghĩ vì câu trả lời của bạn bắt gặp ánh mắt của tôi và tôi đang nghĩ về lập trình cho một giao diện. *) Đúng vậy, và tôi đồng ý, nhưng cách tiếp cận 'id' dịch các bản ghi bảng thành các đối tượng tốt hơn, đặc biệt nếu bạn có một siêu trừu tượng -class với thuộc tính 'id'. Nếu bạn làm những gì bạn đề nghị (mà tôi xảy ra để làm, quá), sau đó bạn cũng phải quản lý các lĩnh vực khác nhau 'blahId' và tài sản khi lập bản đồ bảng hồ sơ cho các đối tượng. Điều đó đúng với các khóa ngoại được dịch sang thuộc tính đối tượng, nhưng ít nhất lớp siêu trừu tượng chỉ có thể có một thuộc tính đơn giản có tên 'id'. –
Tuy nhiên, nó có thể có thuộc tính 'id', nhưng mã của bạn sẽ nhất quán theo chiều ngang trên các lớp siêu trừu tượng nếu chúng ta sử dụng' id', đặc biệt khi gán giá trị của trường 'id' vào thuộc tính' id'. Sự rõ ràng của cơ sở dữ liệu có thể bị một số, nhưng điều đó có thể được giảm thiểu bằng cách cho các khóa ngoại tên 'blahId'. Những cái tên đó sẽ thấm vào các đồ vật, nhưng bạn sẽ có thể biết được cái gì. –
Nó là một vấn đề ưu tiên; tuy nhiên, có một lợi thế khi sử dụng ID (cái gì đó) trong các tên cột đó trở nên ít mơ hồ hơn khi bạn đang thực hiện kết nối giữa các bảng.
vâng, cảm ơn tôi đồng ý, câu hỏi này đã xuất hiện khi tôi viết nhiều hơn và nhiều hơn nữa ... –
Có một lợi thế cho cả khi tham gia. Tôi thích 'id' cho tên cột vì tôi sẽ liệt kê tên bảng trước khi các cột trong * tất cả * tham gia, vì vậy' tablename_id' hoặc một cái gì đó tương tự chỉ là tính đặc biệt, không cần thiết. – 0b10011
@ bfrohs: Có, tôi đồng ý bao gồm tên bảng trong tên cột ID liên quan đến việc nhập nhiều hơn một chút. –
Có chùm bài viết trên mạng, đi kiểm tra này ra ...
Và quan trọng nhất, như KM đã nói ở trên, hãy chọn một & dính vào nó !!!! – larryr
'something_id' là không cần thiết khi bạn có thể sử dụng 'table.id' ở khắp mọi nơi ... trừ khi bạn đưa vào một khóa ngoại. –
Tôi luôn tự hỏi mọi người nghĩ gì về ưu và nhược điểm của phương pháp tiếp cận – erikkallen
vấn đề chính ở nước ngoài là lý do tại sao "ID" có thể gây nhầm lẫn - bởi vì bạn phải tạo mối quan hệ với "somethingID" trong một bảng khác; bạn đang tạo mối quan hệ trên các trường có tên khác nhau. – niico