Đặt tên bảng: Dấu gạch dưới so với Dấu gạch ngang? không gian tên? Số ít và Số nhiều?

Tôi đã đọc một số câu hỏi / câu trả lời trên StackOverflow để cố gắng tìm cách 'tốt nhất', hoặc tôi nên nói là phải được chấp nhận, để đặt tên cho các bảng trên Cơ sở dữ liệu.

Hầu hết các nhà phát triển có xu hướng đặt tên cho các bảng tùy thuộc vào ngôn ngữ yêu cầu cơ sở dữ liệu (JAVA, .NET, PHP, v.v.). Tuy nhiên tôi chỉ cảm thấy điều này không đúng.

Cách tôi đặt tên bảng cho đến bây giờ là làm một cái gì đó như:

doctorsMain
doctorsProfiles
doctorsPatients
patientsMain
patientsProfiles
patientsAntecedents 

Những điều tôi quan tâm là:

• Tính dễ đọc
• Xác định nhanh mô-đun mà bảng lấy từ (bác sĩ || bệnh nhân)
• Dễ hiểu, để tránh nhầm lẫn.

Tôi muốn đọc bất kỳ ý kiến ​​nào liên quan đến quy ước đặt tên. Cảm ơn bạn.

Nhất quán quan trọng hơn nhiều so với việc bạn sử dụng chương trình cụ thể nào.

Tôi thường sử dụng PascalCase và các thực thể là số ít:

DoctorMain
DoctorProfile
DoctorPatient

Nó bắt chước các quy ước đặt tên cho các lớp trong ứng dụng của tôi, giữ cho mọi thứ khá gọn gàng, sạch sẽ, nhất quán và dễ hiểu đối với mọi người.

Bản chất không phân biệt chữ hoa chữ thường của SQL hỗ trợ Underscores_Scheme. Tuy nhiên, phần mềm hiện đại hỗ trợ bất kỳ loại lược đồ đặt tên nào. Tuy nhiên, đôi khi một số lỗi khó chịu, sai sót hoặc yếu tố con người có thể dẫn đến UPPERCASINGEVERYTHINGviệc những người đã chọn cả hai Pascal_Casevà lập Underscore_Casekế hoạch sống với tất cả thần kinh của họ ở vị trí tốt.

Tổng hợp của hầu hết những điều trên:

• không dựa vào trường hợp trong cơ sở dữ liệu
• không xem xét trường hợp hoặc phần phân cách của tên - chỉ các từ
• sử dụng bất kỳ dấu phân tách hoặc viết hoa nào là tiêu chuẩn cho ngôn ngữ của bạn

Sau đó, bạn có thể dễ dàng dịch (thậm chí tự động) tên giữa các môi trường.

Nhưng tôi muốn thêm một cân nhắc khác: bạn có thể thấy rằng có những yếu tố khác khi bạn chuyển từ một lớp trong ứng dụng sang một bảng trong cơ sở dữ liệu của bạn: đối tượng cơ sở dữ liệu có các khung nhìn, trình kích hoạt, procs được lưu trữ, chỉ mục, ràng buộc, v.v. - đó cũng cần tên. Vì vậy, ví dụ: bạn có thể thấy mình chỉ truy cập các bảng thông qua các dạng xem thường chỉ là một "select * from foo" đơn giản. Chúng có thể được xác định là tên bảng chỉ với hậu tố '_v' hoặc bạn có thể đặt chúng trong một lược đồ khác. Mục đích của một lớp trừu tượng đơn giản như vậy là nó có thể được mở rộng khi cần thiết để cho phép các thay đổi trong một môi trường để tránh ảnh hưởng đến môi trường khác. Điều này sẽ không phá vỡ các đề xuất đặt tên ở trên - chỉ cần tính đến một số điều nữa.

Tôi sử dụng dấu gạch dưới. Tôi đã thực hiện một dự án Oracle cách đây vài năm, và có vẻ như Oracle đã buộc tất cả các tên đối tượng của tôi thành chữ hoa, điều này sẽ đánh bật bất kỳ sơ đồ viết hoa nào. Tôi không thực sự là một gã Oracle, vì vậy có lẽ có một cách nào đó để giải quyết vấn đề này mà tôi không biết, nhưng nó khiến tôi sử dụng dấu gạch dưới và tôi đã không bao giờ quay lại.

Vì câu hỏi không dành riêng cho một nền tảng hoặc công cụ DB cụ thể, tôi phải nói rằng để có tính di động tối đa, bạn nên luôn sử dụng tên bảng viết thường.

/ [a-z _] [a-z0-9 _] * / thực sự là mẫu tên duy nhất dịch liền mạch giữa các nền tảng khác nhau. Chữ thường chữ-số + dấu gạch dưới sẽ luôn hoạt động nhất quán.

Như đã đề cập ở phần khác, tên quan hệ (bảng) phải là số ít: http://www.teamten.com/lawrence/programming/use-singular-nouns-for-database-table-names.html

Tôi có xu hướng đồng ý với những người nói rằng nó phụ thuộc vào quy ước của ngôn ngữ bạn đang sử dụng (ví dụ: PascalCase cho C # và solid_case cho Ruby).

Không bao giờ camelCase, mặc dù.

Sau khi đọc nhiều ý kiến ​​khác, tôi nghĩ việc sử dụng quy ước đặt tên của ngôn ngữ là rất quan trọng, tính nhất quán quan trọng hơn quy ước đặt tên chỉ khi bạn (và sẽ là) nhà phát triển ứng dụng duy nhất. Nếu bạn muốn tính dễ đọc (có tầm quan trọng rất lớn), bạn nên sử dụng các quy ước đặt tên cho mỗi ngôn ngữ. Trong MySQL, tôi không khuyên bạn nên sử dụng CamelCase vì không phải tất cả các nền tảng đều phân biệt chữ hoa chữ thường. Vì vậy, ở đây gạch dưới tốt hơn.

Đây là năm xu của tôi. Tôi đi đến kết luận rằng nếu DB từ các nhà cung cấp khác nhau được sử dụng cho một dự án thì có hai cách tốt nhất:

1. Sử dụng dấu gạch dưới.
2. Sử dụng trường hợp lạc đà với dấu ngoặc kép.

Lý do là một số cơ sở dữ liệu sẽ chuyển đổi tất cả các ký tự thành chữ hoa và một số thành chữ thường. Vì vậy, nếu bạn có myTablenó sẽ trở thành MYTABLEhoặc mytablekhi nào bạn sẽ làm việc với DB.

Thật không may là không có câu trả lời "tốt nhất" cho câu hỏi này. Như @David đã nêu tính nhất quán quan trọng hơn nhiều so với quy ước đặt tên.

có sự khác biệt lớn về cách tách các từ, vì vậy bạn sẽ phải chọn bất cứ thứ gì bạn thích hơn; nhưng đồng thời, có vẻ như gần như có sự đồng thuận rằng tên bảng nên là số ít.

Các quy ước đặt tên tồn tại trong phạm vi của một ngôn ngữ và các ngôn ngữ khác nhau có các quy ước đặt tên khác nhau.

SQL không phân biệt chữ hoa chữ thường theo mặc định; vì vậy, solid_case là một quy ước được sử dụng rộng rãi. SQL cũng hỗ trợ các số nhận dạng được phân tách; vì vậy, trường hợp hỗn hợp trong một tùy chọn, như camelCase (Java, trong đó các trường == cột) hoặc PascalCase (C #, trong đó các bảng == lớp và cột == trường). Nếu công cụ DB của bạn không thể hỗ trợ tiêu chuẩn SQL, đó là vấn đề của nó. Bạn có thể quyết định sống chung với điều đó hoặc chọn một động cơ khác. (Và lý do tại sao C # phải khác biệt là một điểm nghiêm trọng đối với những người viết mã trong cả hai chúng ta.)

Nếu bạn định chỉ sử dụng một ngôn ngữ trong các dịch vụ và ứng dụng của mình, hãy sử dụng các quy ước của ngôn ngữ đó ở tất cả các lớp. Ngoài ra, hãy sử dụng các quy ước được sử dụng rộng rãi nhất của ngôn ngữ trong miền mà ngôn ngữ đó được sử dụng.