我正在观看Brent Ozar的一些视频（例如，像这样的视频），他建议不要在表前添加‘tbl’或‘TBL’。

在互联网上，我发现一些博客说它没有为文档添加任何内容，而且“读取它需要更长的时间”。

问题与考虑

• 这真的有问题吗？因为自从我的第一份dba工作以来，我就在表的前面加上“ tbl”（高级DBA告诉我要对组织进行此操作）。
• 这是我需要摆脱的东西吗？我进行了一些测试，复制了一个很大的表并为其赋予了'tbl'前缀，而其他表则保留了该表，并且我没有发现任何性能问题。

我曾经有一张桌子，它闪亮而美丽。它拥有组织的所有财务交易。然后我们开始将数据加载到其中。

在当前月份，他们可以根据需要多次声明和重新声明值。在一个月的最后10天内，他们会重新编号->运行ETL处理->每天查看报告几次。当月结束后，书将被密封，无法修改值。

令人惊讶的是，一家金融服务公司生成了多少金融数据...我们的测试数据集并没有意识到，数据量将使他们的月末程序变得站不住脚。在用新的试验运行替换“当月数据”之前，删除它花费了越来越长的时间。

我们必须做一些事情以使其更快地进行处理，而又不会破坏所有依赖于MonthlyAllocation表的未列入目录的“谁知道什么”列表。我决定扮演魔术师，将桌布从下面放下来。我上了高中，并使用了分区视图。数据已经有一个IsComplete标志，所以我制作了两个表-每个表都有相反的检查约束：MonthlyAllocationComplete，monthlyAllocationInComplete

然后，我使用与原始表相同的名称创建了分区视图：monthlyAllocation。对于我们对数据库进行的物理更改，没有任何明智的选择。没有报告破裂，可以直接访问的分析人员之前或之后均未报告该“表”的任何问题。

很酷的故事兄弟，但是你要去哪里？

如果他们在那里有一个命名约定tbl_MonthlyAllocation怎么办？怎么办？我们是否花费大量的工时来遍历组织中的每个ETL，每个报告，每个临时电子表格并更新它们以使用vw_MonthlyAllocation？然后，所有这些更改当然都要经过更改委员会，这始终是一个快速而轻松的过程。

您的老板可能会问：重新进行所有工作会对公司有何奖励？

另一个选择是，我们将该视图命名为tbl_，而不花所有时间测试，更新和部署代码。您会向所有新员工以及关注时间短的员工解释哪些有趣的轶事，这些新员工必须与数据库一起工作，以了解为什么与对象命名不一致

否则，您不会使用冗余元数据对对象进行双重编码。数据库将愉快地告诉您什么是表，什么是视图，什么是表值函数等。

命名约定是好的，只是不要将自己与它们混为一谈。

布伦特（您在问题中指的那个人）。

我告诉您不要在表名前面添加tbl的原因与我说不在孩子的名字前面添加child的原因相同。您不要称他们为childJohn和childJane。它不仅不会增加任何价值，而且在以后的生活中可能不是孩子-您的对象以后可能会成为视图。

这是一个非常主观的论点，但这是我的观点：tbl前缀是无用的。

您正在查看多少个方案，却无法分辨是表还是其他？

tbl除了在对象浏览器中查看表列表时，还需要做更多的工作来找到您要寻找的表，所以它增加了什么价值？

有人说，他们在处理表或视图时希望在代码中保持清楚。为什么？如果这很重要，为什么不仅要以特殊方式命名视图？在大多数情况下，它们的行为就像表一样，因此我看不出有什么区别。

这是一种可怕的做法。

tbl
tbl_
Table_
t_

...看到它们全部投入生产。

我目前正在使用的一种产品中有一半的表名为tbl_whatever，另一半的表名为“通常”-显然，他们的开发人员正在使用不同的标准。他们的另一个坏习惯是在外键列名前面加上fk，然后是表名，fk然后是列名，这样的列名就很糟糕fktbl_AlarmsfkAlarmsID。该命名约定只是整个tbl_%咒语的逻辑扩展，您可以看到它变得多么荒谬！

我差点忘了另一个使我每天哭泣的数据库。数据类型为列名dtPaymentDate加上dt前缀... ，因为名称确实需要前缀吗？

请不要听取准备给其他人打个招呼。proYou应该始终使用nouPrefixes propro与您的adjTable nouNames一起使用。使用预先准备好的辅助语言，以备不时之需。

请参阅如何有效地证明效果？名词人们可以正确理解您的名词写作的更好！

使用这样的前缀称为匈牙利符号。它的前提很简单：您可以通过命名来确定什么。这在编程语言中尤其常见，特别是当开发人员由于缺乏技能或缺乏语言功能而编写跨越数十页的单片函数时。这是一种助记符，可帮助开发人员使数据类型保持直线。

一般而言，这种命名方式很可能会用在真正的旧代码中，或者仅由正在学习（并且正好学习这种习惯）的开发人员使用，或者只要他们记得就一直在使用。根据我的经验，我发现，如果没有经验丰富的开发人员没有通过编程课程或教程对其进行介绍，很少会看到匈牙利语自发地出现。他们更有可能使用变量名，例如i或x或acct。

除了画自己的一个角落，这实际上只是填充。SQL语法足够精确，开发人员应该始终知道他们是否在谈论字段，记录或数据集（可能是表，视图等）。尽管它可能会提供很好的教学帮助，但通常不应在生产数据库中使用此语法。它可能会损害可读性，并使查找您要查找的表变得更加困难，尤其是当出现几个替代的命名主题时，例如tbl vs. table vs. tab等。

数据库并不真正关心什么，你打电话给你的表，字段等，他们只是字节由它们的人类操作员或脚本安排在一个特定的顺序数据。但是，必须维护此数据的人员会喜欢有意义的名称，例如“用户”，“订单”和“帐户”。如果您使用的是SQL查询，例如“像'a％'一样显示表”，这也更加实用。使用前缀和后缀会使不必要的维护变得不必要。

在继承了第一个SQL Server实例并注意到有很多对象带有前缀之后，我已经阅读了一些类似这样或这样的博客文章，我想开始使用不太冗长的方法和单一的命名约定来开发新的对象（对于我[ 以及可能还有其他开发人员 ]进行对象关系映射的工作要容易得多。

其中最广泛使用的前缀是Tbl或tbl，但后来我不得不TBL和tbl_连*TableName*_Tbl

在尝试从Visual Studio查询和工作时，这简直是地狱，我没关系为整个表tbl加上前缀，但至少要对整个数据库保持这种方式。

因此，最后我肯定会说这是个人喜好问题，但这也与一致性有很多关系，如果您走这条路，那么很多人都会很高兴，至少在您的发展中保持不变。

...另一方面，我只是想说，如果您采用其他方法并使用非前缀的单数名称表，那么将来会使开发人员感到幸福，还有什么比幸福更重要的呢？

是的，添加表示对象类型的前缀是一个问题，并且是不必要的。因为，

1. 有时，物体以某种东西开始生活，但最终会变成其他东西。（例如，由于某种原因，表tblXxx被拆分为tblXxxY，tblXxxZ并替换为连接两个新表的视图。现在，您有一个名为的视图tblXxx）。
2. tbl在编辑器中键入时，其自动完成功能会挂起45秒，然后显示4000个条目的列表。

但...

我将扮演恶魔的拥护者，并说出其他一些建议。在少数情况下，后缀/前缀可能会有用，这是我工作的组织的一个示例。

我们有一个基于实体的ERP系统，其中的业务逻辑是用Oracle PL / SQL编写的。它已有近二十年的历史，但是系统非常稳定（这不是旧系统，我们正在不断开发中）。

该系统基于实体，并且每个实体都将一个表，多个视图，多个PL / SQL包以及许多其他数据库对象关联在一起。

现在，我们希望属于同一实体的对象具有相同的名称，但又不能区分其目的和类型。因此，如果我们有两个名为CustomerOrder和的实体CustomerInvoice，我们将有以下对象：

1. 用于存储数据的表[ TAB后缀]：
   • CUSTOMER_ORDER_TAB
   • CUSTOMER_INVOICE_TAB。
2. 客户端使用的视图[无后缀]：
   • CUSTOMER_ORDER
   • CUSTOMER_INVOICE。
3. 基本操作界面；（PL / SQL软件包）[ API后缀]：
   • CUSTOMER_ORDER_API
   • CUSTOMER_INVOICE_API。
4. 报告生成器；（PL / SQL软件包）[ RPI后缀]：
   • CUSTOMER_ORDER_RPI
   • CUSTOMER_INVOICE_RPI。
5. 主键的索引[ PK后缀]：
   • CUSTOMER_ORDER_PK
   • CUSTOMER_INVOICE_PK。
6. 次要索引[ IX后缀]：
   • CUSTOMER_ORDER_XXX_IX
   • CUSTOMER_INVOICE_XXX_IX（其中XXX描述了索引的用法）。
7. ... 等等。

这确实是Apps Hungarian的一种形式（请注意，根据目的，相同类型的对象可以具有不同的后缀）。但是，用后缀而不是前缀。我无法告诉您足够多的内容，该系统是如此易于阅读。IntelliSense确实有效，因为TBL我可以键入Customer并获取属于实体的所有对象，而不必键入并获得4000个结果Customer*。

所以，在这里我已经展示了如何元数据可以是有用的。目的是使一组相关的数据库对象可通过单个名称标识，但根据它们的用途对其进行区分。

话虽如此，如果您没有这种系统，就不会使用object 的类型作为前缀或后缀。

请注意，我们没有使用诸如_table，_package或的后缀_view（即对象的类型）。例如，（3）和（4）都是PL / SQL软件包，但使用了不同的后缀。（5）和（6）都是相同的，它们都是索引。因此，后缀基于目的而不是类型。

tl; dr（很有可能）添加了冗余信息，从而导致了认知开销，因此应将其删除。

上下文是一件很棒的事情，尤其是在计算机系统中。在上下文之外，您可能无法确定被调用的对象users是表，视图，存储过程还是其他所有对象。传统（或写得不好）的系统和语言通常使得在阅读代码时难以确定上下文。例如，在bash中，你不能告诉什么function users没有做至少读功能的内容。在Java中，Map<Uid,UserDetails> users()它非常透明，您可以轻松地深入了解细节。

将此参数用于SQL表时，什么时候users知道它是表还是视图对用户有用？换句话说，是一种tbl前缀要告诉所有的消费者的东西，他们不知道和需要知道什么？希望绝大多数消费者将针对它编写DML和DQL查询。对于他们来说，它应该只是另一个数据源，无论是视图还是表，都应该与其分区，存储在HDD或SSD或其他任何技术细节上一样相关。DBA当然需要知道这些细节才能运行一些罕见的DDL / DCL查询，但是为了使少数真正了解如何导航架构并获取所有技术细节的少数人的利益，污染名称空间似乎会适得其反。

关系数据库管理系统的特征之一是，它将对客户端的信息逻辑表示与物理存储区分开。前者是行集中的列。后者是作为存储卷上的文件。将一个映射到另一个是DBMS的工作。仅DBA或sysadmin关心哪个硬件支持信息需求。消费者不必，实际上也不应意识到这些问题。

客户也不必担心行集的构造方式。在这方面，基本表，视图或函数都是相同的。每个都简单地产生了一组供客户使用的行和列。即使是简单的标量也可以视为单行单列表。行/列模型是客户端和服务器之间的合同。

通过在工件名称的实现类型前面加上前缀，可以消除关注点的分离。客户端现在知道并依赖于服务器的内部。服务器编码的更改可能需要客户端重新工作。

在这里有很多我同意的答案，告诉您这不是一个非常有价值的命名约定。对于那些对其他答案不满意的人，我将尝试证明许多其他答案在说什么。

SELECT
  bar
  , fizz
  , buzz
FROM dbo.foo

在上面的语句中，我从名为的内容中选择三列dbo.foo。前缀的核心抱怨之一是它们不知道dbo.foo是表还是视图。当然，这是抽象视图的优点之一，但是我偏离了话题。他们说我们应该像这样给对象加上前缀dbo.tblFoo。现在他们可以在上面的查询中看到该对象（可能是表）。但是，如果我们编写与该目标等效的功能，它将看起来像这样。

SELECT
  bar
  , fizz
  , buzz
FROM dbo.Foo --table

我怀疑注释似乎没有用处，即使这是前缀有效地要求的。为了突出显示此元数据注释注入的无用噪声，请考虑更复杂的查询。

SELECT
  qc.occurances
  , i.employeeId
  , q.questionText
FROM dbo.questionCount /*Indexed view*/ qc WITH (NOEXPAND)
  INNER JOIN dbo.interviewer /*partitioned view*/ i ON i.employeeId = qc.interviewerId
  INNER JOIN dbo.question /*table*/ q ON q.id = qc.questionId
WHERE
  EXISTS (
           SELECT 
             1 
           FROM dbo.currentEmployees /*view*/ ce 
             INNER JOIN dbo.questionsAsked /*table*/ qa ON qa.candidateId = ce.candidateId
           WHERE
             ce.employeeId = i.employeeId
             AND
             qa.questionId = q.id
         )
  AND
  qc.occurances > 5;

额外的注释是否会使查询更容易推理，还是只会增加额外的噪音？在我看来，它们只会增加额外的噪音并增加零值。这就是反前缀者试图说的。此外，使用前缀实际上比那些注释差，因为如果需要调整数据模型，则更新注释的成本比更新前缀表的名称要低得多。由于这些前缀是有代价的，并且它们不会传递有价值的信息，因此应避免使用。

有人引用的前缀的另一个优点是，它可以在您的开发环境中进行某种分组或排序。由于我们花费大量时间来编辑代码，因此对于某些人来说，这可能是一个诱人的论点。但是，以我的经验，现代开发环境提供了等效或高级的选择，它们不会使您的代码充满无用的元数据并限制了灵活性。

这已经被讨论过很多次了，但是可能最著名的是美国SQL和关系数据库专家Joe Celko。我个人一直在网上接受他的言论之一（感到荣幸），他将这些前缀称为“晃动”，或更准确地称为“ 拟态 ”。

一般的想法是，这些前缀是很久以前的编码实践（可能是由于命名限制，例如对对象名称的限制为8字节），由于没有明显的用处原因而传给了几代程序员，而不仅仅是“它完成了。”

公司，博客作者和程序员使用自己的编码样式传递信息，某些样式可能比其他样式更“弗兰肯斯坦”。公司可能具有“家庭风格”，程序员被迫学习这种做法。

随着时间的流逝，即使最初使用它们的原因现在已被弃用，事情也会坚持下去。“窃听”是关系数据库管理中最著名的例子之一。

向上舍入：它不添加任何值，它仅在每个表名称上添加正好4个字节的存储空间，这是因为它在那里。它对现代SQL Server系统没有任何帮助，但是如果让您感觉更好，请继续使用它。

我的建议是您立即停止这样做。如果这使您不满意，请在表名的末尾添加“ _tbl” 。当然，由于已经提到的原因，也不需要这样做。最初告诉您这样做的人给了您一些不好的建议。“对于我们组织的系统设置不正确而言，这很有意义”的建议可能很糟糕，但是在那种情况下，修复它是他的工作。仍然是不好的建议。

“不要在表前加上tbl前缀”真的有问题吗？

关于系统？否。关于其他人？也许。你会产生很多仇恨。

我个人不为表添加前缀，而是在其他对象（例如视图，存储过程，函数等）上添加前缀。

我不得不说请停止这样做。过去发生过这种情况，但是通过继续这样做，您会鼓励进入您的环境的新人们以为这是当地的惯例并继续。但是他们不仅会继续，而且会做些不同

当为特定项目拖曳数据库时，我并不是唯一一个会打开对象资源管理器并只是想滚动到它的对象，您知道它是按字母顺序排列的。那就是直到前缀开始使混乱不堪，并且我有了tblname，tbl_name，tbname，t_name和其他一千种变体之前，要真正找到那个已经是一个表的表变得非常困难

同样，为所有vw_或sp_加上前缀，将有人进入，您将获得SPname，spname，s_p_name。删除所有前缀，软件就知道项目是什么，如果您真的需要知道，则使用后缀代替。NameOfMyView_v，NameOfMyProc_sp。直观搜索容易得多

但是，如果您正在拖曳长时间存储的proc而又无法轻易分辨出proc或表是什么视图该怎么办？很有可能这些别名还是会被别名使用，即使后缀无法解决

不要害怕改变自己的工作，如果您走进一个已经习惯使用命名约定的环境，就不要害怕实施自己的命名规则，并开始将事情变得更好。通过匹配现有的混乱状况，没有机会使其混乱程度降低，而只能使其更加混乱

如果我不得不考虑使用前缀“ tbl”的优势，那就是在当前的具有智能感知功能的SSMS中，我可以输入

select * from tbl

然后找到我需要的表名（假设我不知道确切的表名）。这是一步的工作。当然，我们总是可以通过额外的步骤，找出表名，但我要说的是与“TBL”的前缀，这是一步的工作，这就是为什么我总是喜欢一个前缀（不一定是“TBL”）在我自己的作业项目。

编辑：（经过这么多否定表决，我仍然认为值得指出为sql server中的对象的特定类别赋予特定前缀的一些利基优势）。似乎没有人抱怨存储过程/函数/视图有前缀，但是对于表这样做总是有争议的。（对我来说，在现实世界中，无论我们是否给表加上前缀，我都不会在乎。）

我记得在sql server 2005的日子里，有一个需求是要找到在哪些存储过程/视图中使用了哪些表，并以表名作为前缀，使用正则表达式/ C＃是如此容易。（是的，我知道还有其他方法，这里没有争论）。

我的职业随着阅读大量“最佳实践”论文/文章而增长，但是我也看到了在不同情况下，几乎每种“最佳实践”都以一种或另一种方式出现了足够的例外。因此，我总是告诉自己和我的DBA同事，根据业务需求做出判断，“最佳实践”有其确定的位置，但只能在我们自己的环境中考虑。

考虑dbo.User与dbo.tUser。现在假设您想在使用该表的代码中查找所有位置。哪个版本使之更容易（甚至可能？）“用户”一词可能会有很多误报，例如变量名，注释等。

在其他任何答案中我都没有看到过，但是我是开发人员兼DBA，所以也许其他人不必处理遗留代码，因为查询可以嵌入到应用程序中，而并非全部查询完全可以使用架构来限定引用，诸如此类。（即使一切都是完全合格的，你需要找到dbo.User和[dbo].[User]和dbo.[User]等）。或“依赖性信息”过时且不准确的数据库版本（例如，旧版本的MS-SQL）

因此，在我从事的某些项目中，像这样混合在一起，我要求使用a t或v前缀（tbl_变得愚蠢），只是为了使其更具选择性。

在以后的项目中，由于具有诸如SQL Server数据工具（您好，查找所有引用）以及仅通过ORM层进行数据库访问之类的功能，因此没有实用程序，因为查找表的所有用法都是微不足道的（重命名也是如此！）

每一方面都有其优点和缺点。这取决于您的团队或公司的领导才能决定要遵循的约定。

我们使用tbl惯例。主要原因是我们在脚本中知道可以做什么和不应该做什么。我们有各种各样的项目，有些人根本不了解该架构。我们的表具有逻辑名称，因此在编写脚本时很容易找到自己的方式。这样做时，当我们找到一个表时，我们立即（通过IntelliSense）知道它是一个表。可以说添加前缀不会增加太多上下文。但是，删除它意味着没有上下文。

不使用前缀的唯一真正优势是可互换性。但是，我认为这是一种潜在的危险情况。当然，您的脚本和查询不会中断，但是也许您开始过多地依赖该事实，而有些事情却不适用于视图或不明智。

最后，它实际上可以归结为您的团队喜欢什么以及它如何编写代码/脚本。

我曾经有理由在表名前加上“ tbl”前缀。如果要查看数据库对象列表，则可以运行以下查询：

select * from sysobjects

如果只想获取表，则可以执行以下操作：

select * from sysobjects where type = 'U'

谁能记住这一点？如果您的表名称都以“ tbl”开头，则可以使用此查询，而无需记住类型列的值：

select * from sysobjects where name like 'tbl%'

由于您标记了SQL Server 2014，因此这不适用于您，因为从SQL Server 2005开始，您可以这样做：

select * from sys.tables

我想不出为表名加上前缀的另一个原因。