.NET 工作流队列应该使用什么？
我们有一个定制的工作流程引擎和流程，可以满足我公司的许多业务需求。我几年前写的，但最近我们很多现有的项目已经迁移到使用该框架。每个人都喜欢它，但我们的 DBA 除外。通常我会忽略他们的建议，因为他们仍然认为存储过程在 2005/2008 数据库中比参数化 SQL 运行得更快，并且在检查事务日志等方面始终存在问题。
长话短说......他们不喜欢我们使用数据库表作为工作队列。它运行速度很快，并且我们有适当的事务锁等，可以使其在多个实例和线程同时查询的情况下运行。他们要求我们将其更改为其他内容......但他们不知道是什么。
他们只是疯了，我应该继续努力保持我们的数据库结构，还是我真的很喜欢使用数据库，应该使用其他东西来代替队列？
We have a custom workflow engine and process for a lot of our business needs at my company. I wrote it a few years ago, but recently a lot of our existing projects have been migrated over to use the framework. Everyone loves it but our DBAs. Usually I ignore their advice since they still believe that stored procs run faster than parameterized SQL in 2005/2008 databases and consistently have problems keeping transactional logs and such in check.
Long story short... they do not like that we use a database table for our work queue. It runs fast and we have proper transactional locks and such to keep it running with with multiple instances and threads all querying it at the same time. They are asking we change it to something else... but they have no idea what.
Are they just being crazy and I should continue to fight to keep our database structure, or am I really crazy for using a database and should be using something else instead for the queue?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我不知道我是否会说他们只是太疯狂了……但是要求你改变一些运行良好的东西而不提出替代方案似乎不太合理。无论如何，我很好奇 R-DBA 会建议什么作为存储工作流数据的替代方案。也许是平面文件系统？谁知道呢……
改变它可能会有好处。他们真的对它的实施感到担忧吗？系统是否给他们带来了问题？我知道你建议它运行得很快，一切都很顺利，但是他们有顾虑吗？也许帮助解决这些问题可以大有帮助。
我想这根本不是一个办公室间政治帮助网站，但听起来你工作场所的开发人员/数据库管理员之间存在一个更大的、首要的问题。如果是这样的话，无论对方多么不妥协，都需要一个人始终保持“大人物”的心态，并以合作的心态重新开始，才能真正解决此类问题。
I don't know if I'd say they are just being crazy... but demanding you to change something that is working well without suggesting an alternative seems less than reasonable. I would be curious what a R-DBA would suggest as an alternative to storing workflow data, anyway. Maybe a flat file system? Who knows...
There may be merits to changing it. Do they actually have concerns about it as implemented? Is the system causing them problems? I know you suggest that it runs fast and everything is going well, but do they have concerns? Perhaps helping to address those could go a long way toward helping.
I guess this isn't an inter-office-politics help site at all, but it sounds like there's a larger, over-arching problem between dev/dba at your workplace. It takes someone consistently being the 'bigger person' and starting over with cooperation in mind, no matter how intransigent the other side is, to really fix that sort of thing, if so.