允许用户在应用程序中嵌入原始 SQL 查询是一个好的做法吗？

Question

允许用户在应用程序中嵌入原始 SQL 查询是一个好的做法吗？

3

我尽力想出一个合适的标题，如果不太合理请谅解。我希望在下面更好地解释。我们有一个基于.Net框架并使用SQL作为数据存储的应用程序。与任何应用程序一样，这个应用程序需要支持可扩展性，例如支持附加数据转换和验证。

举个例子：将该应用程序视为一种工具，它提供了一组输入表，用户可以使用访问或Excel导入数据（已经有UI和网格），以允许数据导入。一旦导入数据，该工具会创建一个中间模型，并对输入数据执行一些计算，然后以预定义的格式输出结果。输入表模式和中间模型模式是固定的，不会发生变化。可扩展性是在从输入数据派生中间模型阶段需要的。允许用户能够更改数据派生的方式，例如，允许按多个字段分组而不仅仅是按一个字段分组等。

为了支持这种灵活性，我认为有两种基本方法：

选项1：创建一个映射到SQL数据模型的业务模型，并向用户公开业务模型，以允许他们覆盖转换和创建新的转换（例如使用LINQ或纯C#）。

选项2：公开整个SQL数据模型，并允许用户嵌入原始SQL查询来执行转换和验证。

我的个人偏好是使用选项1，因为我不太喜欢允许用户直接操作底层数据表。我更喜欢更受控制的访问方式。然而，这种方法需要用户具备编程语言（C#或VB）的知识。另一方面，选项2可能只需要了解SQL编程的人来创建原始查询，并将其直接插入应用程序中。但是，我认为这是一种不好的方法。

产品管理团队倾向于选择选项2，因为他们认为它更灵活，并且从资源角度来看更容易实现。

因此，我正在努力找出两种方法的优缺点，以更好地支持我对选项1的倾向。基本上，我倾向于使用C#或VB .net编程语言进行工作，而不仅仅是使用纯SQL查询。

请分享您的想法和意见。

- user320587

4

你的意思是允许用户嵌入查询语句，比如 DROP TABLE Students; 吗？ - Bob Kaufman

6

哦，小博比·泰布尔斯！ - Gromer

@BobKaufman 主要是CREATE TABLES，SELECT INTO，UPDATE等操作。更好地解释一下，假设有表A和B。允许用户从表A查询数据并插入到表B中。 - user320587

@Bobson在帖子中添加了一个例子。 - user320587

@user320587 - 已编辑。看看你觉得怎么样。 - Bobson

显示剩余2条评论

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Bobson · Accepted Answer

没有一个选项是好的。

最终用户理论上精通业务逻辑 - 他们不应该需要精通编程语言才能完成工作。

你应该创建一个使用标准控件（组合框、文本输入、网格等）进行扩展的框架。如果没有具体的可扩展性需求，很难给出具体建议，但我会举一个我的项目的例子：

我们的用户需要一种方法来向产品添加任意标签，以便在我们的网站上进行过滤。我们创建了一个数据网格，用户可以在其中输入类型名称，指定它是“真/假”、整数、小数或列表中的值，然后设置所述列表的项目。然后，在每个产品上，他们将呈现所有适用类型的列表，并需要填写值 - “真/假”生成复选框，整数和小数生成验证的文本字段，列表生成包含所有指定选项的组合框。每当他们想要一个新属性时，他们可以自己添加它，但他们根本不需要考虑这些属性如何工作，因为网站是基于类型运作的。

好的，根据您的示例，我建议如下：

提供一个表单，列出数据的每个列，并在其旁边放置一个组合框，以指定要执行的操作。可以从列表中选择操作，其中包括：

- 忽略数据 - 使用数据原样 - 格式化数据 - 在其他地方查找值 - 执行计算

根据用户在此下拉列表中的选择，您将：

- 不包括该列在输出中 - 使用数据原样。 - 提供一个按钮打开一个表单，他们可以在其中格式化数据（可能使用String.Format选项的子集），基于数据类型。您将在底部显示一个键，以显示支持的值。 - 提供一个按钮来指定“其他地方”。这可能是可扩展性最有用的地方，因此我将在下面再次解释。 - 提供一种输入适当计算的方法。

至于“其他地方”查找，这可能主要是值和字符串的列表以及用于转换的字符串。这些值可以在应用程序的配置部分中指定，并存储在某个表中。您可以创建任意分组来表示各种“选项”列表。或者，您可以列出一些现有的数据表，您希望用户引用它们，并让他们指定一个转换（使用计算屏幕）将其值转换为对其他表的查找。

这有意义吗？