Fucking hell, the devs before write a query that pulls 30ish column for a report. When I break it down MANUALLY, since it’s a spaghetti on top of another spaghetti, you only need 6. Fuck you, did you dropped your head when you was a kid? Fuck sake, and every query is written in stored procedure even though you’re using an entity libraries

Wow.. what a beautiful yet fierce mood

@jotamontecino I’m not creating this from ground, this is an old project and some parts are using LINQ, and some are using normal SQL, just make up your mind shit heads

Edit: I’m not refererring this to you btw

wtf is wrong with these people?

Sounds as if your day has gotten off to a great start

@err-occured @PonySlaystation these motherfucker job is “make it work” not “make it maintainable”

@devTea

As a DBA I'm baffled by this trend of not caring about databases. "Let's just store everything as json", "We always use select * because it's easy", "We store everything in one table because we're scared of joins" 😫

On some level I understand that people don't like having to learn another language.

But so many bugs are caused by bad database design, so many performance problems by bad queries... Solving data integrity problems at the database level is such a great way of avoiding way more complicated issues in all other layers.

@bittersweet yes, people stop learning once it worked and getting comfy with it

@devTea I think it's mostly because of lazy fullstack JS devs being salty that they need to learn more, so they started this crusade against relational databases. And now management believes that databases are kind of a side thing, that any and all conscious thought about technical design in the persistence layer can be replaced by nosql databases and/or generic ORMs.

@bittersweet mOnGo Db bEsT dB

@bittersweet couldn't agree more. a bad database design will make your programming complicated. It all starts with a good database design.

@bittersweet I love how everything seems to come back to how much people hate JS devs. Why does everyone hate me?

@nathanasius here’s a cookie 🍪

@nathanasius I don’t hate js, I hate *most* of the devs

@nathanasius I hate JS devs who want to reduce everything to JS code and json, even if it requires force.

It's such a great swiss army knife, but that doesn't mean you don't need any other tooling.

I could never hate you though, because 10th = best doctor.

I'm not a web dev and have no experience to know better, but are stored procedures a no-no? I would have thought it's preferable since
a) increased performance as they are pre-compiled
b) makes your web app portable because database agnostic
c) eliminate (or maybe only reduces?) SQL injection
d) I'm sure there are more

@LrdShaper With code in the backend, your backend is less portable, with code in the database, your database is less portable.

There are some arguments in favor of database procedures and some against it.

Biggest arguments against it are lack of testing options, lack of transparency for backend devs, and version control & deploying options are less good.

I design databases to perform well using the right amount of normalization and indexes, and set up tables is such a way that data integrity is guaranteed through foreign key constraints.

That's all.

I tend to use triggers & stored procedures only in special cases: For monitoring, database masking, sometimes for seeding with staging/test data, adding extra integrity checks, sometimes for special fun cleanup queries like "select iban where isValidIBAN(iban)"

But my personal rule of thumb is to set up the DB in such a way that none of the stored procs are essential to the functionality -- they're just some extra tools for the DBA.