I just saw one of "those" questions. You know the ones:

'We're hitting an error with a stored procedure. What is the maximum number of parameters you can have?"

<sigh>

Look, I get it. Breaking the land speed record is cool. Getting the most people into a phone booth (look it up), also cool. Fastest, biggest, most. All cool... depending on the circumstances.

However, for a lot of technology, limits are in place for a reason. We need to acknowledge this and treat them as limits, not goals. If you are pushing the edge, or exceeding, the number of parameters in a procedure, the number of columns in a table or index, any of the other standard limitations on our various technology stacks, it's time to step back. You need to reevaluate your decisions. Chances are extremely high, you're operating under some false assumptions or you've made some poor decisions. You are, in all likelihood, deep into technical debt and you're going to have to pay that off.

So, when you start to see that you're getting near these limitations, stop digging. Don't go online and moan about how having only 2,100 parameters is hurting you. You're hurting you. Also, be thankful you're working in SQL Server where the limit is 2,100. In PostgreSQL it's 100 (again, a limit, not a goal, please). The simple fact is, many, maybe even most, of these limits are in place for two reasons. First, programming for infinite choices is just hard, so people put limits in place. Second, performance and behavior degrades as more and more things get added, so limits are put in place to prevent that. These are just some of the hard facts of life in technology.

Pretty sure, we can all deal with that. Maybe?