Các quy ước đặt tên cơ sở dữ liệu, bảng và cột? [đóng cửa]

Bất cứ khi nào tôi thiết kế một cơ sở dữ liệu, tôi luôn tự hỏi liệu có cách tốt nhất để đặt tên một mục trong cơ sở dữ liệu của tôi không. Tôi thường tự hỏi mình những câu hỏi sau:

1. Tên bảng có nên là số nhiều?
2. Tên cột có nên là số ít?
3. Tôi nên tiền tố bảng hoặc cột?
4. Tôi có nên sử dụng bất kỳ trường hợp trong việc đặt tên các mặt hàng?

Có bất kỳ hướng dẫn được đề xuất ngoài kia để đặt tên các mục trong cơ sở dữ liệu?

Tôi khuyên bạn nên kiểm tra cơ sở dữ liệu mẫu SQL Server của Microsoft: https://github.com/Microsoft/sql-server-samples/release/tag/adventureworks

Mẫu AdventureWorks sử dụng quy ước đặt tên rất rõ ràng và nhất quán sử dụng tên lược đồ để tổ chức các đối tượng cơ sở dữ liệu.

1. Tên số ít cho bảng
2. Tên số ít cho các cột
3. Tên lược đồ cho tiền tố bảng (Ví dụ: SchemeName.TableName)
4. Vỏ Pascal (còn gọi là vỏ lạc đà trên)

Câu trả lời muộn ở đây, nhưng tóm lại:

1. Sở thích của tôi là số nhiều
2. Đúng
3. Bảng : * Thông thường * không có tiền tố là tốt nhất. Cột : Không.
4. Cả bảng và cột: PascalCase.

Xây dựng:

(1) Những gì bạn phải làm. Có rất ít điều mà bạn phải làm theo một cách nhất định, mọi lúc, nhưng có một vài điều.

• Đặt tên cho các khóa chính của bạn bằng định dạng "[singularOfTableName] ID". Nghĩa là, cho dù tên bảng của bạn là Khách hàng hay Khách hàng , khóa chính phải là ID khách hàng .
• Hơn nữa, khóa ngoại phải được đặt tên nhất quán trong các bảng khác nhau. Nó là hợp pháp để đánh bại một người không làm điều này. Tôi sẽ trình bày rằng trong khi các ràng buộc khóa ngoài được xác định thường rất quan trọng, việc đặt tên khóa ngoại nhất quán luôn luôn quan trọng
• Cơ sở dữ liệu của bạn phải có quy ước nội bộ . Mặc dù trong các phần sau, bạn sẽ thấy tôi rất linh hoạt, trong cơ sở dữ liệu, việc đặt tên phải rất nhất quán. Việc bảng của bạn dành cho khách hàng được gọi là Khách hàng hay Khách hàng ít quan trọng hơn việc bạn thực hiện theo cùng một cách trong cùng một cơ sở dữ liệu. Và bạn có thể lật một đồng xu để xác định cách sử dụng dấu gạch dưới, nhưng sau đó bạn phải tiếp tục sử dụng chúng theo cùng một cách . Nếu bạn không làm điều này, bạn là một người xấu nên có lòng tự trọng thấp.

(2) Những gì bạn có thể nên làm.

• Các trường đại diện cho cùng một loại dữ liệu trên các bảng khác nhau nên được đặt tên giống nhau. Không có Zip trên một bảng và ZipCode trên một bảng khác.
• Để tách các từ trong tên bảng hoặc cột của bạn, hãy sử dụng PascalCasing. Sử dụng camelCasing sẽ không có vấn đề gì về bản chất, nhưng đó không phải là quy ước và nó sẽ trông buồn cười. Tôi sẽ giải quyết dấu gạch dưới trong giây lát. (Bạn không thể sử dụng ALLCAPS như ngày xưa. OBNOXIOUSTABLE.ANNOYING_COLUMN đã ổn trong DB2 20 năm trước, nhưng không phải bây giờ.)
• Đừng rút ngắn hoặc viết tắt các từ một cách giả tạo. Nó là tốt hơn cho một tên dài và rõ ràng hơn ngắn và khó hiểu. Tên siêu ngắn là một sự nắm giữ từ thời kỳ đen tối hơn, man rợ hơn. Cus_AddRef. Chuyện quái quỷ gì vậy? Tài liệu tham khảo người nhận giám sát? Hoàn tiền bổ sung của khách hàng? Địa chỉ giới thiệu tùy chỉnh?

(3) Những gì bạn nên xem xét.

• Tôi thực sự nghĩ rằng bạn nên có tên số nhiều cho các bảng; một số nghĩ rằng số ít. Đọc các đối số ở nơi khác. Tên cột phải là số ít tuy nhiên. Ngay cả khi bạn sử dụng tên bảng số nhiều, các bảng biểu thị sự kết hợp của các bảng khác có thể ở dạng số ít. Ví dụ: nếu bạn có Khuyến mãi và Vật phẩm bảng , một bảng đại diện cho một mặt hàng là một phần của quảng cáo có thể là Khuyến mãi_Items, nhưng nó cũng có thể là Khuyến mãi_Điều này tôi nghĩ (phản ánh mối quan hệ một-nhiều).
• Sử dụng dấu gạch dưới một cách nhất quán và cho một mục đích cụ thể. Chỉ cần các tên bảng chung là đủ rõ ràng với PascalCasing; bạn không cần gạch dưới để phân tách các từ. Lưu dấu gạch dưới (a) để chỉ ra bảng kết hợp hoặc (b) cho tiền tố, mà tôi sẽ giải quyết trong dấu đầu dòng tiếp theo.
• Tiền tố không tốt hay xấu. Nó thường không phải là tốt nhất. Trong db hoặc hai đầu tiên của bạn, tôi sẽ không đề xuất sử dụng tiền tố cho nhóm các bảng theo chủ đề chung. Các bảng kết thúc không phù hợp với danh mục của bạn một cách dễ dàng và nó thực sự có thể làm cho việc tìm bảng khó khăn hơn . Với kinh nghiệm, bạn có thể lập kế hoạch và áp dụng sơ đồ tiền tố có lợi hơn là có hại. Tôi đã làm việc trong một db khi bảng dữ liệu bắt đầu bằng tbl , bảng cấu hình với ctbl , chế độ xem với vew , sp của Proc và udf's fnvà một vài người khác; nó được tỉ mỉ, áp dụng nhất quán để nó hoạt động ổn. Lần duy nhất bạn CẦN tiền tố là khi bạn có các giải pháp thực sự riêng biệt mà vì một lý do nào đó nằm trong cùng một db; tiền tố chúng có thể rất hữu ích trong việc nhóm các bảng. Tiền tố cũng ổn đối với các tình huống đặc biệt, như đối với các bảng tạm thời mà bạn muốn nổi bật.
• Rất hiếm khi (nếu có) bạn muốn tiền tố cột.

Ok, vì chúng tôi đang cân nhắc với ý kiến:

Tôi tin rằng tên bảng nên số nhiều. Bảng là một bộ sưu tập (một bảng) của các thực thể. Mỗi hàng đại diện cho một thực thể duy nhất và bảng đại diện cho bộ sưu tập. Vì vậy, tôi sẽ gọi một bảng gồm các thực thể Person People (hoặc Người, bất cứ điều gì làm bạn thích).

Đối với những người thích xem "tên thực thể" số ít trong các truy vấn, đó là những gì tôi sẽ sử dụng bí danh bảng cho:

SELECT person.Name
FROM People person

Một chút giống như "từ người trong người chọn người" của LINQ.

Đối với 2, 3 và 4, tôi đồng ý với @Lars.

Tôi làm việc trong một nhóm hỗ trợ cơ sở dữ liệu với ba DBA và các tùy chọn được xem xét của chúng tôi là:

1. Bất kỳ tiêu chuẩn đặt tên là tốt hơn so với không có tiêu chuẩn.
2. Không có tiêu chuẩn "một đúng", tất cả chúng ta đều có sở thích của mình
3. Nếu đã có tiêu chuẩn, sử dụng nó. Đừng tạo ra một tiêu chuẩn khác hoặc làm vẩn đục các tiêu chuẩn hiện có.

Chúng tôi sử dụng tên số ít cho các bảng. Các bảng có xu hướng được thêm tiền tố với tên của hệ thống (hoặc từ viết tắt của nó). Điều này hữu ích nếu hệ thống phức tạp vì bạn có thể thay đổi tiền tố để nhóm các bảng lại với nhau một cách hợp lý (ví dụ: reg_customer, reg_booking và regadmin_limits).

Đối với các trường, chúng tôi mong muốn các tên trường sẽ bao gồm tiền tố / acryonm của bảng (ví dụ: obl_address1) và chúng tôi cũng thích sử dụng một bộ hậu tố tiêu chuẩn (_id cho PK, _cd cho "code", _nm cho "name ", _Nb cho" số ", _dt cho" Ngày ").

Tên của trường khóa Foriegn phải giống với trường Khóa chính.

I E

SELECT cust_nm, cust_add1, booking_dt
FROM reg_customer
INNER JOIN reg_booking
ON reg_customer.cust_id = reg_booking.cust_id

Khi phát triển một dự án mới, tôi khuyên bạn nên viết ra tất cả các tên thực thể, tiền tố và từ viết tắt ưa thích và cung cấp tài liệu này cho các nhà phát triển của bạn. Sau đó, khi họ quyết định tạo một bảng mới, họ có thể tham khảo tài liệu thay vì "đoán" những gì bảng và các trường nên được gọi.

1. Không. Một bảng nên được đặt tên theo thực thể mà nó đại diện. Người, không phải người là cách bạn sẽ đề cập đến bất cứ ai trong số các hồ sơ đại diện.
2. Một lần nữa, điều tương tự. Cột FirstName thực sự không nên được gọi là FirstNames. Tất cả phụ thuộc vào những gì bạn muốn đại diện với cột.
3. KHÔNG.
4. Đúng. Trường hợp nó cho rõ ràng. Nếu bạn cần phải có các cột như "FirstName", vỏ sẽ giúp bạn dễ đọc hơn.

Đồng ý. Đó là 0,02 đô la của tôi

Tôi cũng ủng hộ quy ước đặt tên theo phong cách ISO / IEC 11179, lưu ý rằng chúng là hướng dẫn chứ không phải là quy định.

Xem tên thành phần dữ liệu trên Wikipedia :

"Các bảng là Bộ sưu tập của các Thực thể và tuân theo các nguyên tắc đặt tên Bộ sưu tập. Lý tưởng nhất là sử dụng tên tập thể: ví dụ: Nhân sự. Số nhiều cũng đúng: Nhân viên. Tên không chính xác bao gồm: Nhân viên, tblEmployee và EmployeeTable."

Như mọi khi, có các ngoại lệ cho các quy tắc, ví dụ: một bảng luôn có chính xác một hàng có thể tốt hơn với một tên số ít, ví dụ như bảng cấu hình. Và tính nhất quán là vô cùng quan trọng: kiểm tra xem cửa hàng của bạn có một quy ước hay không và nếu có, hãy tuân theo nó; nếu bạn không thích nó thì hãy làm một trường hợp kinh doanh để thay đổi nó chứ không phải là người kiểm lâm đơn độc.

Tôi nghe lập luận tất cả thời gian rằng một bảng có số nhiều hay không đều là vấn đề sở thích cá nhân và không có cách thực hành tốt nhất. Tôi không tin đó là sự thật, đặc biệt là một lập trình viên trái ngược với DBA. Theo như tôi biết, không có lý do chính đáng nào để số nhiều tên bảng khác ngoài "Nó chỉ có ý nghĩa với tôi vì đó là một tập hợp các đối tượng", trong khi có những lợi ích hợp pháp trong mã bằng cách có tên bảng số ít. Ví dụ:

1. Nó tránh các lỗi và sai lầm gây ra bởi sự mơ hồ số nhiều. Các lập trình viên không biết chính xác về chuyên môn chính tả của họ, và số nhiều từ gây nhầm lẫn. Ví dụ: từ số nhiều kết thúc bằng 'es' hay chỉ 's'? Là người hay người? Khi bạn làm việc trong một dự án với các nhóm lớn, điều này có thể trở thành một vấn đề. Ví dụ, một trường hợp trong đó một thành viên trong nhóm sử dụng phương thức không chính xác để số nhiều bảng mà anh ta tạo. Vào thời điểm tôi tương tác với bảng này, nó được sử dụng toàn bộ trong mã mà tôi không có quyền truy cập hoặc sẽ mất quá nhiều thời gian để sửa. Kết quả là tôi phải nhớ đánh vần sai bảng mỗi lần tôi sử dụng nó. Một cái gì đó rất giống với điều này đã xảy ra với tôi. Bạn càng dễ dàng tạo điều kiện cho mọi thành viên trong nhóm sử dụng chính xác và dễ dàng, Tên bảng chính xác mà không có lỗi hoặc phải tìm kiếm tên bảng mọi lúc, tốt hơn. Phiên bản số ít dễ xử lý hơn trong môi trường nhóm.

2. Nếu bạn sử dụng phiên bản số ít của tên bảng VÀ tiền tố khóa chính với tên bảng, giờ đây bạn có lợi thế là dễ dàng xác định tên bảng từ khóa chính hoặc ngược lại chỉ qua mã. Bạn có thể được cung cấp một biến có tên bảng trong đó, nối "Id" ở cuối và bây giờ bạn có khóa chính của bảng thông qua mã mà không phải thực hiện truy vấn bổ sung. Hoặc bạn có thể cắt "Id" từ cuối khóa chính để xác định tên bảng thông qua mã. Nếu bạn sử dụng "id" mà không có tên bảng cho khóa chính, thì bạn không thể thông qua mã xác định tên bảng từ khóa chính. Ngoài ra, hầu hết những người số nhiều tên bảng và tiền tố cột PK với tên bảng sử dụng phiên bản số ít của tên bảng trong PK (ví dụ: status và status_id),

3. Nếu bạn đặt tên bảng là số ít, bạn có thể đặt chúng khớp với tên lớp mà chúng đại diện. Một lần nữa, điều này có thể đơn giản hóa mã và cho phép bạn thực hiện những việc thực sự gọn gàng, như khởi tạo một lớp bằng cách không có gì ngoài tên bảng. Nó cũng chỉ làm cho mã của bạn nhất quán hơn, dẫn đến ...

4. Nếu bạn đặt tên bảng là số ít, nó làm cho sơ đồ đặt tên của bạn nhất quán, có tổ chức và dễ duy trì ở mọi vị trí. Bạn biết rằng trong mọi trường hợp trong mã của bạn, cho dù đó là tên cột, như tên lớp hay tên bảng, thì đó là cùng một tên chính xác. Điều này cho phép bạn thực hiện các tìm kiếm toàn cầu để xem mọi nơi dữ liệu được sử dụng. Khi bạn số nhiều tên bảng, sẽ có trường hợp bạn sẽ sử dụng phiên bản số ít của tên bảng đó (lớp mà nó biến thành, trong khóa chính). Nó chỉ có ý nghĩa để không có một số trường hợp trong đó dữ liệu của bạn được gọi là số nhiều và một số trường hợp số ít.

Tóm lại, nếu bạn đa dạng hóa tên bảng của mình, bạn sẽ mất tất cả các loại lợi thế trong việc làm cho mã của bạn thông minh hơn và dễ xử lý hơn. Thậm chí có thể có trường hợp bạn phải có bảng / mảng tra cứu để chuyển đổi tên bảng thành tên đối tượng hoặc tên mã cục bộ mà bạn có thể tránh. Tên bảng số ít, mặc dù có thể cảm thấy hơi kỳ lạ lúc đầu, cung cấp những lợi thế đáng kể so với tên số nhiều và tôi tin là thực tiễn tốt nhất.

sở thích của chúng tôi:

1. Tên bảng có nên là số nhiều?
   Không bao giờ. Các đối số cho nó là một bộ sưu tập có ý nghĩa, nhưng bạn không bao giờ biết bảng sẽ chứa gì (0,1 hoặc nhiều mục). Quy tắc số nhiều làm cho việc đặt tên phức tạp không cần thiết. 1 Nhà, 2 nhà, chuột vs chuột, người với người và chúng tôi thậm chí không nhìn vào bất kỳ ngôn ngữ nào khác.

   Update person set property = 'value'hành động trên mỗi người trong bảng.
   Select * from person where person.name = 'Greg'trả về một bộ sưu tập / hàng của hàng người.

2. Tên cột có nên là số ít?
   Thông thường, có, ngoại trừ nơi bạn đang phá vỡ các quy tắc bình thường hóa.

3. Tôi nên tiền tố bảng hoặc cột?
   Chủ yếu là một sở thích nền tảng. Chúng tôi thích các cột tiền tố với tên bảng. Chúng tôi không có các bảng tiền tố, nhưng chúng tôi thực hiện các chế độ xem tiền tố (v_) và archive_procedures (sp_ hoặc f_ (function)). Điều đó giúp những người muốn cố gắng cập nhật v_person.age thực sự là một trường được tính toán trong một chế độ xem (dù sao đó cũng không thể là CẬP NHẬT).

   Đó cũng là một cách tuyệt vời để tránh xung đột từ khóa (Delivery.from break, nhưng deliver_from thì không).

   Nó làm cho mã dài dòng hơn, nhưng thường hỗ trợ khả năng đọc.

   bob = new person()
bob.person_name = 'Bob'
bob.person_dob = '1958-12-21'
   ... Rất dễ đọc và rõ ràng. Điều này có thể ra khỏi tầm tay mặc dù:

   customer.customer_customer_type_id

   biểu thị mối quan hệ giữa khách hàng và bảng customer_type, cho biết khóa chính trên bảng customer_type (customer_type_id) và nếu bạn từng thấy 'customer_customer_type_id' trong khi gỡ lỗi truy vấn, bạn sẽ biết ngay nó đến từ đâu (bảng khách hàng).

   hoặc nơi bạn có mối quan hệ MM giữa customer_type và customer_carget (chỉ một số loại nhất định có sẵn cho các danh mục nhất định)

   customer_category_customer_type_id

   ... là một chút (!) ở phía dài.

4. Tôi có nên sử dụng bất kỳ trường hợp trong việc đặt tên các mặt hàng? Có - chữ thường :), với dấu gạch dưới. Đây là rất dễ đọc và đa nền tảng. Cùng với 3 ở trên nó cũng có ý nghĩa.

   Hầu hết trong số này là sở thích mặc dù. - Miễn là bạn nhất quán, nó sẽ được dự đoán cho bất cứ ai phải đọc nó.

Hãy xem ISO 11179-5: Nguyên tắc đặt tên và nhận dạng Bạn có thể lấy nó ở đây: http : // metadata-stiterias.org/11179/#11179-5

Tôi đã viết về nó một thời gian trước đây: Các quy ước đặt tên ISO-11179

Tôi biết điều này đã muộn với trò chơi và câu hỏi đã được trả lời rất tốt, nhưng tôi muốn đưa ra ý kiến ​​của mình về # 3 liên quan đến tiền tố của tên cột.

Tất cả các cột phải được đặt tên bằng một tiền tố duy nhất cho bảng mà chúng được xác định.

Ví dụ: Cho trước các bảng "khách hàng" và "địa chỉ", chúng ta hãy đi với các tiền tố tương ứng là "trông coi" và "addr". "khách hàng" sẽ có "obl_id", "obl_name", v.v. "địa chỉ" sẽ có "addr_id", "addr_cust_id" (FK trở lại khách hàng), "addr_street", v.v.

Khi tôi lần đầu tiên được trình bày với tiêu chuẩn này, tôi đã quyết định chống lại nó; Tôi ghét ý tưởng. Tôi không thể chịu được ý tưởng về việc gõ thêm và dự phòng. Bây giờ tôi đã có đủ kinh nghiệm với nó mà tôi sẽ không bao giờ quay trở lại.

Kết quả của việc này là tất cả các cột trong lược đồ cơ sở dữ liệu của bạn là duy nhất. Có một lợi ích lớn cho việc này, đó là bỏ qua tất cả các lập luận chống lại nó (tất nhiên theo ý kiến ​​của tôi):

Bạn có thể tìm kiếm toàn bộ cơ sở mã của mình và tìm thấy mọi dòng mã chạm vào một cột cụ thể.

Lợi ích từ # 1 là vô cùng lớn. Tôi có thể phản đối một cột và biết chính xác những tập tin nào cần được cập nhật trước khi cột có thể được gỡ bỏ khỏi lược đồ một cách an toàn. Tôi có thể thay đổi ý nghĩa của một cột và biết chính xác mã nào cần được cấu trúc lại. Hoặc đơn giản là tôi có thể biết liệu dữ liệu từ một cột thậm chí có được sử dụng trong một phần cụ thể của hệ thống hay không. Tôi không thể đếm số lần điều này đã biến một dự án khổng lồ tiềm năng thành một dự án đơn giản, cũng không phải là số giờ chúng tôi đã tiết kiệm được trong công việc phát triển.

Một lợi ích tương đối nhỏ khác là bạn chỉ phải sử dụng bí danh bảng khi bạn tự tham gia:

SELECT cust_id, cust_name, addr_street, addr_city, addr_state
    FROM customer
        INNER JOIN address ON addr_cust_id = cust_id
    WHERE cust_name LIKE 'J%';

Ý kiến ​​của tôi về những điều này là:

1) Không, tên bảng nên là số ít.

Mặc dù nó có vẻ có ý nghĩa đối với lựa chọn đơn giản ( select * from Orders) nhưng nó có ý nghĩa ít hơn đối với tương đương OO ( Orders x = new Orders).

Một bảng trong DB thực sự là tập hợp của thực thể đó, nó có ý nghĩa hơn một khi bạn đang sử dụng logic tập hợp:

select Orders.*
from Orders inner join Products
    on Orders.Key = Products.Key

Dòng cuối cùng, logic thực tế của phép nối, trông khó hiểu với tên bảng số nhiều.

Tôi không chắc chắn về việc luôn luôn sử dụng bí danh (như Matt gợi ý) sẽ xóa điều đó.

2) Họ nên là số ít vì họ chỉ nắm giữ 1 tài sản

3) Không bao giờ, nếu tên cột không rõ ràng (như trên, trong đó cả hai đều có một cột được gọi là [Khóa]), tên của bảng (hoặc bí danh của nó) có thể phân biệt chúng đủ tốt. Bạn muốn các truy vấn được nhập nhanh và đơn giản - tiền tố thêm độ phức tạp không cần thiết.

4) Dù bạn muốn, tôi muốn đề xuất CapitalCase

Tôi không nghĩ có một bộ hướng dẫn tuyệt đối về bất kỳ trong số này.

Miễn là bất cứ điều gì bạn chọn là nhất quán trên ứng dụng hoặc DB, tôi không nghĩ nó thực sự quan trọng.

Theo ý kiến ​​của tôi:

1. Tên bảng nên là số nhiều.
2. Tên cột phải là số ít.
3. Không.
4. CamelCase (ưu tiên của tôi) hoặc gạch dưới_separated cho cả tên bảng và tên cột.

Tuy nhiên, giống như nó đã được đề cập, bất kỳ quy ước nào là tốt hơn so với không có quy ước. Cho dù bạn chọn cách nào để thực hiện nó, hãy ghi lại nó để các sửa đổi trong tương lai tuân theo các quy ước tương tự.

Tôi nghĩ rằng câu trả lời tốt nhất cho mỗi câu hỏi sẽ được đưa ra bởi bạn và nhóm của bạn. Điều quan trọng hơn nhiều là có một quy ước đặt tên sau đó chính xác là quy ước đặt tên như thế nào.

Vì không có câu trả lời đúng cho điều đó, bạn nên dành chút thời gian (nhưng không quá nhiều) và chọn các quy ước của riêng bạn và - đây là phần quan trọng - tuân theo nó.

Tất nhiên, thật tốt khi tìm kiếm một số thông tin về các tiêu chuẩn về điều đó, đó là những gì bạn đang hỏi, nhưng đừng lo lắng hay lo lắng về số lượng câu trả lời khác nhau mà bạn có thể nhận được: chọn câu trả lời có vẻ tốt hơn cho bạn.

Chỉ trong trường hợp, đây là câu trả lời của tôi:

1. Đúng. Một bảng là một nhóm các hồ sơ , giáo viên hoặc diễn viên , vì vậy ... số nhiều.
2. Đúng.
3. Tôi không sử dụng chúng.
4. Cơ sở dữ liệu tôi sử dụng thường xuyên hơn - Firebird - giữ mọi thứ ở dạng chữ hoa, vì vậy nó không thành vấn đề. Dù sao, khi tôi lập trình, tôi viết tên theo cách dễ đọc hơn, như phát hànhYear .

1. Chắc chắn giữ tên bảng số ít, người không phải người
   2. Tương tự ở đây
   3. Không. Tôi đã thấy một số tiền tố khủng khiếp, đi xa đến mức nói rõ những gì đang xử lý là một bảng (tbl_) hoặc thủ tục lưu trữ người dùng (usp_). Tiếp theo là tên cơ sở dữ liệu ... Đừng làm điều đó!
   4. Đúng. Tôi có xu hướng PascalCase tất cả các tên bảng của tôi

Các quy ước đặt tên cho phép nhóm phát triển thiết kế khả năng khám phá và khả năng bảo trì tại trung tâm của dự án.

Một quy ước đặt tên tốt cần có thời gian để phát triển nhưng một khi nó được thực hiện, nó cho phép nhóm tiến lên với một ngôn ngữ chung. Một quy ước đặt tên tốt phát triển hữu cơ với dự án. Một quy ước đặt tên tốt dễ dàng đối phó với các thay đổi trong giai đoạn dài nhất và quan trọng nhất của vòng đời phần mềm - quản lý dịch vụ trong sản xuất.

Đây là câu trả lời của tôi:

1. Có, tên bảng nên ở dạng số nhiều khi chúng đề cập đến một tập hợp các giao dịch , chứng khoán hoặc đối tác chẳng hạn.
2. Đúng.
3. Đúng. Các bảng SQL có tiền tố là tb_, các khung nhìn có tiền tố vw_, các thủ tục được lưu trữ có tiền tố usp_ và các kích hoạt được tiền tố tg_ theo sau là tên cơ sở dữ liệu.
4. Tên cột nên được viết thường bằng dấu gạch dưới.

Đặt tên rất khó nhưng trong mọi tổ chức đều có người có thể đặt tên cho mọi thứ và trong mọi nhóm phần mềm nên có người chịu trách nhiệm về tiêu chuẩn đặt tên và đảm bảo rằng việc đặt tên các vấn đề như sec_id , sec_value và security_id sẽ được giải quyết sớm trước khi họ bị cuốn vào dự án .

Vậy các nguyên lý cơ bản của một quy ước và tiêu chuẩn đặt tên tốt là gì: -

• Sử dụng ngôn ngữ của khách hàng và miền giải pháp của bạn
• Hãy mô tả
• Hãy kiên định
• Định hướng, phản ánh và tái cấu trúc
• Đừng sử dụng chữ viết tắt trừ khi chúng rõ ràng với mọi người
• Không sử dụng các từ khóa dành riêng SQL làm tên cột

Đây là một liên kết cung cấp một vài sự lựa chọn. Tôi đã tìm kiếm một thông số đơn giản mà tôi có thể làm theo thay vì phải dựa vào một thông số được xác định một phần.

http://justinsomnia.org/writings/naming_conventions.html

SELECT 
   UserID, FirstName, MiddleInitial, LastName
FROM Users
ORDER BY LastName

Tên bảng phải luôn là số ít, vì chúng đại diện cho một tập hợp các đối tượng. Như bạn nói bầy đàn chỉ định một nhóm cừu, hoặc đàn làm chỉ định một nhóm chim. Không cần số nhiều. Khi một tên bảng là thành phần của hai tên và quy ước đặt tên ở số nhiều, sẽ khó biết được tên số nhiều nên là từ đầu tiên hay từ thứ hai hoặc cả hai. Đó là logic - Object.instance, không phải object.instance. Hoặc TableName.column, không phải TableNames.column. Microsoft SQL không phân biệt chữ hoa chữ thường, việc đọc tên bảng dễ dàng hơn, nếu sử dụng chữ in hoa, để phân tách tên bảng hoặc cột khi chúng bao gồm hai hoặc nhiều tên.

Tên bảng: Nó phải là số ít, vì nó là một thực thể số ít đại diện cho một đối tượng trong thế giới thực chứ không phải các đối tượng, là số ít.

Tên cột dọc: Chỉ nên là số ít sau đó nó truyền tải rằng nó sẽ giữ một giá trị nguyên tử và sẽ xác nhận với lý thuyết chuẩn hóa. Tuy nhiên, nếu có n số thuộc tính cùng loại, thì chúng phải được thêm vào 1, 2, ..., n, v.v.

Tiền tố Bảng / Cột: Đây là một chủ đề rất lớn, sẽ thảo luận sau.

Vỏ bọc: Nó phải là vỏ lạc đà

Bạn của tôi, Patrick Karcher , tôi yêu cầu bạn vui lòng không viết bất cứ điều gì có thể gây khó chịu cho ai đó, như bạn đã viết, "• Hơn nữa, các khóa ngoại phải được đặt tên liên tục trong các bảng khác nhau. Nên đánh bại một người không hợp pháp làm cái này.". Tôi chưa bao giờ mắc lỗi này, bạn Patrick của tôi, nhưng tôi thường viết. Điều gì sẽ xảy ra nếu họ cùng nhau lên kế hoạch đánh bại bạn vì điều này? :)

Đến bữa tiệc rất muộn nhưng tôi vẫn muốn thêm hai xu của mình về tiền tố cột

Dường như có hai đối số chính để sử dụng tiêu chuẩn đặt tên tên bảng_column (hoặc tên bảng) cho các cột, cả hai đều dựa trên thực tế là tên cột sẽ là duy nhất trên toàn bộ cơ sở dữ liệu của bạn:

1) Bạn không phải chỉ định tên bảng và / hoặc bí danh cột trong các truy vấn của mình mọi lúc

2) Bạn có thể dễ dàng tìm kiếm toàn bộ mã của mình cho tên cột

Tôi nghĩ rằng cả hai đối số là thiếu sót. Giải pháp cho cả hai vấn đề mà không sử dụng tiền tố là dễ dàng. Đây là đề xuất của tôi:

Luôn sử dụng tên bảng trong SQL của bạn. Ví dụ: luôn luôn sử dụng bảng.column thay vì cột.

Nó rõ ràng giải quyết được 2) vì bây giờ bạn có thể chỉ cần tìm kiếm bảng.column thay vì table_column.

Nhưng tôi có thể nghe bạn hét lên, làm thế nào để giải quyết 1)? Đó là chính xác về việc tránh điều này. Vâng, đó là, nhưng giải pháp là thiếu sót khủng khiếp. Tại sao? Chà, giải pháp tiền tố rút gọn thành:
Để tránh phải chỉ định bảng.column khi có sự mơ hồ, bạn đặt tên cho tất cả các cột của mình là table_column!
Nhưng điều này có nghĩa là từ bây giờ, LUÔN LUÔN phải viết tên cột mỗi khi bạn chỉ định một cột. Nhưng nếu bạn phải làm điều đó dù sao đi nữa, lợi ích của việc luôn luôn viết bảng.column là gì? Chính xác, không có lợi ích, đó chính xác là cùng số lượng ký tự để nhập.

chỉnh sửa: có, tôi biết rằng việc đặt tên cho các cột với tiền tố bắt buộc sử dụng đúng trong khi cách tiếp cận của tôi phụ thuộc vào các lập trình viên

Các quy ước đặt tên cơ sở dữ liệu cần thiết (và kiểu) (bấm vào đây để mô tả chi tiết hơn)

Tên bảng chọn tên ngắn gọn, không rõ ràng, sử dụng không quá một hoặc hai từ để phân biệt bảng dễ dàng tạo điều kiện cho việc đặt tên của tên trường duy nhất cũng như bảng tra cứu và liên kết cho bảng tên số ít, không bao giờ đồng ý với các lý do được đưa ra cho quy ước này, nhưng hầu hết mọi người thực sự thích tên bảng số nhiều, vì vậy tôi đã làm dịu lập trường của mình) ... vui lòng theo liên kết ở trên

Bảng tên số ít. Giả sử bạn đang lập mô hình thực tế giữa ai đó và địa chỉ của họ. Ví dụ: nếu bạn đang đọc một datamodel, bạn sẽ thích 'mỗi người có thể sống ở 0,1 hoặc nhiều địa chỉ.' hoặc 'mỗi người có thể sống ở 0,1 hoặc nhiều địa chỉ.' Tôi nghĩ rằng địa chỉ số nhiều dễ dàng hơn, thay vì phải viết lại mọi người như cá nhân. Cộng với danh từ tập thể khá thường không giống với phiên bản số ít.

--Example SQL

CREATE TABLE D001_Students
(
    StudentID INTEGER CONSTRAINT nnD001_STID NOT NULL,
    ChristianName NVARCHAR(255) CONSTRAINT nnD001_CHNA NOT NULL,
    Surname NVARCHAR(255) CONSTRAINT nnD001_SURN NOT NULL,
    CONSTRAINT pkD001 PRIMARY KEY(StudentID)
);

CREATE INDEX idxD001_STID on D001_Students;

CREATE TABLE D002_Classes
(
    ClassID INTEGER CONSTRAINT nnD002_CLID NOT NULL,
    StudentID INTEGER CONSTRAINT nnD002_STID NOT NULL,
    ClassName NVARCHAR(255) CONSTRAINT nnD002_CLNA NOT NULL,
    CONSTRAINT pkD001 PRIMARY KEY(ClassID, StudentID),
    CONSTRAINT fkD001_STID FOREIGN KEY(StudentID) 
        REFERENCES D001_Students(StudentID)
);

CREATE INDEX idxD002_CLID on D002_Classes;

CREATE VIEW V001_StudentClasses
(
    SELECT
        D001.ChristianName,
        D001.Surname,
        D002.ClassName
    FROM
        D001_Students D001
            INNER JOIN
        D002_Classes D002
            ON
        D001.StudentID = D002.StudentID
);

Đây là những quy ước tôi đã được dạy, nhưng bạn nên thích nghi với bất cứ điều gì bạn sử dụng vòi phát triển.

1. Số nhiều. Nó là một tập hợp các thực thể.
2. Đúng. Thuộc tính là một đại diện của thuộc tính số ít của một thực thể.
3. Có, tên bảng tiền tố cho phép dễ dàng theo dõi việc đặt tên cho tất cả các chỉ mục ràng buộc và bí danh bảng.
4. Trường hợp Pascal cho tên bảng và cột, tiền tố + TẤT CẢ mũ cho chỉ mục và ràng buộc.