48
devTea
6y

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

Comments
  • 5
    Wow.. what a beautiful yet fierce mood
  • 3
    @devTea Knowing what you do is overrated... Every time I take over a team or create one, they always say: we don't need SQL formation. And EVERY time they are wrong!!!
  • 3
    @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
  • 2
    @devTea consistency is also overrated!!

    PS: I get it
  • 2
    wtf is wrong with these people?
  • 2
    Sounds as if your day has gotten off to a great start
  • 7
    @err-occured @PonySlaystation these motherfucker job is “make it work” not “make it maintainable”
  • 5
    @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.
  • 3
    @bittersweet yes, people stop learning once it worked and getting comfy with it
  • 2
    @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.
  • 4
    @bittersweet mOnGo Db bEsT dB
  • 2
    @bittersweet couldn't agree more. a bad database design will make your programming complicated. It all starts with a good database design.
  • 2
    @bittersweet I love how everything seems to come back to how much people hate JS devs. Why does everyone hate me?
  • 4
    @nathanasius here’s a cookie 🍪
  • 3
    @nathanasius I don’t hate js, I hate *most* of the devs
  • 2
    @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.
  • 1
    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
  • 2
    @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.
  • 1
    @bittersweet It has nothing to do with the programming language, the DB, the OS, etc... Every language is a fucking nightmare if the dev doesn't think! And that's the main problem: people don't think any more!!! They are fucking lazy motherfuckers who want it easy!!! It's suppose to be difficult! When you have programmers (doesn't matter the language) who doesn't know how the fuck do a computer to work, it's the start of the problems. I know a lot of none JS/PHP developpers who never design!! Who doesn't know how a fucking sql db work, how their own fucking compiler work!!!!

    Every program is a system, and the important part in a system IS THE FUCKING SYSTEM!!!! Not the db, not the coding , not the deploying, etc... Everything is important.

    If you don't know why your are doing what you are doing the way your are doing it, stop doing it!!
Add Comment