在表名中添加“ tbl”前缀真的有问题吗？

#1 楼

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

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

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

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

然后我创建了与原始表同名的分区视图：MonthlyAllocation。对于我们对数据库进行的物理更改，没有任何明智的选择。没有报告中断，没有直接访问权限的分析师之前或之后都没有报告过该“表”的问题。

酷故事，但是您要去哪里？

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

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

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

或者您不这样做。对带有冗余元数据的对象进行双重编码。数据库会很高兴地告诉您什么是表，什么是视图，什么是表值函数等。

命名约定很好，只是不要将自己涂在角落。

#2 楼

布伦特（这里是您所指的那个人）。

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

#3 楼

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

您正在查看代码的几种情况，但无法确定是表还是其他内容？

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

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

#4 楼

这是一个可怕的做法。

tbl
tbl_
Table_
t_

...在生产中看到了它们。

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

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

#5 楼

请不要听取准备给其他人打个招呼。 proYou应该始终使用proyour adjTable nouNames来始终使用nouPrefixes prep。提供专业的语言支持，使用专业的语言准备并进行补充。

com请参见adv如何有效地证明其效果？ NouPeople auxCan ververUnder了解您的nou文字书写更好！

#6 楼

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

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

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

数据库并不真正在乎您所谓的表，字段等。它们只是由人工操作员或脚本按特定顺序排列的数据字节。但是，必须维护此数据的人员会喜欢一些有意义的名称，例如“用户”，“订单”和“帐户”。如果使用的是SQL查询（例如“像'a％'一样显示表”），这也更加实用。使用前缀和后缀会使不必要的维护变得不必要地复杂化。

#7 楼

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

最广泛使用的前缀之一是Tbl或tbl，但是后来我有了TBL和tbl_甚至*TableName*_Tbl



在尝试从Visual Studio查询和工作时，这简直是地狱，我不要紧要整套带有前缀tbl的表，但请保持这种方式至少整个数据库。

所以最后我肯定会说是个人喜好，但这也与一致性有很大关系，如果走这条路，很多人至少会很高兴

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

#8 楼

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


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

但是...在少数情况下，后缀/前缀可能会有用，这是我工作的组织的一个示例。

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

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

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


用于存储数据的表[TAB后缀]：


CUSTOMER_ORDER_TAB

CUSTOMER_INVOICE_TAB。


客户端使用的视图[无后缀]：


CUSTOMER_ORDER

CUSTOMER_INVOICE。


基本操作接口； （PL / SQL软件包）[API后缀]：


CUSTOMER_ORDER_API

CUSTOMER_INVOICE_API。


报告生成器； （PL / SQL软件包）[RPI后缀]：


CUSTOMER_ORDER_RPI

CUSTOMER_INVOICE_RPI。


主键索引[PK后缀]：


CUSTOMER_ORDER_PK

CUSTOMER_INVOICE_PK。


二级索引[IX后缀]：


CUSTOMER_ORDER_XXX_IX

CUSTOMER_INVOICE_XXX_IX（其中XXX描述了索引的用法）。


...，依此类推。

这确实是Apps Hungarian的一种形式（请注意，根据目的，相同类型的对象可以具有不同的后缀）。但是，使用后缀而不是前缀。我无法告诉您足够多的方式来阅读该系统。 IntelliSense确实有效，因为我可以键入TBL而不是输入Customer并获得4000个结果，而是获取属于Customer*的实体的所有对象。因此，在这里，我向您展示了元数据如何有用。目的是要用一个名称来标识一组相关的数据库对象，但要根据它们的用途来区分它们。

说过，如果您没有这种系统，那么

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

#9 楼

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

上下文是一件很了不起的事情，尤其是在计算机系统中。在上下文之外，您无法分辨出称为users的东西是表，视图，存储过程还是其他东西。传统的（或只是写得不好）的系统和语言通常使得在阅读代码时难以确定上下文。例如，在Bash中，至少不阅读函数的内容就无法判断function users的作用。在Java中，Map<Uid,UserDetails> users()非常透明，您可以轻松地深入研究细节。

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

#10 楼

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

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

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

#11 楼

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

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;

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

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

#12 楼

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

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

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

随着时间的流逝，即使最初使用它们的原因已被弃用，但仍然存在。 “ Tibbling”是关系数据库管理中最著名的例子之一。

作为总结：它不添加任何值，它在每个表名上恰好增加了4个字节的存储空间除了那里，没有其他原因。它对现代SQL Server系统没有任何帮助，但是如果让您感觉更好，请继续使用它。

#13 楼

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

#14 楼

“不是用tbl为表加上前缀”真的有问题吗？


关于系统？否。
关于其他人？也许。您可以产生很多仇恨。

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

#15 楼

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

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

类似的前缀不管是vw_还是sp_，都会有人进入，您会得到SPname，spname和s_p_name。删除所有前缀，软件就知道项目是什么，如果您真的需要知道，则使用后缀代替。 NameOfMyView_v，NameOfMyProc_sp。可视化搜索要容易得多

但是，如果您在长时间存储的proc中拖网又不能轻易分辨出proc或表是什么视图，该怎么办？很有可能这些别名都将被别名化，即使后缀不起作用，您也不必担心

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

#16 楼

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

select * from tbl

，然后找到我需要的表名（假设我不知道确切的表名）。
这是一步的工作。当然，我们总是可以通过其他步骤找出表名，但是我想说，使用'tbl'前缀，这是一步的工作，这就是为什么我总是更喜欢在其中使用前缀（不一定是'tbl'）我自己的作业项目。

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

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

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

#17 楼

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

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

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

在以后的项目中，诸如SQL Server数据工具（您好，查找所有引用）和数据库只能通过ORM层进行访问，因此没有实用程序，因为查找表的所有用法都是微不足道的（就像重命名一样！）

#18 楼

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

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

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

最后实际上只是归结为团队所喜欢的以及它如何编写代码/脚本。