将条件合并到一处
有两个函数：一个返回具有特定任务的工作人员的记录，另一个返回特定工作人员的任务。这两个函数的游标在 WHERE 子句中具有相同的条件。
我的问题是，如何在一个地方定义这些条件？那么我的代码就不会违反DRY原则。
提前致谢！
PS：我不想使用参考游标，因为它们不可靠。
There are two functions: one returns records of workers who have certain tasks to work with and the other one returns the tasks for a particular worker. These two functions have cursors with the same conditions in the WHERE clause.
My question is, how can I define these conditions in a single place? Then my code won't break DRY principle.
Thanks in advance!
P.S.: I wouldn't like to use REF CURSORS because they are unreliable.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我认为
DRY（不要重复自己）的一个明智的经验法则是三角测量：如果相同的逻辑存在于三个地方，那么值得将其提取到自己的模块中。但如果它只存在于两个地方，请不要担心。然而，你并没有真正重复自己，不是吗？您所拥有的是两个不同的查询，返回两个不同的结果集（一个是 WORKERS，另一个是 TASKS），它们恰好有一些共同的 WHERE 子句。这不是正确的重复。
如果您尝试根除两行代码执行相同操作的所有单个实例，您最终会得到一个非常不可读且无法维护的程序。请记住，DRY 是由 Andy Hunt 和 Dave Thomas 制定的，他们称自己为务实程序员很好的理由：明智地应用原则并理解为什么要这样做，而不是盲目遵循教条。
I think a sensible rule of thumb with
DRY(Don't repeat yourself) is triangulation: if the same logic exists in three places it is worth the effort of extracting it into its own module. But don't bother if it only exists in two places.However, you aren't really repeating yourself, are you? What you have is two different queries returning two different resultsets (one is WORKERS the other is TASKS) which just happen to have some bits of their WHERE clauses in common. That's not proper repetition.
If you try to root out everything single instance where two lines of code do the same thing you will end up with a horribly unreadable and unmaintainable programs. Remember that DRY was formulated by Andy Hunt and Dave Thomas, who call themselves Pragmatic Programmers for a very good reason: apply the principle sensibly and understand why you're doing it, rather than blindly following dogma.
针对您对 REF CURSOR 的保留，您为什么认为它们不可靠？我和他们之间从来没有遇到过任何问题。使用动态 SQL 填充引用游标很可能会让您感到悲伤。但这是尝试删除虚构重复的功能，与游标变量的使用无关。
Addressing your reservations about REF CURSORs, why do you think they are unreliable? I've never had any problems with them. What might well give you grief is using dynamic SQL to populate ref cursors. But that's a function of trying to remove imaginary duplication, and is nothing to do with the use of cursor variables as such.