Lead developer wants to put SQL statements in to records of the database for the code to execute (in Rails). This smells really bad to me, am I over reacting?

🤨that's... well it's not something I would do but, is there a purpose to be storing queries that a stored procedure wouldn't handle?

Truth be told i dont use rails but if it works it works haha

Nope

You know, that place where he wants to put code is called database (and not codebase) for reason 😌

I wouldn't do it. Just because to read this code latter, it would be necessary to open the database and understand what is happening there.

Instead, I would create these SQL statements on code itself and personalize accordingly with some DB field.

Sounds like something future selves will regret

op and @myss, it could be a legitimate solution for a legitimate need.

There's this software role of people that analyze data and generate reports or charts for the company and they are usually decent at sql.

Expecting such people to also be good at git and rails, and have them push commits and potentially mess up the code is dumb because you can just create a frontend for them and also save them tons of time

Usually these reports are one offs, so it'd pointless to versionize them.

One way to have this is to migrate your db to elastocsearch and frontend it with kibana, which does exactly that, it saves searches.

But I don't know your lead dev, he could as well be crazy and overengineering a solution.

Depends on the architecture like @jesustricks said.

Are the queries conceptually entities in your architecture? If not and this is purely for convenience or performance then absolutely don't do it!