拥有一个包含同名列的 SQL 表是一种不好的编码习惯吗？

发布于 2024-07-19 04:53:51 字数 222 浏览 9 评论 0原文

示例：

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

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

SELECT ErrorNumber FROM ErrorNumber WHERE ErrorNumber=10

原文

Example:

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

This can result in queries that look like:

SELECT ErrorNumber FROM ErrorNumber WHERE ErrorNumber=10

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

幸福不弃 2024-07-26 04:53:51

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

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

我不确定的另一件事是这（列名与表名相同）是否会导致错误？我确信每个供应商的情况都会有所不同。

回复收藏 0 原文

流星番茄 2024-07-26 04:53:51

CREATE TABLE Errors (
    Number int,
    Description varchar(255)
)

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

表名现在代表它的含义
是。
这些列不需要这个词
由于表格而导致其中出现“错误”
他们进来了。

CREATE TABLE Errors (
    Number int,
    Description varchar(255)
)

I feel the above is a better naming scheme because:

The table name now represents what it
is.
The columns do not need the word
"Error" in them because of the table
they're in.

回复收藏 0 原文

梦境 2024-07-26 04:53:51

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

回复收藏 0 原文

落花随流水 2024-07-26 04:53:51

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

回复收藏 0 原文

紙鸢 2024-07-26 04:53:51

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

回复收藏 0 原文

鸩远一方 2024-07-26 04:53:51

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

CREATE TABLE ErrorCodes
(
Id int,
Number int,
Description varchar(255)
)

I agree with DWC, and would take it a step further in naming the table something a little more descriptive, as in what type of error table it is. If it is used to store errors that you will use in your code is one thing, and if its a table that logs errors is another. Not sure what you are using it for, so it's really up to you to name it something that makes sense to the context it's used for. When I see a table named "Errors" I am not sure if its a log table, or a lookup table used to find error codes. If it is the latter than perhaps something like ErrorCodes would be a good name.

CREATE TABLE ErrorCodes
(
Id int,
Number int,
Description varchar(255)
)

回复收藏 0 原文

卸妝后依然美 2024-07-26 04:53:51

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

回复收藏 0 原文

不及他 2024-07-26 04:53:51

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

我们的应用程序中有很多表，它们只有 id 和一个“名称”字段。它们用于下拉列表。

所以我这样设置它们：

列表名称是： State

表名称是： State

ID 是： StateID

实际状态值列是： StateName

它对我们有用。

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

回复收藏 0 原文

司马昭之心 2024-07-26 04:53:51

如果任何数据库供应商对此感到困惑，请使用其他数据库供应商。任何数据库都应该可以毫无问题地轻松解析它。

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

回复收藏 0 原文

你是年少的欢喜 2024-07-26 04:53:51

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

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

回复收藏 0 原文

南七夏 2024-07-26 04:53:51

如果一个表预计包含多行，那么我倾向于使用集体术语作为名称。请注意，这与采用单数并附加“s”不同，例如我更喜欢“人员”和“工资单”而不是“员工”和“员工薪水”。应取出并拍摄诸如“实体”之类的名称:)

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

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

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

SELECT pi FROM Pi;

[并且诸如此处的代码解析器也使工作变得更容易！]

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

SELECT P1.pi 
  FROM Pi AS P1;

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

因此，虽然我可以设想一个 SQL 表包含具有相同名称的列，即使采用我首选的数据元素命名约定，但这种情况确实很少发生。

If a table is expected to comprise more than one row then my preference is to use a collective term as a name. Note this is not the same as takin the singular and appending an 's' e.g. I'd prefer 'Personnel' and 'Payroll' over 'Employees' and 'EmployeesSalaries' respectively. And a name such as 'Entitys' should be taken out and shot :)

In light of this, and considering the columns in your design, I would name the table in question 'Errors'. Now, I know many coders prefer singular terms for table names but that's just a different style rather than 'poor coding practice'.

There are occasional needs for single row tables e.g. a table 'Constants' containing the shared approximation of pi to be used by applications using the DBMS... but then the 'Constants' table I have in mind has multiple columns each for a different constant so it gets a collective term as a name.

Perhaps if your applications only ever used one constant then maybe you could end up with a table called 'Pi'? Well, another style choice I've made is to use UpperCamelCase for table names and lower_case_separated_by_underscores for column names. Therefore, I still be able to distinguish (just about) the table from the column i.e.

SELECT pi FROM Pi;

[And a code parser such as the one here on SO makes the job easier too!]

Actually, I tend to use table correlation names almost exclusively so I'd be more likely to write:

SELECT P1.pi 
  FROM Pi AS P1;

Also consider that some collective terms are spelled the same as the singular term e.g. 'species', 'deer', 'sheep', 'fish' and probably many others not pertaining to the animal kingdom but I'm having a mental block just now :)

So while I can envisage a SQL table that contains a column with the same name even with my preferred data element naming convention, it would be a rare occurrence indeed.

回复收藏 0 原文