So you have multiple software projects with similar problem domains. You have been using stored procedures for long enough that you copy all of them over multiple projects to save the occasionally exorbitant amount of time it took to write and debug just one.
Perhaps you rename those you don’t need, to provide reference in case you need them again because you don’t use version control. Perhaps you see their use as encouraging good database design. Perhaps they are promoting a development approach which is familiar to you and therefore simplifies working with your existing code. Perhaps you are even copying the entire database structure along with it. This is ALL bad practice.
Who cares about adding unnecessary complexity. It’s worth it, because the way we designed the first one can’t have much room for improvement because we made all that money…right? After a few weeks of consideration I have come up with a few choices. This is how to cope with an organisational dependence on SQL stored procedures.
1. Keep them, let an object relational manager deal with them. Something lightweight maybe. A micro ORM like Dapper or Massive. Let it create objects out of the procedure result, and get real scalable reuse out of the data layer.
2. Start training, develop the SQL skills into a more powerful technology EF, nH or SS. But everyone knows what comes with great power…
3. Try to ignore anything that could make life easier or people more productive. Put your fingers in your ears and tell yourself its all worth it for the performance gains.
4. Use them as weapons to batter the confidence of those unfamiliar with your unintuitive and secret coding conventions.and practices.
5. Pretend it is all a terrible nightmare and you will wake up soon.
6. Use them as a justification against multiple developers working on the same code base.
7. Stop learning, stop growing, start writing the first T-SQL edition of the holy bible or start worshipping the sacred T-SQL cow.
I still don’t know.
Edit: I think I might be getting there.