Tại sao tên cột tiền tố được coi là thực hành xấu?

Theo một bài viết SO phổ biến là nó được coi là một thực tiễn xấu đối với tên bảng tiền tố. Tại công ty của tôi, mỗi cột được tiền tố bởi một tên bảng. Điều này là khó khăn cho tôi để đọc. Tôi không chắc chắn lý do, nhưng việc đặt tên này thực sự là tiêu chuẩn của công ty. Tôi không thể chịu được quy ước đặt tên, nhưng tôi không có tài liệu để sao lưu lý luận của mình.

Tất cả những gì tôi biết là việc đọc AdventureWorks đơn giản hơn nhiều. Trong này công ty chúng tôi DB bạn sẽ thấy một bảng, Person và nó có thể có tên cột:

Person_First_Name
hoặc thậm chí là
Person_Person_First_Name (đừng hỏi tôi tại sao bạn nhìn thấy người 2x)

Tại sao nó được coi là một thực tiễn xấu để sửa tên cột? Có phải dấu gạch dưới được coi là xấu trong SQL không?

Underscores không phải là xấu chỉ khó hơn để gõ. Điều gì là xấu là thay đổi tiêu chuẩn giữa dòng mà không sửa chữa tất cả các đối tượng hiện có. Bây giờ bạn có personId, Person_id, v.v. và không thể nhớ bảng nào có sử dụng dấu gạch dưới hay không. Tính nhất quán trong cách đặt tên (ngay cả khi cá nhân bạn không thích tên) giúp mã hóa dễ dàng hơn.

Cá nhân tôi là nơi duy nhất tôi cảm thấy cần phải sử dụng tablename trong một cột là trên cột ID (việc sử dụng chỉ ID là một phản mẫu trong thiết kế cơ sở dữ liệu vì bất kỳ ai đã thực hiện các truy vấn báo cáo mở rộng đều có thể cho bạn biết. 12 cột trong truy vấn của bạn mỗi khi bạn viết báo cáo.) Điều đó cũng giúp bạn dễ dàng biết ngay các FK trong các bảng khác vì chúng có cùng tên.

Tuy nhiên, trong một cơ sở dữ liệu trưởng thành, việc thay đổi một tiêu chuẩn hiện có là công việc nhiều hơn so với giá trị hiện có. Chỉ cần chấp nhận đó là tiêu chuẩn và tiếp tục, có những điều quan trọng hơn nhiều cần phải được sửa chữa đầu tiên.

Một đối số cho tiền tố tên cột sẽ ngăn tên "va chạm" khi tham gia nhiều bảng VÀ khi người tạo truy vấn không sử dụng bí danh.

SELECT person.name, company.name FROM person JOIN company ON ...

SELECT * FROM person JOIN company ON ...

Cả hai truy vấn sẽ có hai cột "tên" ( name_1, name_2 ) mà không "nói" với thực thể nào thuộc về nó. Và bạn không bao giờ có thể chắc chắn về các tên cột được tạo (nó sẽ là name_2 hoặc name_3 hoặc ...). Nếu bạn sử dụng tiền tố tên bảng, tên cột sẽ là person_name , company_name để bạn biết mỗi tên thuộc về thực thể nào, cộng với bạn biết rằng tên cột sẽ không đổi (ví dụ: nếu bạn lấy chúng trong Java bằng JDBC ).

Cả hai đối số có thể bị bỏ qua nếu bạn sử dụng bí danh, nhưng tôi nghĩ rằng hầu hết các quy ước mã hóa được thi hành trong các công ty đều xuất phát từ việc nhiều lập trình viên (thiếu niên) không tuân theo các thực tiễn tốt. Trong trường hợp này, ví dụ, sử dụng ký tự đại diện trên câu lệnh SELECT có thể gây ra sự cố mà không có tiền tố tên.

Đối với dấu gạch dưới trong tên bảng và cột, tôi sử dụng nó rộng rãi vì tôi chỉ sử dụng chữ thường trong tên cộng với dấu gạch dưới làm dấu phân cách. Chỉ sử dụng chữ thường giúp phân biệt các từ định danh với các từ khóa SQL (mà tôi nhập vào tất cả chữ hoa):

SELECT person_name, COUNT(bought_product) FROM bought_products WHERE person_name LIKE 'A%'

Thêm các loại tiền tố đó vào tên cột sẽ làm cho một bảng khó phát triển hơn. Ví dụ: nếu cuối cùng bạn nhận ra rằng bạn muốn / cần thay đổi tên bảng, bạn sẽ phải sửa đổi toàn bộ cấu trúc bảng của mình (nghĩa là không chỉ tên của bảng, mà cả tên của tất cả các cột của nó). Điều này cũng sẽ gây khó khăn hơn cho việc cập nhật các chỉ mục của bảng và mã của các máy khách truy vấn nó.

Có những trường hợp ngoại lệ nếu được sử dụng một cách thận trọng (theo câu trả lời của Patrick Karker trên liên kết của bạn) cho các tên cột phổ biến (thường chỉ có ID, đôi khi là Tên) sẽ quá mơ hồ .

Một cách thực hành tốt nhất khác là luôn luôn đủ điều kiện các cột và đối tượng trong các truy vấn của bạn. Vì vậy, tiền tố cột trở thành moot và làm lộn xộn mã của bạn.

So sánh những điều này: cái nào dễ nhất trên mắt?

SELECT P.name, P.Salary FROM dbo.Person P

SELECT Person.Name, Person.Salary FROM dbo.Person Person

SELECT dbo.Person.name, dbo.Person.Salary FROM dbo.Person

SELECT Person.Person_name, Person.Person_Salary FROM dbo.Person Person

Nói chung, thực sự không có bất kỳ tiêu chuẩn phổ biến nào. Câu hỏi bạn liên kết đến có một số câu trả lời được bình chọn cao với các quy ước hoàn toàn khác nhau. Tất nhiên, mọi người sẽ bảo vệ các tiêu chuẩn của riêng mình, và điều quan trọng hơn nhiều là giữ các quy ước nhất quán trong một dự án.

Điều đó nói rằng, tên cột tiền tố dường như là quá mức cần thiết. Bạn đã biết bạn đang làm việc với bảng nào và tình huống có hai cột từ các bảng khác nhau có cùng tên có thể được giải quyết dễ dàng bằng cách sử dụng bí danh bảng hoặc cột.

Trong TSQL, bạn có thể tham khảo các trường ở dạng TableName.FieldName nếu bạn muốn tránh sự mơ hồ, vì vậy việc thêm tên bảng vào tên trường thực sự sẽ mất đi khả năng đọc làm cho nó là TableName.TableName_FieldName hoặc tương tự. Tôi nghĩ rằng sử dụng dấu gạch dưới hay không là một lựa chọn cá nhân nhiều hơn. Tôi thích CamelCase và tôi sử dụng _ khi tôi muốn thêm hậu tố hoặc tương tự, ví dụ TableName_Temp, nhưng đó chỉ là tôi.

Tôi đã từng làm việc trên một hệ thống nơi chúng tôi quyết định sử dụng các mã ngắn để tiền tố các cột. Các trường PK đã sử dụng "tên bảng đầy đủ" làm tiền tố và tất cả các cột khác sử dụng 2-4 ký tự một cách nhất quán làm tiền tố. Mỗi cột cũng sử dụng một miền dữ liệu làm hậu tố của nó. Nếu được thực hiện một cách nhất quán, nó có thể rất đẹp và sạch sẽ. Thật vô nghĩa khi một tiêu chuẩn đặt tên của loại này hoặc loại khác có nghĩa là mã hóa cẩu thả. Sự hiện diện của một tiêu chuẩn nhất quán là những gì quan trọng. Tôi đã thấy một số cơ sở dữ liệu không nhất quán vì không có tiêu chuẩn rõ ràng và nhiều hơn bất cứ điều gì khác cho tôi thấy rằng có thể có rắc rối trong cấu trúc dữ liệu. Nếu người thiết kế cơ sở dữ liệu thậm chí không thể đặt tên cho các đối tượng và con cái của họ,

Tiền tố là thực tiễn xấu vì nó gây ra vấn đề được thiết kế để ngăn chặn. Như bạn đã nói, rất khó để đọc các cột có tiền tố. Nếu bạn kết thúc với các tên cột trùng lặp trong một truy vấn nơi bạn tham gia hai bảng, bạn có thể giải quyết chúng hoặc là một dạng xem, thủ tục được lưu trữ hoặc hàm do người dùng bảng xác định, nó thực hiện cho bạn nếu bạn thấy mình liên tục tham gia các bảng cụ thể.

Theo như sử dụng gạch dưới trong tên bảng, đó là một lập luận tôn giáo. Cuối cùng, nếu tăng khả năng hiển thị và làm cho mọi thứ dễ dàng hơn cho nó. Tôi thường sẽ không bao giờ có khoảng trắng hoặc bảng trong một tên cột hoặc bảng. Tuy nhiên, tôi có thể tạo ngoại lệ cho các bảng hoặc dạng xem chỉ được sử dụng bởi gói báo cáo hoặc xuất sang tệp CSV.

Nhiều cơ sở dữ liệu có giới hạn nghiêm ngặt về số lượng ký tự trong một tên cột (ví dụ: Oracle).

Nếu bạn đang làm việc với cơ sở dữ liệu cho phép tên cột dài, nhưng sau đó bạn quyết định rằng bạn muốn di chuyển cấu trúc đó sang hệ thống cơ sở dữ liệu khác, các tiền tố sẽ tăng khả năng tên cột của bạn không hợp lệ.

Mặc dù hiện tại bạn đang làm việc với SQL Server, nhưng không ai có thể dự đoán được tương lai và có thể phần mềm của bạn có thể phải hoạt động trên nhiều cơ sở dữ liệu trong tương lai.

Xem xét việc viết một từ điển dữ liệu (hoặc "đăng ký"). Điều đó có nghĩa là một tài liệu chứa tất cả các thành phần dữ liệu trong mô hình của bạn: tên, mô tả, v.v. Nó phải độc lập với việc triển khai mô hình, ví dụ không nên đề cập đến tên bảng. Làm thế nào bạn định hướng các tên như 'ID', 'Loại' và 'Mã'?

Một cách tiếp cận là tuân theo các hướng dẫn của tiêu chuẩn quốc tế ISO / IEC 11179 - sau tất cả, tại sao lại phát minh lại bánh xe? Cấu trúc cơ bản là:

[Object] [Qualifier] Property RepresentationTerm

với các dấu phân cách giữa các phần tử: SQL không chơi tốt với khoảng trắng trong tên cột và dấu gạch dưới hoạt động tốt.

Tôi có cảm giác rằng ai đó trong tổ chức của bạn đã cố gắng tuân theo các nguyên tắc này khi họ đưa ra các tên nguyên tố như Person_Person_First_Name.

Ví dụ tôi muốn trình bày là từ điển dữ liệu của Dịch vụ Y tế Quốc gia Anh (NHS) .

Vì vậy, tôi không nghĩ rằng quy ước đặt tên bạn phải làm việc với âm thanh quá tệ.

Khi triển khai, ví dụ như trong SQL, một số dân gian muốn bỏ qua các thành phần phụ Object, Qualifier và Thuộc tính khi tên bảng cung cấp ngữ cảnh, ví dụ như person_first_nametrở thành first_nametrong Personbảng, v.v. Tuy nhiên, quy tắc ngón tay cái mà một thành phần dữ liệu không nên thay đổi tên của nó một cách đơn giản do vị trí của nó trong mô hình vật lý có vẻ tốt. Bất cứ ai nếu nghĩ rằng không tuân theo quy tắc này thì nên giao nhiệm vụ ghi lại tất cả các biến thể tên mà họ đã sử dụng :)

Bạn sẽ tìm thấy một bản tóm tắt hay về ISO 11179 trong cuốn sách Phong cách lập trình của Joe Celko , bao gồm bằng chứng cho việc thích dấu gạch dưới là dấu phân cách trong tên cột.

Một số người tìm thấy mã dễ dàng hơn để biết dữ liệu đến từ bảng nào, tuy nhiên, nếu bạn đang nói về một hệ thống hướng đối tượng, bạn nên sử dụng ngữ cảnh của tên để biết nó đến từ đâu, trong trường hợp này là tên bảng.

Cá nhân, tiền tố tên bảng là một dấu hiệu cho thấy các nhà phát triển không có nhiều kỹ năng và khi bạn đào sâu hơn, bạn sẽ thấy nhiều quy ước mã hóa xấu khác và nếu tôi phải đoán ứng dụng có quá nhiều bảng, là lỗi, v.v.