您好所有人。每当我开始为任何应用程序开发新数据模型时，我都会遇到同样的问题：
是否方便多元化表名？
存储表格的地方，例如用户;你会打电话给'用户'或'用户'吗？
我没有多元化，因为有了这个数据模型，我就为ORM生成了实体，并且似乎更正确来实例化一个新的'用户'那是一个新的'用户'。
我想知道想一想。
向所有人致以问候！
答案 0 :(得分：3)
我想这完全取决于您实际使用数据库的目的：
我没有多元化，因为使用这个数据模型，我然后为ORM生成了实体，并且实例化一个新的用户＆＃39;似乎更正确。一个新的＆＃39;用户＆＃39;。
但除了sql，哪个框架，哪些工具之外，你还没有提供关于你使用哪种语言的信息。
我通常说最好是符合框架或ORM的标准，例如在.NET Entity Framework中，表格是generated with a singular notation，映射到这些表格的类名也是单数的，而在Ruby on Rails ActiveRecord它们在数据库中是generated pluralized但映射类是单数的。
我认为没有更好的方法，但是，如果您的应用程序的数据比应用程序本身更重要（例如，我们可能会从该框架或语言最终迁移到完全不同的东西）或者如果有的话将是其他人直接在数据库上工作（人们做报告，DBA和分析师等）然后我建议你把表格复数为数据库人更敏锐以这种方式使用它。
如果您认为在数据库级别多元化是有意义的，users表可能会有多个用户，依此类推。如果您不打算存储具有相同结构的多个记录，为什么还要以表格形式存储数据？比多数化更有意义。
如果您使用 X 语言创建数据类型的数据，请说，对于用户，您不要将其称为user，而是将其称为users可能，因为它可能包含多个，即使你最初只存储了一件东西。
因此，为什么复数表名是一种好的方法，这是我的理由，此外，如果复数打破约定，你几乎总能在ORM中设置映射，以便你可以设置User类例如，映射到users表。
更新： here is another good discussion，他们对联合关联提出了重要意见
答案 1 :(得分：2)
我认为类似Rails的约定在这里是最好的。 ORM中的奇异模型名称，数据库表中的复数名称。原因是他们有不同的责任。该表存储了多个用户的记录，而 - 正如您所指出的 - 您通常会实例化单个用户。