logo标签列表

数据库、表和列命名规范？

databasedatabase-designlanguage-agnosticnaming-conventions
912

每当我设计一个数据库时，我总是在想是否有最佳的方式来命名我的数据库中的项目。我经常问自己以下问题：

  1. 表名应该是复数吗？
  2. 列名应该是单数吗？
  3. 我应该给表或列加前缀吗？
  4. 在命名项目时是否应该使用任何大小写？

是否有任何推荐的指南来命名数据库中的项目？

7
我认为我们应该给表格取复数名词，而给列取单数名词。 - AZ_
7
我将一张桌子视为可以存放多个物品的“存储空间”，而不是单个“实体”，因此我使用复数形式进行命名。当我将表格映射到对象时，我会使用单数形式来命名对象。这只是我的个人观点。 - kazinix
4
在多表联接时，随处使用ID是噩梦般的体验。每次查询都需要重新为该列取别名，这种极度烦人的操作遥遥无期，根本无法通过知道此列是主键而稍微获得些许好处。如果想在表中指定主键，请将其作为第一列。此外，在列名称中指示外键，在我看来也是一种极其不良的反模式。 - ErikE
2
请看**这个答案**。 - PerformanceDBA
1
关于命名规范，我建议使用蛇形命名法（snake_case），这样你就不必担心像帕斯卡命名法（PascalCase）那样缩写词的大写问题。例如：PHPVersion 还是 PhpVersion？在蛇形命名法中，它很明显应该是 php_version 等等。 - Lucas Bustamante
我发现这篇文章 https://www.sqlshack.com/learn-sql-naming-conventions/ 很有帮助。 - U.A
23个回答
378

我建议查看微软的SQL Server示例数据库：https://github.com/Microsoft/sql-server-samples/releases/tag/adventureworks

AdventureWorks示例使用非常清晰和一致的命名约定，使用模式名称来组织数据库对象。

  1. 表的名称为单数形式
  2. 列名称为单数形式
  3. 模式名称用于表前缀（例如：SchemaName.TableName）
  4. 帕斯卡命名法（又称大驼峰命名法）
17
http://www.wilsonmar.com/sql_adventureworks.htm是对AdventureWorks模式的优秀分析。 - Daniel Trebbien
251
我不会依赖Microsoft去制定任何标准-如果你看一下他们的Northwind数据库，你会发现他们使用复数表名、单数列名、架构前缀用于表、表前缀用于主键列、匈牙利式约束前缀，最糟糕的是使用空格" "表示多词表名。此外，SQLServer的系统表使用复数形式，因此AdventureWorks在这些数据库中可能是个例外。 - Marcus Pope
85
我认为这里的主要问题在于“单数表名派”似乎将数据库表视为一个实体，而不是像“复数表名派”那样将其中的行视为实体。你必须问问自己，它是哪个实体。如果数据表只是行的容器，使用复数命名是否更合理呢？你永远不会在代码中将集合命名为单数，那么为什么要将数据表命名为单数呢？为什么不保持一致性？我听到了关于排序和加入的所有论据，但它们都似乎非常牵强附会。如果最终只是个人喜好的问题，我将坚持保持一致并使用复数形式。 - Jason
6
还要考虑潮流的方向。似乎趋势是朝着复数表名的方向发展，尤其是由于SQL Server中所有系统表都是复数形式，而Entity Framework的默认设置也是复数形式。如果这是Microsoft的立场，我希望走向未来20年，就要顺应这个趋势。即使Oracle的数据库规范也要求使用复数表名。想想看，在引入“var”关键字时有多少C#开发人员反感，现在它已成为定义变量的广泛接受的方式。 - Jason
7
@Jasmine - 我理解你的观点，不过我认为你无意中倒过来命名了你的示例表格。“TableOfInvoices” 应该缩短为“Invoices”，这是我更喜欢的。你可能本意是 “InvoiceTable”，这样缩短“Invoice”更合理。 - Derek
显示剩余12条评论
373

晚了一些，但简要回答如下：

  1. 复数表名： 我的偏好是使用复数。
  2. 单数列名： 是的。
  3. 添加表或列前缀：
  • 表： 通常不添加前缀最好。
  • 列： 不添加。
  1. 在命名项中使用任何情况： PascalCase 对于表和列都是适用的。

详细说明：

(1) 您必须做的事情。 有很少的事情是每次都必须以某种方式完成的，但有一些。

  • 使用“[TableName的单数形式]ID”格式来命名主键。也就是说，无论您的表名是“Customer”还是“Customers”，主键应该是“CustomerID”。
  • 此外，不同表中的外键必须保持一致地命名。不遵循这个规则的人应该受到惩罚。我认为，虽然定义外键约束通常很重要，但一致的外键命名始终很重要。
  • 您的数据库必须有内部约定。即使在后面的章节中，您看到我的灵活性非常大，在数据库中命名必须非常一致。无论您的客户表被称为“Customers”还是“Customer”，比起保持相同的数据库命名方式更不重要。您可以抛硬币来决定如何使用下划线，但然后您必须始终保持使用它们的方式。如果不这样做，您就是一个自尊心低的坏人。

(2) 您应该做的事情。

  • 在不同的表中，代表同一种数据的字段应该使用相同的名称。比如说一个表中使用Zip，而另一个表中使用ZipCode是不合适的。
  • 在表或者列名中，可以使用PascalCasing来分隔单词。虽然使用camelCasing也不会有本质问题，但是这不是惯例，看起来可能有些怪异。我们稍后再讨论下划线的使用。（你不能像古时候那样使用全大写字母，二十年前在DB2中使用OBNOXIOUSTABLE.ANNOYING_COLUMN是可以的，但现在不行了。）
  • 不要人为地缩短或缩写单词。一个名称越清晰易懂，就越好，而不是越短越容易引起混淆。极度缩短的命名方式已经过时了。例如Cus_AddRef，这是什么意思呢？客户地址参考？客户附加退款？自定义地址推荐？

(3) 需要考虑的事情。

  • 我认为表名应该使用复数形式，而有些人则认为应该使用单数形式。请在其他地方阅读相关争议。但是无论如何，列名应该都使用单数形式。即使使用了复数形式的表名，表示其他表的组合的表也可能是单数形式的。例如，如果你有一个和一个表，用于表示商品参加促销的表可以被命名为Promotions_Items，但我认为它也可以合理地被命名为Promotion_Items（反映出一对多的关系）。
  • 要一致地使用下划线，并且只用于特定的目的。普通的表名可以通过PascalCasing来清晰地区分单词，不需要下划线。请将下划线保留给表示关联表的情况，或者用于前缀，关于前缀的使用我将在下一条说明。
  • 前缀并不是好也不是坏。通常情况下，不建议在前两个数据库中使用前缀来进行一般性的主题分组。表最终难以容易地适应您的分类，这实际上会让查找表格更加困难。有了经验，您可以计划和应用一个比危害更多的前缀方案。我曾经在一个数据库中工作，其中数据表以 tbl 开头，配置表以 ctbl 开头，视图以 vew 开头，存储过程以 sp 开头，函数以 fn 开头，还有其他一些；它被精心且一致地应用，所以效果还不错。只有当您有真正单独的解决方案因某种原因驻留在同一个数据库中时，您才需要添加前缀；在对表格进行分组方面，添加前缀非常有帮助。前缀也适用于特殊情况，例如临时表格，您希望这些表格突出显示。
  • 很少（如果有的话）会想要为列添加前缀。
    • 13
    不同表格上代表相同数据类型的字段应命名相同。不要在一个表格上使用"Zip"，在另一个表格上使用"ZipCode"。是的，无数次是的。你能看出我们的数据库没有按照这种方式设计吗？一个人的ID可能会有十几种不同的称呼方式，非常麻烦。我一直遵循这个规则，在我掌控设计的任何数据库中都可以使生活变得更简单。 - HLGEM
    114
    我认为主键应该只是“ID”。这样简单的约定可以使主键可预测且易于识别。但当它在其他表中用作外键时，我会在前面加上表名（“PersonID”）。此约定有助于区分同一表中的主键和外键。 - Triynko
    66
    在多表连接查询时，随处使用ID会让人感到十分痛苦。重命名那个该死的ID列在每个查询中都要一遍又一遍地进行操作，这种极其恼人的过程根本无法通过稍微了解主键所带来的轻微优势来弥补。如果你想为一个表指定主键，就把它作为第一列吧。此外，在列名称中表示外键在我看来也是一种完全错误的反模式。 - ErikE
    20
    如果你只使用“ID”，程序无法确定它属于哪个表。通过添加表名前缀，你可以轻松地通过代码截取主键的最后两位数字并知道它属于哪个表。很多时候，IT和DBA人员没有意识到，在设计数据库时采用某些方式会给程序员带来编码优势。 - dallin
    27
    @ErikE 我的意思是你不知道 CustomerID 是 Customer 表的主键还是其他表中的外键。这只是一个小问题。为什么要使用像 c 这样的差命名呢？CustomerID = Customer.ID 很清楚，因为你可以看到你正在将一个外键与一个主键连接；它不是多余的，因为两边是两个不同的东西。在我看来，单字符命名是很糟糕的做法。 - Dave Cousineau
    显示剩余17条评论
    107

    好的，既然我们要发表意见:

    我认为表名应该是复数形式。表格是实体的集合（一张表），每行代表一个单独的实体，表格则代表这个集合。因此，我会称一个Person实体的表为People（或Persons，随意取决于您）。

    对于那些希望在查询中看到单数“实体名称”的人，我会使用表别名来实现：

    SELECT person.Name
FROM People person

    有点像LINQ的"from person in people select person.Name"。

    至于2、3和4，我同意@Lars的观点。

    18
    在英语中，我们不会说“Look at all the person out there in that crowd of person！”使用单数词来指代复数的概念问题是可以预料的，这既不常见也不正确。 "Data"是个例外，经常用来指代一段体积物质中的某一部分，就像“cake”一样。“Would you like (a piece of) cake?”因为包含多个个体信息，所以将表命名为"People"比命名为"Person"更合理。对于ROW的数据类命名为"Person"也是有意义的，单数列名也是如此。 - Triynko
    7
    @Emtucifor：归根结底，所有语言都是任意和约定俗成的。我只是在争论我们通常将一组物品称为其中物品类型的复数形式。因此，每行都包含有关单个人信息的行集合将被称为People的集合。但如果你想把它称为Person的集合，那就随便你了。 - Triynko
    4
    是的，哈哈。把表命名为“PersonCollection”就相当于命名为“People”。相比之下，仅将此类集合命名为“Person”是没有意义的 :) - Triynko
    4
    @Emtucifor: 让我们从另一个角度考虑，将命名规则放在一个背景下。假设你有用于表示行和表的对象类。很显然，“Person”适用于表示数据行的类。如果您的表也被命名为“Person”，那么您可能会遇到命名冲突或混淆等问题。我认为更合理的做法是准确地使用复数形式为对象命名。包含个人数据的行应该称为Person，而包含关于人或多个人的信息的表应该称为People、PersonCollection、Persons等。 - Triynko
    5
    无论你选择哪种方式，我的方法是可以的。如果你按照我的方法，你可以将People表别名为"person"，然后使用SELECT person.Name来解决问题。;-) - Matt Hamilton
    显示剩余13条评论
    85

    我在一个带有三个数据库管理员的数据库支持团队中工作，我们考虑的选项是：

    1. 任何命名标准都比没有标准好。
    2. 没有“真正”的标准，我们都有自己的偏好。
    3. 如果已经有标准，请使用它。不要创建另一个标准或弄乱现有的标准。

    我们为表使用单数名称。表通常以系统名称（或其首字母缩写）为前缀。如果系统很复杂，则可以更改前缀以逻辑地将表组合在一起（例如reg_customer、reg_booking和regadmin_limits）。

    对于字段，我们期望字段名称包括表的前缀/首字母缩写（即cust_address1），我们还倾向于使用一组标准后缀（_id表示主键，_cd表示“代码”，_nm表示“名称”，_nb表示“号码”，_dt表示“日期”）。

    外键字段的名称应与主键字段相同。

    例如：

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

    在开发新项目时，我建议您列出所有首选的实体名称、前缀和缩略词，并将该文档提供给您的开发人员。然后，当他们决定创建一个新表时，可以参考该文档，而不是“猜测”该表和字段应该被称为什么。

    9
    特别是对于第三点，我们有一群人都来自同一家公司，并试图在他们所做的任何事情上强加他们旧的命名标准（而其他人都没有使用）。非常令人恼火。 - HLGEM
    46
    当然，这段 SQL 代码不易读懂；但我认为我能翻译它。"cust_nm" 应该改成 CustomerName，"booking_dt" 应该改成 BookingDate。至于 "reg_customer"，我不确定它具体指什么。 - Ian Boyd
    3
    @Ian。意图是让您坚持使用您习惯的命名规则并保持一致性。我始终知道任何日期字段是_dt，任何名称字段是_nm。'reg'是一个“注册”系统（预订、客户等），所有相关表都将具有相同的前缀。但是每个人都有自己的做法... - Guy
    8
    我同意，一个特定的标准不如拥有一致的标准重要。但是有些标准是错误的，比如DB2以及像CSPTCN、CSPTLN、CSPTMN和CSDLN这样的列名。人们应该学会长名称的发明 - 我们可以承受使事物更易读的代价。 - Ian Boyd
    20
    多年来，我在我所开发和营销的应用程序中，在我的表格末尾添加了新的列。有时候，我在列中使用英文名称，有时候我使用西班牙语，有时候我重新使用某些列，而不是删除它们并添加一个适当的描述性名称以说明其用途。我故意这样做是为了混淆我的源代码，以防止其他人试图破解或反向工程化我的代码。只有我能理解它，其他人会感到沮丧！这样，他们总是必须依赖于我来得到任何信息！ - FrankRuperto
    55
    1. 表格应该根据其所代表的实体进行命名。Person，而不是persons，是您引用记录中每个人的方式。
    2. 同样的道理。列FirstName确实不应该称为FirstNames。这完全取决于您想用该列表示什么。
    3. 不行。
    4. 可以。为了清晰起见使用大小写。如果您需要像“FirstName”这样的列，使用大小写会使其更易于阅读。

    好的，那就是我的$0.02。

    5
    为了更清晰地解释第三点，前缀是将元数据嵌入列名称的一种方式。对于任何现代数据库来说，出于与（过度使用的）匈牙利命名法相同的原因，不应该有必要这样做。 - Mark McDonald
    32
    “从order中选择前15个”或“从orders中选择前15个”？我（人类）更喜欢后者。 - Ian Boyd
    11
    @Ian Boyd: 是的：选择前100个报告，从报告R表和VisitReport VR表内连接，条件是R.ReportID = VR.ReportID。这完全取决于你如何思考。如果在一个罐子上贴上一张柠檬的图片，你会知道里面有柠檬，不需要外面有两个柠檬表示它可能是复数。当然，你可以用书面单词“lemons”来标记它。但它也可能只是“lemon”。要获取名为“lemon”的资源，请访问此处。 - ErikE
    6
    如果在列名中使用大写字母，每个列名需要增加$0.01；如果在列名中使用下划线，则每个列名需要再增加$0.01，这样可以更容易地区分列名。总计=我向您捐赠$0.02！ - FrankRuperto
    7
    一张表应该以它所代表的实体命名。一张表是实体的集合。虽然表本身也是一个实体，但它是“表格”类型的实体，将这个类型添加到它的名称中是没有意义的。 - Trisped
    显示剩余4条评论
    46
    我经常听到这样的论点：表格是否使用复数形式仅仅是个人口味问题，没有最佳做法。作为程序员而不是DBA，我并不认为这是正确的。据我所知，除了“因为它是对象集合，所以用复数形式更有意义”外，没有正当理由使用复数形式命名表格，而使用单数形式却可以在代码中获得实际效益。例如：
    1. 它避免了复数含义不明确造成的错误和疑惑。程序员并不以拼写专家著称，某些词汇的复数形式容易让人困惑。例如，复数形式要以“es”还是只要以“s”结尾？是persons还是people？当你在一个大团队的项目中工作时，这可能会成为一个问题。例如，有一个团队成员使用了错误的复数形式来创建一个表格。等到我与这个表格交互时，它已经出现在了我无法访问或需要花费太长时间才能修复的代码中。结果是，我必须记住每次使用这个表格都要拼错它的名字。类似的事情也发生在我身上。你使整个团队的每个成员都能够一致、轻松地使用正确的表格名字而不出错或一直查找表格名字，那么更好的做法是使用单数形式。在团队环境中，单数形式更容易处理。
      2. 如果您在表名使用单数版本，并在主键前缀加上表名，那么您现在可以轻松地通过代码确定主键或反之亦然，从而获得优势。您可以得到一个包含表名的变量，在末尾拼接“Id”，然后通过代码获得表的主键，而无需进行额外的查询。或者，您可以从主键末尾截断“Id”以通过代码确定表名。如果您在主键中使用“id”而没有表名，则无法通过代码从主键确定表名。此外，大多数将表名复数化并在主键中加上表名的人在PK中使用表名的单数形式(例如statuses和status_id)，这完全不可能做到。
      如果您将表名变成单数形式，它们可以与它们所代表的类名匹配。再次说明，这可以简化代码，使您能够做出非常棒的事情，比如仅通过表名实例化一个类。它还使您的代码更加一致，这会导致......
      如果您将表名变成单数形式，它将使您的命名方案在每个位置都保持一致、有组织且易于维护。您知道在代码的每个实例中，无论是作为列名、作为类名还是作为表名，它都是完全相同的名称。这使您可以进行全局搜索，查看数据在何处使用。当您将表名复数化时，会有一些情况下您将使用该表名的单数版本(它变成的类，在主键中)。让数据有时被引用为复数，有时被引用为单数，这是没有意义的。
      总之，如果您将表名复数化，您将失去使代码更智能和更易于处理的所有优势。甚至可能有一些情况需要查找表/数组以将表名转换为对象或本地代码名称，这是可以避免的。尽管初始感觉有点奇怪，但单数形式表名比复数形式表名提供了显著的优势，并且我认为这是最佳实践。
    5
    这是非常好的推理。争论似乎在于匹配集合名称还是类名称，而这是关于类名称方法的很好的解释。谢谢！ - Evan Moran
    2
    讲解得非常好！一些 SQL 人员习惯于以集合为基础进行思考，他们错误地将表模式视为字面上的记录组！在面向对象（OO）术语中：表模式类比于类型/类定义，属性/字段类比于列，记录类比于对象，表类比于对象集合。例如，“_Person_” 类只是一个“_Type_”，甚至不是一个对象，就像表模式是一个抽象模板来保存您的数据一样。Person p; 对象代表 1 条记录，而 List<Person> lp; 集合则是选择了 0 条或多条记录。 - MikeTeeVee
    36

    我也赞成采用 ISO/IEC 11179 风格的命名约定，但需要注意它们是指导方针而非强制性规定。

    参见维基百科上的 数据元素名称：

    “表是实体的集合，并遵循集合命名准则。理想情况下，使用集体名称，例如：人事部门。复数形式也是正确的，例如：员工。不正确的名称包括：Employee、tblEmployee 和 EmployeeTable。”

    当然，规则都有例外。例如，一个始终只有一行的表可能更适合使用单数名称，例如配置表。而且一致性非常重要：请核查您所在的商店是否有命名约定，如果有，请遵循；如果您不喜欢它，请提出商业案例以便更改，而不是单枪匹马地行动。

    2
    -1：所引用的文本与ISO/IEC 11179无关。不应信任所引用的维基百科页面；请阅读实际标准（http://metadata-standards.org/11179/#A5）。 - mkadunc
    1
    @onedaywhen：我对这个主题了解不够，无法纠正维基百科页面；此外，维基百科页面并不是错误的，而是有误导性——它没有明确说明ISO/IEC 11179包括数据库命名约定，只是说“在关系型数据库中命名表和列时适用ISO/IEC 11179”。然后提供了一个关系型数据库可能使用的命名约定示例。它让你认为这个示例是从标准中摘取的，但实际上是维基百科文章作者编造的。 - mkadunc
    29

    我们的偏好:

    1. 表名应该是复数吗？
      从逻辑上看，将其视为一个集合的论点是有道理的，但您永远不知道表中会包含多少项（0、1或多个）。复数规则会使命名变得不必要地复杂。例如：1个房子，2个房子，老鼠 vs 老鼠，人 vs 人们等等，甚至我们还没有考虑其他语言。

      Update person set property = 'value' 将作用于表中的每个人。
      Select * from person where person.name = 'Greg' 返回一组person行/结果集。

    2. 列名应该是单数吗？
      通常是，除非您违反了规范化规则。

    3. 我应该在表或列前加前缀吗？
      大多数情况下是平台偏好。我们倾向于使用表名前缀来命名列。我们不添加表前缀，但是我们会添加视图（v_）和存储过程（sp_或f_（函数））的前缀。这有助于那些想尝试更新视图中实际计算字段的v_person.age（无论如何都无法进行更新）的人们。

      这也是避免关键字冲突的好方法（delivery.from会出现问题，但delivery_from不会）。

      这确实使代码更冗长，但通常有助于可读性。

      bob = new person()
      bob.person_name = 'Bob'
      bob.person_dob = '1958-12-21'
      ... 非常易读和明确。但是，这可能会失控：

      customer.customer_customer_type_id

      表示customer和customer_type表之间的关系，并指示customer_type表上的主键（customer_type_id）。如果您在调试查询时看到“customer_customer_type_id”，则可以立即知道它来自哪个表（customer表）。

      或者，当customer_type和customer_category之间存在M-M关系时（只有某些类型适用于某些类别）

      customer_category_customer_type_id

      ...... 有点长。

  • 在命名项目时，我应该使用任何大小写格式吗？

    是的 - 应该使用小写字母，并且要用下划线分隔。这样可以使名称易读且跨平台兼容。结合以上第3点，也更加合理。

    • 但是，大多数情况下这些只是个人偏好。只要保持一致性，在任何需要阅读的人看来都应该是可预测的。

    3
    对我来说，"SELECT * FROM people AS person WHERE person.name = 'Greg'"听起来最自然。 - Kenmore
    1
    @Zuko 大多数情况下，表主键的命名约定是<表名><id>，例如 PersonID 或 Person_ID 等。因此，如果每个记录都代表一个单独的人而不是一组人，则将表名命名为复数形式就没有意义了。 - Mr. Blond
    1
    “你永远不知道表格将包含什么内容（0、1或多个项目）”，那为什么要用单数呢？在99%的情况下，表格将包含多行，否则您可能需要重新设计系统。 - Mehdi Dehghani
    1
    抱歉，但我认为这不是可读的代码。 首先，person_name中的下划线在代码中远非易读。在代码中应该只是bob.name和bob.dob。 至于命名？再次抱歉，所有小写字母和下划线似乎对我来说非常古老和难以阅读。 - SuperDre
    26
    21
    如果您在这里提供一个摘要，那么您的答案将更易理解。不过，这是一个很好的提示！ - Ola Eldøy
    18

    虽然我知道现在已经有很好的答案回答了这个问题，但我想就第3点提供我的观点，即列名的前缀问题。

    所有列应该命名一个在它们所属的表中唯一的前缀。

    例如，给定表"customer"和"address"，我们可以使用"cust"和"addr"作为前缀。"customer"表中会有"cust_id"、"cust_name"等列。"address"表中会有"addr_id"、"addr_cust_id"（连接到customer的外键）、"addr_street"等列。

    当我第一次听到这个标准时，我非常反感；我讨厌这个想法。我无法忍受那么多额外的输入和冗余。现在我已经足够有经验以至于我永远不会回头。

    这样做的结果是数据库架构中的所有列都是唯一的。这其中有一个主要的好处，其优势超过了所有反对它的论点（当然，这是我的观点）：

    你可以搜索整个代码库，并可靠地找到每一行涉及特定列的代码。

    来自#1的好处非常巨大。我可以弃用一列并知道在从架构中安全删除该列之前需要更新哪些文件。我可以更改列的含义并知道需要重构哪些代码。或者我只需确定某个部分是否使用了某个列的数据，这很有用。我数不清多少次这已经将一个可能庞大的项目变成了一个简单的项目，也不知道我们在开发工作中节省了多少小时。

    另外，相对较小的好处是，只有在进行自连接时才需要使用表别名：

    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%';
    1
    那么你就无法“可靠地找到与特定列有关的每一行代码”……这不就是重点吗？ - raveren
    6
    @Raveren - 你仍然可以这样做。如果你只是使用 "SELECT *"，那么该查询对此目的无关紧要。当/如果稍后你使用该查询的结果时，你需要使用列名来处理其数据，因此这就是你在代码中需要担心的地方，而不是 SQL 语句本身。 - Granger
    2
    除非你是在使用非面向对象语言编写整个应用程序，否则拥有一个体面的ORM层会使这个论点变得无效。 - Adam
    1
    @Adam - 多余？“你一直在使用那个词……”即使没有那个词，你的评论仍然没有意义。好的ORM/EF层遵循数据库命名约定，因此执行愚蠢的文本搜索的能力仍然适用。此外，任何非微不足道的应用程序最终都需要绕过ORM/EF/LINQ层。过程式编程并不总是能够很好地映射到关系型；这是一种不同的思维方式。 - Granger
    7
    基于这个答案，我决定在一个大项目中尝试使用表前缀，并想要回报结果。它确实使重构表格变得非常容易，这很棒！然而，它比我预期的更加痛苦。我们的数据库有很多复杂命名的表格。记住Cust是Customer的前缀很容易，但不太容易记住HazardVerificationMethod的前缀。每次我写表格或字段时，我都必须停下来想一想前缀。最终，我决定速度和方便性比可搜索性更重要，但我觉得这是一个有价值的经验。 - dallin
    显示剩余5条评论
    网页内容由stack overflow 提供, 点击上面的
    可以查看英文原文，
    原文链接