2015-12-15 31 views

回答

0

在我的日常工作中,例如,我使用sp来检索,存储,更新和删除记录,我大多数时间从Web应用程序执行这些sps,但有时候某些sp需要一些sp复杂或重复的操作,然后我使用一个函数来重用该操作(如果需要的话)或在我的sp中留下更干净的代码。

我们通常不使用视图,但为简单起见,您可以使用它们,如果您只是调用视图,则不需要使用连接进行相同的长选择命令。

这是我的经验,为我的英语:)。

0

在我看来,使用SPs来读取数据是一种非常不好的习惯。

您一定要分清

  • 之间

      SP:批处理,通常多的语句,你被允许这样做(几乎)一切。最大的缺陷是,你无法轻易地继续使用SP结果,如果你想在进一步的查询中使用SP返回,你总是必须将它写入正确声明的表(实数,温度或变量)。这可能是很多容易出错的输入。此外,优化器将 而不是能够处理这个高性能。 TV-UDF(表值用户定义函数):必须意识到存在两种风格的事实:单语句(ad-hoc)或多语句。第一个是好的,第二个(在几乎所有情况下)非常糟糕! VIEW的一个优点是,该参数及其处理是预编译的。

    • 查看:这和特设的TV-UDF一样好。您可以用模式声明它绑定和处理它几乎一样,如果它是一个表(索引等)...

    Fazit:使用SP可获得UPDATE,DELETE,任何类型的数据或结构操纵但而不是单读。

  • +0

    为什么使用SP读取数据是一个非常不好的习惯? – zedfoxus

    +0

    正如我在答案中写到的,最大的缺陷是在执行**之后使用resultset **。 TV-UDF的返回可以像SELECT * FROM dbo.MyFunction(@ prm1,@ prm2)那样简单,或者可以直接在JOIN或APPLY中使用。这将**从未**与SP一起工作。其次,内联呼叫总是在性能上更好。有一些非常罕见的情况(例如,您必须使用动态SQL),当SP有利于读取数据时。 – Shnugo

    +0

    了解。我对此有不同的看法。当多个应用程序(C#,Java等)正在调用本地检索信息和处理信息时,我很欣赏使用通用SP检索数据,而不是编写参数化SQL语句的应用程序。 SP中复杂的基于光标的业务逻辑也帮助了我。所以我的感觉是,通过SP的CRUD有它的位置;正如你提到的那样,UDF也有它的位置。 – zedfoxus

    相关问题