Question

我从初学者那里重新访问了一些代码，发现一些SQL表的列名非常模糊，让我感到畏缩。

现在如果我继续更改名称，那么纠正代码中所有映射所需的时间和精力似乎在这一点上是不合理的。

我想知道在插入数据库时是否可以提供别名？

我问，因为您可以在SELECT上使用别名：

SELECT users.id, username, number AS order_number FROM users INNER JOIN orders ON users.id = orders.user_id;

或者有没有人对如何做到这一点有任何其他建议？

Answer 1

虽然重构数据库无疑是一个很大的风险活动，但这里有一些缓解风险的技巧。以下是一些有各种利弊的建议（正如我看到的那样）希望他们会有所帮助。

<强>代码

根据您的编程语言，舒适度和时间范围，您可以使用像Hibernate / NHibernate等RDBMS独立对象关系映射器替换内联直接SQL。

赞成

为将来的数据库重构提供抽象。
可提供改进和可重复使用。
减少任何SQL注入攻击。

缺点

重新编写代码库需要付出很多努力和风险，但您可以零敲碎打地做到这一点。
不适合所有类型的应用程序/服务（E.G.，报告）。

存储过程

根据您的RDBMS，您可以使用存储过程为底层数据和架构提供抽象和附加安全性。

赞成

需要维护更多代码。
不易测试，虽然根据您的RDBMS，有大量的数据库测试框架应该包括SP覆盖。
假设您没有在存储过程中构建任何动态SQL，可以提高数据安全性并降低SQL注入攻击的风险。

缺点

可以滥用将您的数据访问与域/业务逻辑交织在一起。
您仍需要更新代码库以使用存储过程。

<强>视图

您可以将现有表Users和Orders重命名为其他内容，并使用视图提供列名抽象。

赞成

为您的select语句提供一些列别名的抽象。
可以快速且相对容易地完成。
如果使用架构绑定/索引视图，则可以提供改进。

缺点

仅限于选择陈述。
可能会混淆发展。
不会破坏任何针对SQL注入攻击的安全措施。
需要维护更多代码。

门面表 结合视图建议，您可以创建具有修订列命名和安全访问权限的外观表。将数据插入facade表时，使用触发器作为填充旧表的抽象机制。

赞成

可以提供插入数据的抽象。

缺点

可能是提供抽象的最危险的选择。
仅适用于插入声明。
使用直接内联SQL时仍然容易受到注入攻击。
您的数据类型可能不支持触发器。
需要维护更多代码。
由于“隐藏”性质，触发器很难调试并且经常不喜欢。

Answer 2

您可以将表格包装在视图中，然后在视图中插入。

create view view_nice_column_names 
as
SELECT bad_name_1 as nice_name_1, bad_name_2_as nice_name_2 FROM blabla
GO

INSERT INTO view_nice_column_names (nice_name_1, nice_name_2) VALUES ( ...)

如何重命名SQL表列名，而不是破坏东西

2 个答案: