Bảng đặt tên tiến thoái lưỡng nan: Tên số ít so với số nhiều [đóng]

Academia cho rằng tên bảng phải là số ít của thực thể mà chúng lưu trữ các thuộc tính.

Tôi không thích bất kỳ T-SQL nào yêu cầu dấu ngoặc vuông xung quanh tên, nhưng tôi đã đổi tên một Usersbảng thành số ít, mãi mãi kết án những người sử dụng bảng để đôi khi phải sử dụng dấu ngoặc.

Cảm giác ruột của tôi là đúng hơn khi ở cùng với số ít, nhưng cảm giác ruột của tôi cũng là dấu ngoặc chỉ ra những điều không mong muốn như tên cột có khoảng trắng trong đó, v.v.

Tôi nên ở lại, hay tôi nên đi?

Những người khác đã đưa ra câu trả lời khá tốt theo "tiêu chuẩn", nhưng tôi chỉ muốn thêm điều này ... Có thể "Người dùng" (hoặc "Người dùng") không thực sự là một mô tả đầy đủ về dữ liệu được giữ trong bảng ? Không phải là bạn nên quá cuồng nhiệt với tên bảng và tính đặc hiệu, nhưng có lẽ thứ gì đó như "Widget_Users" (trong đó "Widget" là tên của ứng dụng hoặc trang web của bạn) sẽ phù hợp hơn.

Tôi đã có cùng một câu hỏi, và sau khi đọc tất cả các câu trả lời ở đây, tôi chắc chắn ở lại với SINGULAR, lý do:

Lý do 1 (Khái niệm). Bạn có thể nghĩ về túi chứa táo như "AppleBag", không có vấn đề gì nếu chứa 0, 1 hoặc một triệu quả táo, nó luôn luôn là cùng một túi. Các bảng chỉ là, các thùng chứa, tên bảng phải mô tả những gì nó chứa, không phải nó chứa bao nhiêu dữ liệu. Ngoài ra, khái niệm số nhiều là về một ngôn ngữ nói (thực ra để xác định xem có một hay nhiều).

Lý do 2 . (Tiện). nó dễ dàng đi ra với tên số ít, hơn với số nhiều. Các đối tượng có thể có số nhiều không đều hoặc không có số nhiều, nhưng sẽ luôn có một số ít (với một vài ngoại lệ như Tin tức).

• khách hàng
• Đặt hàng
• Người dùng
• Trạng thái
• Tin tức

Lý do 3 . (Thẩm mỹ và trật tự). Đặc biệt trong các kịch bản chi tiết tổng thể, điều này đọc tốt hơn, sắp xếp tốt hơn theo tên và có thứ tự logic hơn (Master trước, Chi tiết thứ hai):

• 1. Đơn hàng
• 2.Thay đổi chi tiết

So với:

• 1.Thay đổi chi tiết
• 2 đơn đặt hàng

Lý do 4 (Đơn giản). Đặt tất cả lại với nhau, Tên bảng, Khóa chính, Mối quan hệ, Lớp thực thể ... tốt hơn là chỉ nhận biết một tên (số ít) thay vì hai (lớp số ít, bảng số nhiều, trường số ít, chi tiết số nhiều số nhiều .. .)

• Customer
• Customer.CustomerID
• CustomerAddress
• public Class Customer {...}
• SELECT FROM Customer WHERE CustomerID = 100

Khi bạn biết bạn đang giao dịch với "Khách hàng", bạn có thể chắc chắn rằng bạn sẽ sử dụng cùng một từ cho tất cả các nhu cầu tương tác cơ sở dữ liệu của bạn.

Lý do 5 . (Toàn cầu hóa). Thế giới ngày càng nhỏ hơn, bạn có thể có một nhóm các quốc tịch khác nhau, không phải ai cũng có tiếng Anh như ngôn ngữ bản địa. Sẽ dễ dàng hơn cho một lập trình viên tiếng Anh không phải là người bản xứ nghĩ về "Kho lưu trữ" hơn là "Kho lưu trữ" hoặc "Trạng thái" thay vì "Trạng thái". Có tên số ít có thể dẫn đến ít lỗi hơn do lỗi chính tả, tiết kiệm thời gian bằng cách không phải nghĩ "đó là Trẻ em hay Trẻ em?", Do đó cải thiện năng suất.

Lý do 6 . (Tại sao không?). Nó thậm chí có thể giúp bạn tiết kiệm thời gian viết, tiết kiệm dung lượng ổ đĩa và thậm chí làm cho bàn phím máy tính của bạn bền hơn!

• SELECT Customer.CustomerName FROM Customer WHERE Customer.CustomerID = 100
• SELECT Customers.CustomerName FROM Customers WHERE Customers.CustomerID = 100

Bạn đã lưu 3 chữ cái, 3 byte, thêm 3 lần nhấn bàn phím :)

Và cuối cùng, bạn có thể đặt tên cho những cái đó gây rối với các tên dành riêng như:

• Người dùng> Đăng nhập Người dùng, Người dùng ứng dụng, Người dùng hệ thống, Người dùng CMS, ...

Hoặc sử dụng dấu ngoặc vuông khét tiếng [Người dùng]

Nếu bạn sử dụng các công cụ Lập bản đồ quan hệ đối tượng hoặc trong tương lai tôi sẽ đề xuất Singular .

Một số công cụ như LLBLGen có thể tự động sửa tên số nhiều như Người dùng thành Người dùng mà không cần thay đổi tên bảng. Vì sao vấn đề này? Bởi vì khi được ánh xạ, bạn muốn nó trông giống như User.Name thay vì Users.Name hoặc tệ hơn từ một số bảng cơ sở dữ liệu cũ của tôi đặt tên tblUsers.strName chỉ gây nhầm lẫn trong mã.

Nguyên tắc mới của tôi là đánh giá nó sẽ trông như thế nào khi nó được chuyển đổi thành vật thể.

một bảng tôi thấy không phù hợp với cách đặt tên mới mà tôi sử dụng là UsersInRoles. Nhưng sẽ luôn có một vài ngoại lệ và thậm chí trong trường hợp này nó trông vẫn ổn như UsersInRoles.Username.

Tôi thích sử dụng danh từ không được chú ý , trong tiếng Anh tình cờ là số ít.

Việc ảnh hưởng đến số lượng tên bảng gây ra các vấn đề về hình học (như nhiều câu trả lời khác hiển thị), nhưng việc chọn làm như vậy bởi vì các bảng thường chứa nhiều hàng cũng đầy lỗ hổng về mặt ngữ nghĩa. Điều này rõ ràng hơn nếu chúng ta xem xét một ngôn ngữ thổi phồng danh từ dựa trên trường hợp (như hầu hết làm):

Vì chúng ta thường làm gì đó với các hàng, tại sao không đặt tên trong trường hợp buộc tội? Nếu chúng ta có một bảng mà chúng ta viết nhiều hơn chúng ta đọc, tại sao không đặt tên trong dative? Đó là một bảng của một cái gì đó, tại sao không sử dụng genitive? Chúng tôi sẽ không làm điều này, bởi vì bảng được định nghĩa là một thùng chứa trừu tượng tồn tại bất kể trạng thái hoặc cách sử dụng của nó. Làm ảnh hưởng đến danh từ mà không có lý do ngữ nghĩa chính xác và tuyệt đối là bập bẹ.

Sử dụng danh từ không được chú ý là đơn giản, logic, thường xuyên và độc lập với ngôn ngữ.

Quy ước nào yêu cầu các bảng có tên số ít? Tôi luôn nghĩ đó là tên số nhiều.

Một người dùng được thêm vào bảng Người dùng.

Trang web này đồng ý:
http://vyaskn.tripod.com/object_naming.htmlm#Tables

Trang web này không đồng ý (nhưng tôi không đồng ý với nó):
http://justinsomnia.org/writings/naming_conventions.html

Như những người khác đã đề cập: đây chỉ là hướng dẫn. Chọn một quy ước phù hợp với bạn và công ty / dự án của bạn và gắn bó với nó. Chuyển đổi giữa các từ số ít và số nhiều hoặc đôi khi viết tắt và đôi khi không trầm trọng hơn nhiều.

Làm thế nào về điều này như là một ví dụ đơn giản:

SELECT Customer.Name, Customer.Address FROM Customer WHERE Customer.Name > "def"

so với

SELECT Customers.Name, Customers.Address FROM Customers WHERE Customers.Name > "def"

SQL ở sau là âm thanh lạ hơn so với trước đây.

Tôi bỏ phiếu cho số ít .

Tôi tin chắc rằng trong Sơ đồ quan hệ thực thể, thực thể cần được phản ánh bằng một tên số ít, tương tự như tên lớp là số ít. Sau khi khởi tạo, tên phản ánh thể hiện của nó. Vì vậy, với cơ sở dữ liệu, thực thể khi được tạo thành một bảng (một tập hợp các thực thể hoặc bản ghi) là số nhiều. Thực thể, Người dùng được tạo thành bảng Người dùng. Tôi sẽ đồng ý với những người khác đề xuất rằng tên Người dùng có thể được cải thiện thành Nhân viên hoặc một cái gì đó phù hợp hơn với kịch bản của bạn.

Điều này sau đó có ý nghĩa hơn trong một câu lệnh SQL bởi vì bạn đang chọn từ một nhóm các bản ghi và nếu tên bảng là số ít, thì nó không đọc tốt.

Tôi gắn bó với số ít cho tên bảng và bất kỳ thực thể lập trình.

Nguyên nhân? Thực tế là có nhiều số nhiều bất thường trong tiếng Anh như chuột chuột và cừu cừu . Sau đó, nếu tôi cần một bộ sưu tập , tôi chỉ cần sử dụng chuột hoặc cừu , và tiếp tục.

Nó thực sự giúp đa số nổi bật, và tôi có thể dễ dàng và lập trình xác định bộ sưu tập của mọi thứ sẽ như thế nào.

Vì vậy, quy tắc của tôi là: mọi thứ đều là số ít, mọi bộ sưu tập của mọi thứ đều là số ít với một s được nối thêm. Giúp với ORM quá.

IMHO, tên bảng nên số nhiều như Khách hàng .

Tên lớp nên là số ít như Khách hàng nếu nó ánh xạ tới một hàng trong bảng Khách hàng .

Số ít. Tôi không mua bất kỳ đối số nào liên quan đến logic nhất - mọi người đều cho rằng sở thích của mình là hợp lý nhất. Bất kể bạn làm gì cũng là một mớ hỗn độn, chỉ cần chọn một quy ước và tuân theo nó. Chúng tôi đang cố gắng ánh xạ một ngôn ngữ có ngữ pháp và ngữ nghĩa rất bất thường (ngôn ngữ nói và viết thông thường) thành một ngữ pháp rất thông thường (SQL) với ngữ nghĩa rất cụ thể.

Đối số chính của tôi là tôi không nghĩ về các bảng như một tập hợp mà là các mối quan hệ.

Vì vậy, AppUsermối quan hệ cho biết thực thể nào AppUsers.

Các AppUserGroupmối quan hệ nói với tôi mà đơn vị làAppUserGroups

Các AppUser_AppUserGroupmối quan hệ cho tôi biết làm thế nào AppUsersvà AppUserGroupscó liên quan.

Các AppUserGroup_AppUserGroupmối quan hệ nói với tôi như thế nào AppUserGroupsvà AppUserGroupscó liên quan (nhóm tức là thành viên của nhóm).

Nói cách khác, khi tôi nghĩ về các thực thể và chúng có liên quan như thế nào, tôi nghĩ về các mối quan hệ ở số ít, nhưng tất nhiên, khi tôi nghĩ về các thực thể trong các bộ sưu tập hoặc bộ, các bộ sưu tập hoặc bộ là số nhiều.

Trong mã của tôi, sau đó và trong lược đồ cơ sở dữ liệu, tôi sử dụng số ít. Trong các mô tả văn bản, tôi kết thúc bằng cách sử dụng số nhiều để tăng khả năng đọc - sau đó sử dụng phông chữ, vv để phân biệt tên bảng / quan hệ với số nhiều s.

Tôi thích nghĩ về nó là lộn xộn, nhưng có hệ thống - và theo cách này luôn có một cái tên được tạo ra một cách có hệ thống cho mối quan hệ tôi muốn bày tỏ, mà đối với tôi là rất quan trọng.

Tôi cũng sẽ đi với số nhiều , và với tình huống khó xử Người dùng đã nói ở trên , chúng tôi thực hiện phương pháp ngoặc vuông.

Chúng tôi làm điều này để cung cấp tính đồng nhất giữa cả kiến ​​trúc cơ sở dữ liệu và kiến ​​trúc ứng dụng, với sự hiểu biết cơ bản rằng bảng Người dùng là một tập hợp các giá trị Người dùng cũng như bộ sưu tập Người dùng trong một tạo phẩm mã là một tập hợp các đối tượng Người dùng .

Có nhóm dữ liệu của chúng tôi và các nhà phát triển của chúng tôi nói cùng một ngôn ngữ khái niệm (mặc dù không phải lúc nào cũng có cùng tên đối tượng) giúp truyền đạt ý tưởng giữa chúng dễ dàng hơn.

Tôi cá nhân thích sử dụng tên số nhiều để đại diện cho một tập hợp, nó chỉ "âm thanh" tốt hơn cho tâm trí quan hệ của tôi.

Tại thời điểm chính xác này, tôi đang sử dụng các tên số ít để xác định mô hình dữ liệu cho công ty của mình, bởi vì hầu hết mọi người tại nơi làm việc đều cảm thấy khó hiểu hơn với nó. Đôi khi bạn chỉ cần làm cho cuộc sống dễ dàng hơn với mọi người thay vì áp đặt sở thích cá nhân của bạn. (đó là cách tôi kết thúc trong chủ đề này, để có được xác nhận về "cách thực hành tốt nhất" cho việc đặt tên bảng)

Sau khi đọc tất cả các tranh luận trong chủ đề này, tôi đã đạt được một kết luận:

Tôi thích bánh kếp của tôi với mật ong, bất kể hương vị yêu thích của mọi người là gì. Nhưng nếu tôi đang nấu ăn cho người khác, tôi sẽ cố gắng phục vụ họ những thứ họ thích.

Số ít. Tôi sẽ gọi một mảng chứa một loạt các đối tượng biểu diễn hàng người dùng 'người dùng', nhưng bảng là 'bảng người dùng'. Nghĩ về bảng là không có gì ngoài tập hợp các hàng mà nó chứa là sai, IMO; bảng là siêu dữ liệu và tập hợp các hàng được phân cấp theo bảng, nó không phải là bảng.

Tất nhiên, tôi sử dụng ORM mọi lúc, và nó giúp mã ORM được viết bằng tên bảng số nhiều trông thật ngu ngốc.

Tôi thực sự luôn nghĩ rằng đó là quy ước phổ biến để sử dụng tên bảng số nhiều. Cho đến thời điểm này tôi luôn sử dụng số nhiều.

Tôi có thể hiểu đối số cho tên bảng số ít, nhưng với tôi số nhiều có ý nghĩa hơn. Một tên bảng thường mô tả những gì bảng chứa. Trong một cơ sở dữ liệu chuẩn hóa, mỗi bảng chứa các bộ dữ liệu cụ thể. Mỗi hàng là một thực thể và bảng chứa nhiều thực thể. Do đó dạng số nhiều cho tên bảng.

Một bảng ô tô sẽ có tên ô tô và mỗi hàng là một ô tô. Tôi sẽ thừa nhận rằng việc chỉ định bảng cùng với trường table.fieldtheo cách là cách thực hành tốt nhất và việc có các tên bảng số ít dễ đọc hơn. Tuy nhiên trong hai ví dụ sau, cái trước có ý nghĩa hơn:

SELECT * FROM cars WHERE color='blue'
SELECT * FROM car WHERE color='blue'

Thành thật mà nói, tôi sẽ suy nghĩ lại về vị trí của mình trong vấn đề này và tôi sẽ dựa vào các quy ước thực tế được sử dụng bởi tổ chức mà tôi đang phát triển. Tuy nhiên, tôi nghĩ đối với các quy ước cá nhân của mình, tôi sẽ gắn bó với các tên bảng số nhiều. Đối với tôi nó có ý nghĩa hơn.

Tôi không thích tên bảng số nhiều vì một số danh từ tiếng Anh không thể đếm được (nước, súp, tiền mặt) hoặc ý nghĩa thay đổi khi bạn làm cho nó có thể đếm được (gà vs gà; thịt vs chim). Tôi cũng không thích sử dụng chữ viết tắt cho tên bảng hoặc tên cột vì làm như vậy sẽ tăng thêm độ dốc cho đường cong học tập đã dốc.

Trớ trêu thay, tôi có thể tạo Usermột ngoại lệ và gọi nó là Usersvì USER (Transac-SQL) , vì tôi cũng không thích sử dụng dấu ngoặc quanh các bảng nếu tôi không phải làm vậy.

Tôi cũng muốn đặt tên cho tất cả các cột ID là Id, không ChickenIdhoặc ChickensId(những người số nhiều làm gì về điều này?).

Tất cả điều này là do tôi không có sự tôn trọng đúng đắn đối với các hệ thống cơ sở dữ liệu, tôi chỉ áp dụng lại kiến ​​thức một mẹo nhỏ từ các quy ước đặt tên OO như thói quen và sự lười biếng của Java . Tôi ước có sự hỗ trợ IDE tốt hơn cho SQL phức tạp.

Chúng tôi chạy các tiêu chuẩn tương tự, khi kịch bản chúng tôi yêu cầu [] xung quanh các tên và trong đó các vòng loại lược đồ phù hợp - chủ yếu là nó bảo vệ các cược của bạn trước các cú đánh tên trong tương lai theo cú pháp SQL.

SELECT [Name] FROM [dbo].[Customer] WHERE [Location] = 'WA'

Điều này đã cứu linh hồn của chúng ta trong quá khứ - một số hệ thống cơ sở dữ liệu của chúng tôi đã chạy hơn 10 năm từ SQL 6.0 đến SQL 2005 - vượt qua tuổi thọ dự định của chúng.

Bảng: số nhiều

Nhiều người dùng được liệt kê trong bảng người dùng.

Mô hình: số ít

Một người dùng số ít có thể được chọn từ bảng người dùng.

Bộ điều khiển: số nhiều

http://myapp.com/users sẽ liệt kê nhiều người dùng.

Dù sao đó cũng là của tôi.

Tôi là một fan hâm mộ của các tên bảng số ít vì chúng làm cho sơ đồ ER của tôi sử dụng cú pháp CASE dễ đọc hơn, nhưng bằng cách đọc các phản hồi này, tôi có cảm giác nó không bao giờ bắt kịp được không? Cá nhân tôi thích nó. Có một tổng quan tốt với các ví dụ về cách các mô hình của bạn có thể đọc được khi bạn sử dụng tên bảng số ít, thêm động từ hành động vào các mối quan hệ của bạn và tạo thành các câu hay cho mọi mối quan hệ. Đó là tất cả một chút quá mức cho cơ sở dữ liệu 20 bảng nhưng nếu bạn có DB với hàng trăm bảng và thiết kế phức tạp thì các nhà phát triển của bạn sẽ hiểu nó như thế nào nếu không có sơ đồ dễ đọc?

http://www.aisintl.com/case/method.html

Đối với các bảng tiền tố và khung nhìn, tôi hoàn toàn ghét cách thực hành đó. Cung cấp cho một người không có thông tin nào trước khi cung cấp cho họ thông tin xấu. Bất cứ ai duyệt db cho các đối tượng đều có thể dễ dàng biết một bảng từ một khung nhìn, nhưng nếu tôi có một bảng có tên là tblUsers thì vì lý do nào đó tôi quyết định tái cấu trúc trong tương lai thành hai bảng, với một khung nhìn hợp nhất chúng để không phá vỡ mã cũ Bây giờ tôi có một cái nhìn tên là tblUsers. Tại thời điểm này, tôi còn lại hai tùy chọn không hấp dẫn, để lại một chế độ xem được đặt tên bằng tiền tố tbl có thể gây nhầm lẫn cho một số nhà phát triển hoặc buộc một lớp khác, hoặc tầng giữa hoặc ứng dụng được viết lại để tham chiếu cấu trúc hoặc trình xem tên mới của tôi. Điều đó phủ nhận một phần lớn giá trị của lượt xem IMHO.

Hệ thống tables/viewscủa máy chủ riêng của mình ( SYSCAT.TABLES, dbo.sysindexes, ALL_TABLES, information_schema.columns, vv) là hầu như luôn luôn nhiều. Tôi đoán vì lợi ích của sự nhất quán, tôi sẽ đi theo sự dẫn dắt của họ.

Nếu chúng ta nhìn vào MS SQL Server'scác bảng hệ thống, tên của chúng được Microsoft gán plural.

Các bảng hệ thống của Oracle được đặt tên theo singular. Mặc dù một vài trong số đó là số nhiều. Oracle khuyến nghị số nhiều cho tên bảng do người dùng định nghĩa. Điều đó không có ý nghĩa nhiều khi họ đề xuất một điều và làm theo một điều khác. Rằng các kiến ​​trúc sư ở hai gã khổng lồ phần mềm này đã đặt tên cho các bảng của họ bằng các quy ước khác nhau, cũng không có ý nghĩa gì cả ... Rốt cuộc, những kẻ này ... Tiến sĩ là gì?

Tôi nhớ trong học viện, khuyến nghị là số ít.

Ví dụ: khi chúng ta nói:

select OrderHeader.ID FROM OrderHeader WHERE OrderHeader.Reference = 'ABC123'

có thể b / c mỗi IDđược chọn từ một hàng cụ thể ...?

Điều này có thể là một chút dư thừa, nhưng tôi sẽ đề nghị thận trọng. Không nhất thiết phải đổi tên bảng, nhưng tiêu chuẩn hóa chỉ là điều đó; một tiêu chuẩn - cơ sở dữ liệu này có thể đã được "chuẩn hóa", tuy nhiên rất tệ :) - Tôi muốn đề xuất tính nhất quán là mục tiêu tốt hơn khi cơ sở dữ liệu này đã tồn tại và có lẽ nó chỉ bao gồm hơn 2 bảng.

Trừ khi bạn có thể chuẩn hóa toàn bộ cơ sở dữ liệu, hoặc ít nhất là dự định làm việc cho mục đích đó, tôi nghi ngờ rằng tên bảng chỉ là phần nổi của tảng băng và tập trung vào nhiệm vụ trong tay, chịu đựng nỗi đau của các đối tượng được đặt tên kém, có thể nằm trong lợi ích tốt nhất của bạn -

Tính nhất quán thực tế đôi khi là tiêu chuẩn tốt nhất ... :)

my2cents ---

Các lựa chọn thay thế có thể:

• Đổi tên bảng SystemUser
• Sử dụng dấu ngoặc
• Giữ tên bảng số nhiều.

IMO sử dụng dấu ngoặc là phương pháp an toàn nhất, mặc dù nó hơi cồng kềnh. IMO là 6 trong số một, một nửa tá khác và giải pháp của bạn thực sự chỉ phù hợp với sở thích cá nhân / nhóm.

Tôi thực hiện trong ngữ nghĩa tùy thuộc vào cách bạn xác định container của bạn. Ví dụ: "Túi táo" hoặc đơn giản là "táo" hoặc "túi táo" hoặc "táo".

Ví dụ: bảng "cao đẳng" có thể chứa 0 hoặc nhiều trường cao đẳng, bảng "cao đẳng" có thể chứa 0 hoặc nhiều trường đại học

a "student" table can contain 0 or more students 
a table of "students" can contain 0 or more students.

Kết luận của tôi là hoặc là tốt nhưng bạn phải xác định cách bạn (hoặc mọi người tương tác với nó) sẽ tiếp cận khi tham khảo các bảng; "bảng rìu" hoặc "bảng xs"

Như những người khác đã đề cập ở đây, các quy ước nên là một công cụ để thêm dễ sử dụng và dễ đọc. Không phải là một cái còng hay một câu lạc bộ để tra tấn các nhà phát triển.

Điều đó nói rằng, sở thích cá nhân của tôi là sử dụng tên số ít cho cả bảng và cột. Điều này có lẽ đến từ nền tảng lập trình của tôi. Tên lớp thường là số ít trừ khi chúng là một bộ sưu tập. Trong tâm trí của tôi, tôi đang lưu trữ hoặc đọc các bản ghi riêng lẻ trong bảng trong câu hỏi, vì vậy số ít có ý nghĩa với tôi.

Cách thực hành này cũng cho phép tôi dự trữ tên bảng số nhiều cho những người lưu trữ các mối quan hệ nhiều-nhiều giữa các đối tượng của tôi.

Tôi cũng cố gắng tránh các từ dành riêng trong tên bảng và cột của mình. Trong trường hợp được đề cập ở đây, sẽ hợp lý hơn khi đi ngược lại quy ước số ít cho Người dùng để tránh phải đóng gói một bảng sử dụng từ dành riêng của Người dùng.

Tôi thích sử dụng tiền tố theo cách hạn chế (tbl cho tên bảng, sp_ cho tên Proc, v.v.), mặc dù nhiều người tin rằng điều này thêm lộn xộn. Tôi cũng thích tên CamelBack hơn dấu gạch dưới vì tôi luôn luôn nhấn + thay vì _ khi gõ tên. Nhiều người khác không đồng ý.

Đây là một liên kết tốt khác để đặt tên cho các nguyên tắc quy ước: http://www.xaprb.com/blog/2008/10/26/the-power-of-a-good-sql-naming-convent/

Hãy nhớ rằng yếu tố quan trọng nhất trong quy ước của bạn là nó có ý nghĩa với những người tương tác với cơ sở dữ liệu được đề cập. Không có "Một vành đai để cai trị tất cả" khi nói đến quy ước đặt tên.

Tôi nghĩ rằng sử dụng số ít là những gì chúng ta đã được dạy trong trường đại học. Nhưng đồng thời bạn có thể lập luận rằng không giống như trong lập trình hướng đối tượng, một bảng không phải là một thể hiện của các bản ghi của nó.

Tôi nghĩ rằng tôi đang nghiêng về số ít tại thời điểm này vì sự bất thường số nhiều trong tiếng Anh. Trong tiếng Đức, nó thậm chí còn tệ hơn do không có dạng số nhiều nhất quán - đôi khi bạn không thể biết liệu một từ có phải là số nhiều hay không mà không có bài viết cụ thể ở phía trước của nó (der / die / das). Và trong ngôn ngữ Trung Quốc không có hình thức số nhiều.

Tôi đã từng sử dụng "Dude" cho bảng Người dùng - cùng số lượng ký tự ngắn, không xung đột với từ khóa, vẫn là một tham chiếu đến một con người chung chung. Nếu tôi không quan tâm đến những cái đầu ngột ngạt có thể nhìn thấy mã, tôi sẽ giữ nó như vậy.

Tôi đã luôn sử dụng số ít đơn giản vì đó là những gì tôi được dạy. Tuy nhiên, trong khi tạo một lược đồ mới gần đây, lần đầu tiên sau một thời gian dài, tôi đã chủ động quyết định duy trì quy ước này đơn giản chỉ vì ... nó ngắn hơn. Thêm một 's' vào cuối mỗi tên bảng dường như vô dụng đối với tôi khi thêm 'tbl_' trước mỗi tên.

Tôi luôn nghĩ rằng đó là một quy ước ngu ngốc. Tôi sử dụng tên bảng số nhiều.

(Tôi tin rằng lý do đằng sau chính sách đó là nó giúp cho các trình tạo mã ORM tạo ra các lớp đối tượng và bộ sưu tập dễ dàng hơn, vì nó dễ tạo ra một tên số nhiều từ một tên số ít hơn ngược lại)

Tôi chỉ sử dụng danh từ cho tên bảng của mình được đánh vần giống nhau, dù là số ít hay số nhiều:

nai nai cá máy bay bạn quần short kính mắt kéo loài con

Tôi không thấy điều này rõ ràng trong bất kỳ câu trả lời trước. Nhiều lập trình viên không có định nghĩa chính thức trong tâm trí khi làm việc với các bảng. Chúng ta thường giao tiếp bằng trực giác về "hồ sơ" hoặc "hàng". Tuy nhiên, với một số ngoại lệ cho quan hệ không chuẩn hóa, các bảng thường được thiết kế sao cho mối quan hệ giữa các thuộc tính không khóa và khóa tạo thành một hàm lý thuyết tập hợp.

Một hàm có thể được định nghĩa là một tập hợp con của một sản phẩm chéo giữa hai bộ, trong đó mỗi phần tử của bộ khóa xảy ra nhiều nhất một lần trong ánh xạ. Do đó thuật ngữ phát sinh từ quan điểm đó có xu hướng là số ít. Người ta thấy cùng một quy ước số ít (hoặc ít nhất là không số nhiều) trên các lý thuyết toán học và tính toán khác liên quan đến các hàm (ví dụ đại số và lambda tính toán).