已经有很多答案了,但我想添加两个我在上面没有看到的主要内容:
很多时候,客户或用户甚至另一个部门的开发人员遇到了障碍,并联系我们说他们在进行操作时遇到了问题。我们问他们有什么问题。现在,他们在屏幕上看到的数据,例如带有客户姓名、订单数量、目的地等的网格是许多表格的集合。他们说他们在使用 id 83 时遇到了问题。没有办法知道那是什么 id,它是哪个表,如果它只是被称为“id”。
即,一行数据没有给出任何指示它来自哪个表。除非您碰巧很了解数据库的架构,在复杂系统或您被告知接管的非新建系统中很少出现这种情况,否则即使您有更多数据,您也不知道 id=83 意味着什么例如姓名、地址等(甚至可能不在同一张表中!)。
此 id 可能来自网格,也可能来自 API 中的错误,或者将错误消息转储到屏幕或日志文件的错误查询。
通常,开发人员只是将“ID”转储到列中而忘记了它,并且数据库通常有许多类似的表,例如 Invoice、InvoiceGrouping、InvoicePlan,并且 ID 可能适用于其中的任何一个。沮丧的是,您查看代码以查看它是哪一个,并看到他们在模型上也将其称为 Id,因此您必须深入研究该页面的模型是如何构建的。我无法计算我必须这样做多少次才能弄清楚 Id 是什么。很多。有时您还必须挖掘一个仅返回“Id”作为标题的 SPROC。恶梦。
SQL 通常会给出非常糟糕的错误消息。“无法插入 ID 为 83 的项目,列将被截断”或类似的东西很难调试。通常错误消息不是很有帮助,但通常错误消息会通过仅转储主键名称和值来模糊地尝试告诉您哪些记录被破坏了。如果它是“ID”,那么它根本没有帮助。
这只是我觉得其他答案中没有提到的两件事。
I also think that a lot of comments are 'if you program in X way then this isn't an issue', and I think the points above (and other points on this question) are valid specifically because of the way people program and because they don't have the time, energy, budget and foresight to program in perfect logging and error handling or change engrained habits of quick SQL and code writing.