Trong thế giới cơ sở dữ liệu, có một số thứ được thống nhất chung. Tăng RAM phần lớn có lợi cho hệ thống DMBS. Phân tán dữ liệu và tệp nhật ký trên RAID giúp cải thiện hiệu suất.
Quy ước đặt tên không phải là một trong những điều đó.
Đây là một chủ đề phân cực một cách đáng ngạc nhiên, với những người ủng hộ các phương pháp luận khác nhau kiên định ở vị trí của họ. Và rất có tiếng nói và đam mê trong việc bảo vệ giống nhau của họ.
Bài viết này sẽ đi sâu vào một số quy ước cụ thể và lập luận của cả hai bên, đồng thời cố gắng trình bày một kết luận hợp lý cho mỗi điểm.
Cuộc tranh luận đa dạng tuyệt vời
Về cốt lõi, đây là một chủ đề đơn giản. Ví dụ, cách chính xác để đặt tên bảng có chứa thông tin khách hàng trong lược đồ cơ sở dữ liệu quan hệ là gì? Có phải là Customer hoặc Customer ?
Lập luận của cả hai bên rất nhiều.
Cái nhìn đầu tiên , việc nghĩ về một tập hợp các đối tượng ở số nhiều là điều tự nhiên. Một nhóm gồm nhiều cá nhân hoặc công ty sẽ là Khách hàng . Do đó, một bảng (là một tập hợp các đối tượng) nên được đặt tên ở số nhiều. Một hàng riêng lẻ trong bảng đó sẽ là một khách hàng .
Các nguyên tắc đặt tên của ISO / IEC, mặc dù đã được ghi ngày tháng, khuyến nghị các tên bảng đa năng và tên cột số ít.
Hầu hết các bảng hệ thống SQL Server sử dụng tên số nhiều ( sysnotifications , sysoperator ), nhưng điều này là không nhất quán. Tại sao sysproxylogin chứ không phải sysproxylogins ?
Trong các đối số cho tên bảng số nhiều, các hàng trong bảng cũng được tham chiếu như là 'thể hiện' của tổng thể - tương tự như các mục trong một tập hợp. Khách hàng xác định toàn bộ tập hợp; một khách hàng là một ví dụ về Khách hàng .
Ngược lại, có nhiều lý do để sử dụng tên đối tượng số ít.
Mặc dù có thể có nhiều mặt hàng (hoặc khách hàng ) trong một bảng, bản thân bảng có thể được coi là một thực thể duy nhất. hộp khách hàng không phải là “hộp khách hàng”, ngay cả khi nó có một lượng lớn khách hàng bên trong. Ngoài ra, có thể chỉ có một mục - hoặc không có - trong bảng, khiến "khách hàng" trở thành một từ nhầm lẫn.
Nếu bạn chọn thay đổi tên bảng dựa trên các biến thể của từ, sự mâu thuẫn có thể nhanh chóng xuất hiện. Mặc dù nhiều từ sẽ đơn giản ( Khách hàng trở thành Khách hàng , Sản phẩm trở thành Sản phẩm ), những từ khác có thể không. Trong trường hợp này, Người có thể trở thành Người hoặc Người ; số ít Moose sẽ giống với dạng số nhiều của nó, Moose . (Mặc dù tại sao bạn cần một bảng con nai sừng tấm?) Một quy ước chẳng hạn như People.FirstName bắt đầu trở nên không rõ ràng một cách khó hiểu.
Nếu sử dụng nhiều ngôn ngữ, tình hình thậm chí còn trở nên tồi tệ hơn. Bởi vì sự đa dạng của các từ có thể khác nhau theo nhiều cách (khách hàng, chuột, nai sừng tấm, trẻ em, khủng hoảng, âm tiết, máy bay), những người không phải là người bản ngữ có thêm những thách thức. Việc gắn các tên đối tượng số ít hoàn toàn tránh được vấn đề này.
Câu hỏi quy ước tình huống
Không có sự nhiệt tình với các quy ước trường hợp giống như với đa dạng hóa, nhưng các lập luận được đưa ra cho một số tùy chọn khác nhau. Chúng bao gồm:
- Trường hợp Pascal :Chữ cái đầu tiên của mỗi từ nối được viết hoa, như trong:
CustomerOrder -
Vỏ lạc đà :Chữ cái đầu tiên của từ đầu tiên là chữ thường; tất cả các từ được nối tiếp theo đều có chữ cái đầu tiên viết hoa, như trong:
customerOrderPascal Case đôi khi được coi là một loại phụ của Camel Case, nhưng Microsoft thường phân biệt giữa hai loại này.
Đối với các từ ít hơn ba ký tự, chỉ nên sử dụng chữ hoa, như trong
UIhoặcIO. - Dấu gạch dưới [Chữ hoa “C”] :Các từ được phân tách bằng dấu gạch dưới, như trong
Customer_Orderhoặccustomer_Order- nhiều quyết định hơn nữa!
Các nhà nghiên cứu tại Đại học Johns Hopkins đã tiến hành một nghiên cứu về hiệu quả của việc sử dụng dấu gạch dưới trong tên đối tượng lập trình. Họ nhận thấy rằng việc sử dụng Camel Case (hoặc Pascal Case) đã cải thiện độ chính xác và khả năng nhận dạng khi đánh máy. Dấu gạch dưới được sử dụng rộng rãi trong lập trình C, nhưng xu hướng là Camel / Pascal Case với sự nhấn mạnh gần đây về các ngôn ngữ kiểu Microsoft và Java.
Cũng như các chủ đề khác, sau đây một quy ước được thành lập quan trọng hơn việc lựa chọn của chính công ước.
Một cân nhắc bổ sung ở đây là phân biệt chữ hoa chữ thường của cơ sở dữ liệu. Đối chiếu SQL Server xác định độ nhạy này bằng ‘CS’ (phân biệt chữ hoa chữ thường) hoặc ‘CI’ (phân biệt chữ hoa chữ thường) trong tên đối chiếu. Ví dụ:
SQL_Latin1_General_Cp437_CS_AS_KI_WI: Case Sensitive
SQL_Latin1_General_Cp437_CI_AS_KI_WI: Case Insensitive
Trong các ảnh ghép phân biệt chữ hoa chữ thường, hãy Select * from myTable sẽ thất bại trước đối tượng MyTable . Điều này có thể làm cho dấu gạch dưới thích hợp hơn một chút để tránh nhầm lẫn, nhưng Intellisense cũng giúp loại bỏ lỗi đánh máy trong hầu hết các môi trường lập trình hiện đại.
Các cân nhắc khác của Quy ước Đặt tên
Cuộc tranh luận số ít so với số nhiều và câu hỏi tình huống lớn có thể là nơi trận chiến khốc liệt nhất, nhưng có ít nhất ba lĩnh vực khác cần lưu ý khi xem xét quy ước đặt tên.
Tránh sử dụng bất kỳ từ nào dành riêng cho SQL Server làm tên đối tượng. Điều này bao gồm cả bảng và cột. Ví dụ - Người dùng , Thời gian và Ngày được bảo lưu. Các từ khóa dành riêng có thể yêu cầu cẩn thận hơn để tham chiếu (chẳng hạn như sử dụng dấu ngoặc vuông) tùy thuộc vào ứng dụng gọi điện. Điều này cũng áp dụng cho không gian. Khoảng trắng trong tên đối tượng yêu cầu dấu ngoặc kép để tham chiếu.
Điều này cũng liên quan đến một khuyến nghị khác - độ chính xác. System.CreateDate rõ ràng hơn nhiều so với System.Date . Một mô hình được thiết kế tốt cho phép người xem hiểu ngay mục đích của các đối tượng bên dưới. Khi bất kỳ số nhận dạng nào được tham chiếu như khóa ngoại, hãy tự do trong tên - Customer.CustomerID chứ không phải là Customer.ID .
Tránh tiền tố và hậu tố cho bảng và dạng xem , chẳng hạn như tblTable . Ký hiệu Hungary (luôn được dùng để xác định cách sử dụng biến) đã được đưa vào các quy ước đặt tên SQL Server phổ biến, nhưng nó bị chế giễu rộng rãi. Số nhận dạng đối tượng phải mô tả những gì được chứa bên trong, không phải bản thân đối tượng.
Tuy nhiên, tiền tố hữu ích trong các đối tượng hỗ trợ SQL Server , vì chúng mô tả bản chất chức năng của đối tượng.
Sau đây là các tiền tố thường được chấp nhận cho các đối tượng SQL Server:
- IX:Chỉ mục
- PK:Khóa chính
- FK:Khoá ngoại
- CK:Kiểm tra Ràng buộc
- DF:Mặc định
- UQ đôi khi cũng được sử dụng cho các chỉ mục duy nhất.
Mô hình này minh họa các điểm được xác định ở trên. Nó không yêu cầu giải thích về bản chất của dữ liệu; các quy ước đặt tên số ít được sử dụng và các số nhận dạng rõ ràng được áp dụng.
Cuối cùng, có những thuận lợi và khó khăn đối với mỗi bên trong cuộc tranh luận đặt tên theo quy ước. Tuy nhiên, có một điểm chính mà cả hai bên có thể đồng ý:bất kể quyết định được đưa ra như thế nào, hãy nhất quán với quy ước đã chọn.
Bạn sử dụng quy ước đặt tên SQL nào và tại sao?
