我正在观看一些 Brent Ozar 视频（例如这个视频），他建议不要在表格前加上‘tbl’或‘TBL’。
在网上我发现一些博客说它没有增加文档，而且“阅读它需要更长的时间”。
问题和考虑
当我想创建一些时间戳字段（或其他日期/时间样式字段）时，命名它们的最佳方法是什么？我应该只放 record_timestamp 吗？
我被教导不要将名称Id用于我的表的标识列，但最近我一直在使用它，因为它简单、简短并且非常描述数据的实际内容。
我见过有人建议Id使用表名作为前缀，但这似乎让编写 SQL 查询的人（或程序员，如果您使用的是像实体框架这样的 ORM）做更多的工作，尤其是在更长的表名上，例如CustomerProductId或者AgencyGroupAssignementId
我们聘请的一位第三方供应商为我们创建了一些东西，实际上命名了他们所有的身份列，Ident只是为了避免使用Id. 起初我认为他们这样做是因为Id是一个关键字，但是当我查看它时，我发现它Id不是 SQL Server 2005 中的关键字，而我们正在使用它。
那么为什么人们建议不要使用Id标识列的名称呢？
编辑：澄清一下，我不是在问要使用哪种命名约定，也不是在询问使用一种命名约定而不是另一种命名约定的参数。我只想知道为什么建议不要使用Id标识列名称。
我是一名程序员，而不是 dba，对我来说，数据库只是存储数据的地方。由于我通常构建小型应用程序，并且通常使用 ORM 进行数据访问，因此标识字段的通用字段名称更容易使用。我想知道这样做我错过了什么，以及是否有任何真正好的理由让我不这样做。
我记得在为信息服务硕士学生开设的 DBMS 课程中学习过这样做。为了节省一些输入，您可以输入：
SELECT t1.id, t2.stuff
FROM
someTable t1
INNER JOIN otherTable t2
ON t1.id=t2.id
;
但是......为什么这在存储过程等中是可以接受的？似乎它所做的只是损害了语句的可读性，同时节省了极少的时间。这样做是否有任何功能或逻辑原因？它似乎增加了歧义而不是消除它；我可以看到使用这种格式的唯一可接受的原因是，如果您添加了一个语义上有意义的别名——例如FROM someTable idsTable——当表名不够描述时。
表别名是不好的做法还是只是滥用有用的系统？
我们正在使用来自供应商应用程序的数据库设置，该应用程序很难读取数据库表名，并且没有关于存储位置的文档。我可以理解为什么人们可能想要在专有应用程序中混淆他们的表结构，但该应用程序（企业资源规划）的卖点之一是它的可定制性。
表名类似于 aptrx（Accounts Payable Transactions）和 apmaster_all（奇怪的是，这是 vendor 表）。这是一个极其复杂的数据库，所以我想知道这个约定是否有任何逻辑，或者它是否只是被有意或以其他方式混淆。
据我所知，表名的长度不会显着影响性能，对吗？数据库非常复杂（数百个表），所以排序是有道理的，但我无法想象为什么 AccountsPayableTransactions 不如 aptrx ....
命名表和视图时应该遵循什么标准？例如，将 tbl_ 之类的内容放在表名的开头是否是个好主意？我是否应该以某种方式指定代码/查找表，例如 ct_、lut_ 或代码_？还有其他的做/不做吗？
我正在使用 MS SQL Server 并且有许多带有许多表的数据库，所以如果有一些我们可以用作标准并带有一些支持理性的东西会很好。
当涉及到列命名时，我想要一些关于最佳实践的专家意见。
背景是，根据维基百科，以下语法，
SELECT ... FROM Employees JOIN Timesheets USING (EmployeeID);
比
SELECT ... FROM Employees JOIN Timesheets ON (Employees.EmployeeID = Timesheets.EmployeeID);
但是，该JOIN ... USING语法仅适用于所有具有全局唯一名称的主键列。因此，我想知道这是否被认为是正确的做法。
就个人而言，我总是使用 PK columnid和外键 column来创建表othertable_id。但那样就不可能使用USINGor 了NATURAL JOIN。
任何指向设计风格或表格设计最佳实践指南的链接也将不胜感激！
我正在研究一种广泛使用UUIDs for PRIMARY KEYs 的数据库设计。然而，这让我面临一个非常重要的选择。我如何命名这些列？我会称它们uuid为 ，但UUID作为标识符，我必须在各处引用字段名称：
CREATE TABLE thingie (
"uuid" UUID PRIMARY KEY DEFAULT public.gen_random.uuid(),
foo VARCHAR,
bar VARCHAR,
);
一个直接的替代方案似乎是调用这些列id：
CREATE TABLE thingie (
id UUID PRIMARY KEY DEFAULT public.gen_random.uuid(),
foo VARCHAR,
bar VARCHAR,
);
这样，我就没有列名，并且从语义上讲，我可以说 UUID 确实是一种 ID；在维恩图中，UUID 圆将完全放置在 ID 圆中。
然而，我（并且我相信许多其他人）已经习惯于id与自动递增INTEGER列关联，以至于我担心通过调用这些 ID 来打破某种不成文的规则id。
如果您能通过一些可靠的自行车脱落来消除我的困惑，我将非常感激。事实上，我的问题是：你会如何称呼你的-typed 代理键，为什么？UUID
鉴于当前 Postgres 9.4 中的此设置（来自此相关问题）：
CREATE TABLE foo (ts, foo) AS
VALUES (1, 'A') -- int, text
, (7, 'B');
CREATE TABLE bar (ts, bar) AS
VALUES (3, 'C')
, (5, 'D')
, (9, 'E');
db<> fiddle here（也来自上一个问题）。
我SELECT用 a写了一个FULL JOIN来实现引用问题的目标。简化：
SELECT ts, f.foo, b.bar
FROM foo f
FULL JOIN bar b USING (ts);As per specifications, the correct way to address the column ts is without table qualification. Either of the …