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?
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.