更新

Question

假设您的查找表具有业务逻辑层所依赖的几个默认选项，但您希望允许用户在该表中添加/更新/删除记录。例如，将使用以下内容预先填充的CurrentStatus表，但允许用户更新这些记录的文本以及添加/更新/删除额外记录：

ID  | StatusName
-------------
1   | New
2   | Inactive
... | ...

可以采取哪些方法来实现这种灵活性？我不想对预先填充的记录进行“硬编码”，因为用户可能希望在路上重新定义它。主要是查看SQL Server，但理想情况下该方法应该与服务器无关。

Answer 1

再添加一列“AllowChange”
在桌面上添加INSTEAD OF UPDATE TRIGGER以拦截行动。
阅读AllowChange列并相应地更新或丢弃记录。

INSTEAD OF UPDATE TRIGGER在更新操作之前触发，因此您可以完全控制要执行的操作。

Answer 2

这种类型的权限逻辑无法使用ms sql server实现，更不用说通用的rdbms了。必须在应用程序级别强制执行此类逻辑。

你可能会使用触发器作为一种威慑，但这只会防止意外更改。

更新

SQL 2014/2016现在具有行级安全功能：

https://azure.microsoft.com/en-us/blog/row-level-security-for-sql-database-is-generally-available/

https://channel9.msdn.com/Shows/Data-Exposed/Row-Level-Security-Updates

Answer 3

最简单的方法是对该表的所有写入执行存储过程 - 您可以在存储过程的逻辑中强制执行限制。您可以授予存储过程与基础表的不同权限，以便应用程序的用户只能通过sproc进行更改。见http://www.sommarskog.se/grantperm.html

你也可以创建一个视图并通过视图进行写操作，虽然我之前从未尝试过这种方法，所以它可能无效。

触发器也可以起作用，虽然触发器往往会给应用程序带来额外的复杂性 - 所以我通常喜欢避免它们。

任何这些解决方案的核心要素都是没有什么是万无一失的 - 拥有足够权限的坚定用户可以改变他想要的东西。但只要您可以将应用程序限制为特定用户（或一组用户），并且您可以信任您的高权限用户不会使用即席查询来解决问题，那么您可能没问题。

当然，您还需要更改架构，以便在您选择强制执行限制时，您的代码可以知道要限制的行。其他答案中推荐的“附加列”或“附加表”方法是此附加模式的两个明智选项。对于我来说，“附加表”方法在理论上似乎是最干净的，但可能会导致次优查询计划，因为每个查询都需要跨越两者的UNION。这是你在使用之前要测试的那种东西。

Answer 4

向表中添加一个名为“只读”的字段，并在应用程序中进行检查。不允许在“只读”字段上进行更新/删除。可以轻松添加新字段。简短而又简单。

Answer 5

一些选项 - 您可以在存储过程中包含Insert / Update / Delete，它会检查您不希望用户覆盖的“特殊”值。针对您的查找表的所有编辑都必须通过您的存储过程。

另一种选择是向表中添加一个列，将其称为“标准”并使其成为是/否标志。如果为是（表示您不希望用户更改标准项目），则可以轻松禁止更新或删除。如果为否（表示它是用户创建的值），则可以允许编辑通过。这使您能够定义数据，而无需对项目ID的任何特殊硬编码。

允许用户更新表中的某些记录，但不是全部？

5 个答案:

更新