4 ms·

Glad that doesn't happen any where else!

• nightpool 3y ago
  Most other programming languages are more composable than a SQL query. You can make functions, split logic into different classes, extract common logic, etc. Much harder with big sql queries
  • ako 3y ago
    Use views and stored procedures if you need composability.
    • FridgeSeal 3y ago
      Counterpoint: don’t do this. The path to hell is paved with good intentions. Some co-workers and I inherited a code-base where the authors went down the views and stored procedures route. It was basicallly impossible to untangle; there was no knowing what relied on a view or a proc, so you couldn’t touch them at all, there were no docs, there were duplicates of everything (and again, no way to know what’s used). A good number of them had all kinds of side effects and weird performance characteristics. They weren’t version controlled. The issues just kept going.
      • whstl 3y ago
        If your colleagues are not applying basic engineering rules to views and stored procedures, it's not fair to say that this is a problem with views and sprocs. They can and should most definitely be testable, documentable, trackable and version controlled. Should one also judge all backend programming by PHP standards circa 1998?
        • FridgeSeal 3y ago
          I tend to judge things by the average-worst-case that they enable and how easily things go wrong, and IME stored procs specifically, go badly real quick.
          • ttfkam 3y ago
            Data structures can be a hard part of programming. That doesn't mean folks don't chose the wrong data structures all the time in any language. An array instead of a linked list or vice versa. A dequeue instead of a set or vice versa. A binary tree instead of a B+ tree. You can't just throw column names at a DB schema and hope for the best. There's actual engineering to be done, even if many programmers refuse to admit it when interacting with a relational database engine.
      • ako 3y ago
        You're blaming the language for the bad coding practices of the developers. You can build maintainable database code, and modern SQL IDEs like Datagrip provide similar tools for SQL like you have for other languages, e.g., refactoring, dependency/usage info, versioning, etc. The downsides you mention are not inherent to SQL.
  • camgunz 3y ago
    You can define functions in all major databases
    • manicennui 3y ago
      And how many non-technical users do you know who do this?
      • ako 3y ago
        And how many non-technical users do you know that write good javascript/java/.net/etc code?
      • camgunz 3y ago
        I think SWEs think of databases only as a kind of generic persistence layer and aren't super interested in a lot of the details (more than one has said to me databases are just an implementation detail) or additional capabilities, which I think is a very limited view. Databases are essentially interpreters, just like Python or Ruby. They come with access to a multiuser persistence (etc) service or engine (super handy!) but offer all the affordances of other interpreters. In fact, plpython on PostgreSQL will just use the Python packages on your system. Do you have to read about it? Sure, just like all programming languages and platforms. But, interestingly, SQL was designed for non-technical analysts, so (to your point) it's more accessible than those others.
        • ttfkam 3y ago
          Mediocre coders fixate on algorithms. Great coders concentrate on data structures. SQL schema creation and maintenance is all about choosing the right data structures for the job at hand. If you neglect attention to your data structures, no algorithms will save you, and you really only have yourself to blame. It's a still to be learned and honed like any other.