My react code in production broke because one of my senior renamed a field in sql query to 'id' instead of invoiceid.

Your team has a problem if that made it to production.

how is the frontend not segregated from the SQL layer you have?

I don't think it's a backend problem. Most likely lack of unittests on the FE side

Wouldn't have happened with Vue 🤪

well, maybe if it was invoce_id...

@kobenz > "maybe if it was invoce_id..."

Or what our DBAs like to do, InvoiceID become's InvoiceInvoiceId (pattern of TableNameFieldName)

Why? Duh, it's industry standard.

Working on a side project, I created all the table's primary key field as ID. So all the various FK relationships would always be ID.

Sent over my design to a DBA and he flipped his lid.

"The Question table's primary key should be QuestionID, not ID!!! It's not consistent with our standard!"

As another poke, their competing design had over 50 tables (each with their own CRUD stored procs). My design had maybe 15 tables (might be more or less as the design progresses)

I argued the all the various lookup data points could be in a central table and the UI layer should be responsible for the integration points.

Not being a 'real DBA', my proposal was shot down. Does it matter I've got over 20 years experience over you? Nah, it'll be fine.

@PaperTrail that seems like a great convention. honestly, DB naming should be linted for conventions. Shit, I don't think there are any linters for that...

Young ones might be restless with great eyesight, me?

Eyesight's not even close to good and auto kicks in at 9am so for fucksakes... Shit... I'm too tired to go on already

@kobenz > "that seems like a great convention. honestly, DB naming should be linted for conventions."

IMO, it doesn't necessarily matter what the standard is, just have one and be consistent. If you want the PK to be TableNameFieldNameID, that's OK, I don't like it, but at least its a standard.

The WTFs roll around when the 'standard' changes every 3 years or so and a new DBA walks in "Look at this code...its a mess...good thing you have me to save the day!"

This round of changes are the eradication of triggers. DBAs want all data integrity/validation code in stored procs and the business+service layer.

Again, nothing wrong with that, but triggers solved some specific issues that shouldn't be assumed C# will magically fix (ex. explicit transactions)