2

例子：

CREATE TABLE ErrorNumber
(
     ErrorNumber int,
     ErrorText varchar(255),
)

这可能会导致查询如下所示：

SELECT ErrorNumber FROM ErrorNumber WHERE ErrorNumber=10
4

12 回答 12

10

我假设 ErrorNumber 作为表中的列是主键？在这种情况下，您可以将表列命名为 ErrorNumberID。

我不知道这是一种糟糕的编码实践，但我无法想象它会为可读性做任何事情。您提供的示例很好地展示了查询最终会变得多么混乱。

我不确定的另一件事是（列名与表名相同）是否会导致错误？我敢肯定它因供应商而异。

于 2009-05-14T19:40:15.287 回答
5 
CREATE TABLE Errors (
    Number int,
    Description varchar(255)
)

我觉得上面是一个更好的命名方案，因为：

  • 表名现在代表它是什么。
  • 由于它们所在的表，这些列中不需要“错误”一词。
于 2009-05-14T19:52:44.477 回答
4

您可以坚持默认并命名您的主键 ID。

于 2009-05-14T19:41:13.053 回答
3

我认为拥有与其表共享相同名称的列不是一个好主意。即使它有效，它也会令人困惑。尝试将您的表重命名为 Error 或将列重命名为 ErrorNum 甚至只是 Num

于 2009-05-14T19:42:38.887 回答
2

是的。简单数据模型中的绝大多数简单表应该是复数名词。在您的示例中，该表应称为“错误”，有两列，“id”和“description”。

于 2009-05-14T19:49:15.797 回答
2

我同意 DWC，并且会更进一步，将表命名为更具描述性的名称，例如它是哪种类型的错误表。如果它用于存储您将在代码中使用的错误是一回事，如果它是一个记录错误的表是另一回事。不确定您将其用于什么目的，因此完全取决于您将其命名为对其所使用的上下文有意义的名称。当我看到一个名为“错误”的表时，我不确定它是日志表还是用于查找错误代码的查找表。如果是后者，那么像 ErrorCodes 这样的名称可能是个好名字。

CREATE TABLE ErrorCodes
(
Id int,
Number int,
Description varchar(255)
)
于 2009-05-14T20:08:07.170 回答
0

穷吗？也许有点，但没什么大不了的。

于 2009-05-14T19:42:29.790 回答
0

我同意这没什么大不了的。

我们在应用程序中有大量表，它们只有 id 和“名称”字段。它们用于下拉列表。

所以我这样设置它们：

列表名称是：州

表名是：状态

ID 是：StateID

实际状态值列是：StateName

它对我们有用。

在您的具体情况下，我会按照上面的建议进行操作，只需将表命名为错误。

于 2009-05-14T19:46:52.290 回答
0

如果任何数据库供应商对此感到困惑，请使用另一个数据库供应商。任何数据库都应该可以轻松地解析它而不会出现问题。

我同意出于可读性的原因，这可能不是好的做法。

于 2009-05-14T19:50:57.383 回答
0

它是形式问题。就个人而言，我将大多数表名设为复数，那么它永远不会发生。在这种特殊情况下，我的表将是 ErrorNumbers 并且表字段将是 ErrorNumber （实际上我会使用 ErrorNumberID ）

不过，这取决于您或您的公司的编码标准。如果是不良形式，则属于极轻微的违规行为。如果有的话，那就是变量名称上缺少的 ID，这更像是一种违规。

于 2009-05-14T19:53:16.207 回答
0

如果一个表预计包含多于一行，那么我的偏好是使用一个集体术语作为名称。请注意，这与使用单数并附加“s”不同，例如，我更喜欢“Personnel”和“Payroll”而不是“Employees”和“EmployeesSalaries”。并且应该取出并拍摄诸如“实体”之类的名称:)

鉴于此，并考虑到您设计中的列，我将有问题的表命名为“错误”。现在，我知道许多编码人员更喜欢表名的单数术语，但这只是一种不同的风格，而不是“糟糕的编码实践”。

偶尔需要单行表，例如包含 pi 的共享近似值的表“常量”，以供使用 DBMS 的应用程序使用......但是我想到的“常量”表有多个列，每个列用于不同的常量所以它得到了一个统称作为一个名称。

也许如果您的应用程序只使用过一个常量，那么您最终可能会得到一个名为“Pi”的表？好吧，我做出的另一种样式选择是使用 UpperCamelCase 作为表名，使用 lower_case_separated_by_underscores 作为列名。因此，我仍然能够（几乎）从列中区分表，即

SELECT pi FROM Pi;

[还有一个代码解析器，比如 SO 上的那个，也让工作变得更容易！]

实际上，我倾向于几乎完全使用表相关名称，所以我更有可能写：

SELECT P1.pi 
  FROM Pi AS P1;

还要考虑一些集体术语的拼写与单数术语相同，例如“物种”、“鹿”、“绵羊”、“鱼”，可能还有许多其他不属于动物王国的术语，但我刚才有精神障碍:)

因此，尽管我可以设想一个 SQL 表包含一个具有相同名称的列，即使使用我喜欢的数据元素命名约定，这种情况确实很少见。

于 2009-05-15T08:09:12.350 回答
0

+1 dwc 的简洁名称。

“列名应该表示值域”的问题在于它忽略了上下文。列名仅存在于表的上下文中。它从不模棱两可。它的域不受其名称的控制。

Does the person exist who cannot distinguish between Errors.Description and Parts.Description and Problems.Description, or who would assume that all columns named Description or Name are drawn from the same holy well?

That said, I don't use generic terms such as Number or ID for primary key columns, for a very different reason: the column needs a new name where it appears as a foreign key.

Suppose error numbers had to be recorded in, say, the Actions table. Actions.Number can't possibly refer to an error number, so we're forced to invent something like Actions.ErrorNumber. If it's going to be ErrorNumber everywhere else, it might as well have the same name where it serves as the key!

于 2009-06-05T05:39:09.997 回答