【问题标题】:Best way to store SQL in variables将 SQL 存储在变量中的最佳方法
【发布时间】:2011-08-04 12:19:48
【问题描述】:

目前我将查询放在这样的变量中。

query = @"  select top 1
                u.UserID
            from
                dbo.Users u
            where
                u.SystemUser = 1
                and u.Status = @Status";

这样做的问题是在换行时缩进会丢失,我必须自己添加。

有人知道更好的方法吗?我知道存储过程是一种可能性(消除了这个缩进问题),但我不确定它们对于纯数据检索是否一定更好。

【问题讨论】:

  • 它是否在数据检索中给你一个错误然后你在寻找这样的东西我的意思是如果你需要更好和优化的查询那么很好但是你的查询看起来没有用它应该很快并且不那么复杂。
  • @Karan 这没有给我一个错误。问题是 Visual Studio 之一。我尝试保持查询的可读性,但按 Enter 键时会丢失缩进。我正在寻找一种更好的方式来使用 ad-hoc 查询,或者解释为什么用于数据检索的存储过程是一个更好的选择。
  • 可以,但我不是项目负责人。
  • (from u in dbo.Users select u.userId where u.SystemUser == 1 && u.Status = @Status).Take(1)
  • @Eric 这比我预期的要容易得多。我还没有学习 LINQ to SQL。

标签: c# sql adhoc-queries


【解决方案1】:

忽略 TSQL 的仇恨者;了解一些 TSQL 本质上没有错!无论如何,我会通过(如果我保持你的格式,这不是我的标准 - 但是......嗯);

                // your existing code at, say, this level
                var query = @"
select top 1
      u.UserID
from
      dbo.Users u
where
      u.SystemUser = 1
      and u.Status = @Status";

                // some more code at, say, this level

通过将 TSQL 保持在左侧,任何缩进等都更容易在 IDE 中执行,但它也使 TSQL 更短,并且在查看跟踪时更易于调试,因为它并不奇怪 30-插入一些字符。在 select 之前以换行符开始也有助于保持整洁。

就我个人而言,我还发现代码缩进和 TSQL 缩进之间的脱节有助于找到 TSQL - 而 TSQL 对我来说非常重要,所以这是一件好事。并且强调我们刚刚切换了“世界”(因为缺少更好的术语)也无害。

【讨论】:

  • +1。 @" 语法在处理代码中的 SQL 时更容易处理。
【解决方案2】:

您至少应该考虑使用 LINQ。它确实有一个学习曲线,但它会给您带来编译器检查查询语法的优势。

您不会说这是否是一个网络应用程序,但如果您从用户输入(例如来自网络 url 或从浏览器发布的数据)中获得查询的任何输入,则将用户输入嵌入到字符串中在发送到查询引擎之前,也比其他执行查询的方法更容易受到 SQL 注入攻击。

使用实体框架是另一种极好的方法。我最近使用了 Code First 方法,它非常优雅。最后,存储过程也是一个很好的方法。

【讨论】:

  • 这是一个无需用户输入的 Windows 服务。查询语法检查是一个很好的优势,我会在下一个项目中尝试更深入地研究 LINQ。 (已经知道一点 LINQ,但还不够)。
  • 他正在使用绑定参数(@Status),所以他没有SQL注入的风险。
  • @Branko,是的,但该问题其他读者的主体。它仍然是查询字符串是快速编写 SQL 的最简单方法(我有时仍然自己这样做是为了快速而肮脏的解决方案)——但一般不鼓励这样做。
  • @iandotkelly,确实,在编写 SQL 时不注意可能会使您面临 SQL 注入攻击。但是,手工编写的 SQL 有其用途,不应该被忽视 - 如果使用得当,它肯定既不是“快速”(这是不好的)也不是“肮脏”(这是好的)。
  • 我在这里和@Branko 在一起;坦率地说,您的反 SQL 立场很奇怪 - 对于知道自己在做什么的人来说,还有许多优化 SQL 的方法远远超出了 LINQ 等的可能。
【解决方案3】:

首先,SQL 的格式只有在人类能够看到时才重要。

如果您真的想要保留缩进,您可以将字符串放入资源中(在资源编辑器中使用 SHIFT+ENTER 插入新行)。多亏了 Visual Studio 的魔力,访问资源变得很容易(Properties.Resources.*)。

如果您使用的是 WPF,您还可以使用 XAML 资源。

【讨论】:

  • 澄清一下,这与其说是缩进,不如说是对我自己和/或同事的易用性。
  • 如果您或您的同事只打算查看源代码,那么您已经做的就可以了。如果人们要在调试器或某种执行日志中看到 SQL,那么这是一个小问题,但以我自己的经验来说不是一个大问题!我不会担心太多。
  • @Branko:我更希望 SQL Server Profiler 中显示的 SQL 可读。
【解决方案4】:

你总是可以这样做的:

query = " select top 1"
      + "     u.UserID"
      + " from"
      + "     dbo.Users u"
      + " where"
      + "     u.SystemUser = 1"
      + "     and u.Status = @Status";

至少这样,您的 IDE 将缩进字符串,而不是 SQL。如果你这样做,你必须小心在每一行添加一个前导空格。

更好的选择是使用 LINQ:

result = (from
             u in dbo.Users
         select
             u.userId
         where
             u.SystemUser == 1 &&
             u.Status = @Status
).Take(1)

【讨论】:

  • 如果你遇到这个麻烦,你还应该添加换行符。
  • @Nate:为什么? SQL 不关心新行。它所需要的只是语句之间的空格。显然,select top 1 u.UserIDfrom ... 不起作用,而 select top 1 u.UserID from ... 会。
  • 虽然修复了缩进问题,但并没有解决这通常是创建查询的坏习惯的问题,同时涉及在最终字符串被创建之前总共创建13个字符串构造(除非编译器可以用它玩一些我不知道的技巧)
  • @iandotkelly:我希望能够进行优化。
  • @iandotkelly 不,编译器在那里只看到 1 个字符串;并重新创建查询 - TSQL 的存在时间比 LINQ 长得多。理解 TSQL 并不是“坏习惯”
【解决方案5】:

或者您可以使用不同的方式获取您的pure data
你可以使用

stored procedues
LINQ 2 SQL
Entity Framework
ADO.NET

硬编码的 sql 语法并不是最佳实践。

【讨论】:

  • 请问您有什么理由支持您的最后陈述吗?
  • “硬编码的 sql 语法是否不是最佳实践”有待商榷,与问题无关。
  • 我不同意。简单地说“X 比 Y 好”而不给出理由并不能教给任何人任何东西。
猜你喜欢
  • 2021-04-13
  • 2010-10-10
  • 1970-01-01
  • 2011-05-24
  • 2010-09-13
  • 1970-01-01
  • 1970-01-01
  • 2021-09-29
  • 2010-10-01
相关资源
最近更新 更多