3

我从初学者开始重新审视了我的一些代码，发现一些 SQL 表的列名是如此模棱两可，让我感到畏缩。

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

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

我问是因为你可以像这样使用别名SELECT：

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

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

4

2 回答 2

3

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

代码

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

优点

  • 为未来的数据库重构提供抽象。
  • 可以提供改进和可重用性。
  • 减少任何 SQL 注入攻击。

缺点

  • 重新编写代码库需要付出很多努力和风险，但您可以通过零碎的方法来完成。
  • 不适用于每种类型的应用程序/服务（EG、报告）。

存储过程

根据您的 RDBMS，您可以使用存储过程为底层数据和模式提供抽象和额外的安全性。

优点

  • 更多代码需要维护。
  • 不容易测试，尽管取决于您的 RDBMS，有很多数据库测试框架应该包括 SP 覆盖率。
  • 假设您没有在存储过程中构建任何动态 SQL，则提高了数据安全性并降低了 SQL 注入攻击的风险。

缺点

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

意见

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

优点

  • 为您的选择语句提供一些抽象列别名。
  • 可以快速且相对容易地完成。
  • 如果使用模式绑定/索引视图，可能会提供改进。

缺点

  • 仅限于选择语句。
  • 发展起来可能会令人困惑。
  • 不关闭任何针对 SQL 注入攻击的安全性。
  • 更多代码需要维护。

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

优点

  • 可以为插入数据提供抽象。

缺点

  • 可能是提供抽象的风险最大的选择。
  • 仅适用于插入语句。
  • 使用直接内联 SQL 时仍然容易受到注入攻击。
  • 您的数据类型可能不支持触发器。
  • 更多代码需要维护。
  • 由于“隐藏”的性质，触发器很难调试并且经常不受欢迎。
于 2013-07-27T03:44:07.727 回答
3

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

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 ( ...)
于 2013-07-27T03:48:20.097 回答