3

~2020
Us: "We should switch from user-defined table types to JSON for stored procedure parameters. Its too much hassle to make database changes when we need to add or remove fields."
DBAs: "JSON is just a varchar and not structured. We can just keep adding number suffixes to the type name. See, Invoice15 works just fine."

~2022
Us: "Specifications changed, here are the fields we'll need to update .."
<4 hours later>
DBAs: "You developers need to make up your mind on what fields you need updated. My team doesn't have time to keep creating new user-defined table types and updating all the corresponding stored procedures."
Us: "Why not use JSON? That way the schema binding really falls on us to keep everything in sync. New fields or removing them would be easier, faster, and safer on a case-by-case basis."
DBAs: "NO! JSON is just a varchar and too slow for mass updates!"
Us: "We haven't needed mass updating since moving the data notification pushes to Service Bus almost 10 years ago."
DBAs: "JSON in SQL Server is still too slow, unsecure, and hard-coding field names in string is not best practice!"

~2024
DBAs: "We're only using JSON for this one stored procedure. Its going to be up to you guys to keep the your schemas up to date and be prepared to constantly make changes. We may not support JSON if this doesn't work."

2026: <more than 80% of the stored procs use JSON to pass in parameters>
Us: "Specifications changed, here are the fields we'll need to update .."
<30 seconds later>
DBAs: "Done. Fields ready to go in the JSON schema. If you need to add or remove fields, just let us know. Dealing with JSON is sooo much easier now."

Comments
  • 0
    things is you end up with a DSL

    and at any rate changing fields is job security well deserved
  • 0
    How about using a document based db instead?
Add Comment