3 ms·

Highly manual, error-prone, lack of consistency means lack of tooling support, etc. Most languages simply don't handle the scenario; most languages also didn't

by setr 7y ago

Highly manual, error-prone, lack of consistency means lack of tooling support, etc. Most languages simply don't handle the scenario; most languages also didn't handle code-testing, or building, or etc, but that hardly makes it an ideal situation. Additionally, in the case of DBs, it's strange to call it a "language"; at best it's a language with a supremely massive runtime, but more appropriately, it's a platform. And being a platform, it would be fairly reasonable and unsurprising to consider things like version control and function-versioning to be in scope, even though most DB platforms don't handle it either. But I'm also consistently surprised by how lacking the DB tooling space is compared to programming languages; eg the formatters are generally lacking/incomplete (foolishly imagining the SQL standard to be sufficient to claim support for all DBs), the general lack of any version control, the general lack of SQL transpilers (again, probably due to the misunderstanding that the standard standardizes anything; specifically the lack of a 80-90÷ OS automatic translation for MySQL -> PGSQL is astounding), the general lack of IDE support (Most can't even assist in maintaining datatypes when writing SQL, despite the all-knowing schema available to it; you basically get notepad + a pretty view of the output), etc. DBAs are willing to put up with quite a bit, and I can't figure out why. The engines themselves are phenomenal works of engineering; the usage of it is utterly pathetic

paulddraper 7y ago
> DBAs are willing to put up with quite a bit, and I can't figure out why. The engines themselves are phenomenal works of engineering; the usage of it is utterly pathetic Perhaps they don't want their programs to bloat until they can read email.
- setr 7y ago
  Enhancing management of your relational database seems to me quite in scope of your relational database management system. Whether the functionality exists as an arbitrary other program, in whatever miniscule chunk that fits your preference, or as part of an additional arbitrary SQL extension (we would all certainly love more random keywords/syntax), is unimportant. The functionality/tooling is missing, or at best, lacking, and has nothing to do with a preference for no-bloat. It simply means that we have arbitrary, adhoc implementations to enhance the management of our failing management system. That the database must be babied is not a positive, and RDBMS are meant to remedy that.
  - paulddraper 7y ago
    You are vastly overstating the perceived deficiency. PostgreSQL gives you functions, views, rules for query writing. Plus it gives you ephemeral versions of all those so you don't have manage it separately from the client code.
    - setr 7y ago
      >You are vastly overstating the perceived deficiency. How so? There is no versioning support. That's it. I'm not sure how much more deficient you can get. Anti-versioning features? >PostgreSQL gives you functions, views, rules for query writing. Right, which requires an adhoc versioning mechanism, or coupling application + DB updates. Thankfully it was at least realized versioning your data made sense (MVCC), likely a result of how often problems occur trying to manually version it in your application logic with multiple arbitrary threads (read: humans, applications) operating on it, but somehow got lost on the rest of the system (where multiple arbitrary humans, applications fiddle with it). >Plus it gives you ephemeral versions of all those so you don't have manage it separately from the client code. Moving all of your database logic into your application code is very much a poor state of affairs, and defeats much of the purpose of offering functions, views, etc in the first place. Ideally, you want them to live for more than a single transaction, and be used by multiple applications, and presumably written & maintained by your DBA, who presumably knows the database engine, and its usage patterns, better than your application developer. The ephemeral version is ideally a method of last resort (for one-off usecases); but if you want decent versioning tooling (eg git), this is your method of first resort. Application developers learned this lesson decades ago. What I've never understood about databases is that despite the massive industry, usage, and ecosystem, their tooling is still stuck in the 80's.
      - paulddraper 7y ago
        This is perhaps the most confusing comment I've ever read. > versioning your data made sense (MVCC) In PostgreSQL, functions can be created and versioned with MVCC exactly like data. > Moving all of your database logic into your application code is very much a poor state of affairs Okay, then deploy it separarely. > written & maintained by your DBA But isn't that the "ceremony" you railed so hard against? > tooling is still stuck in the 80's Rather I think you want them to do something (though I'm not exactly sure what) that most other people don't. The tooling for Apache config files is stuck in the 90s too. > Application developers learned this lesson decades ago. What lesson? Is it exactly as hard to install updates to your application, and is it to install updates to your database. Is it exactly as hard to offer a new API version from your HTTP server (/v2/) as it is from your SQL server.

by setr 7y ago

paulddraper 7y ago

> DBAs are willing to put up with quite a bit, and I can't figure out why. The engines themselves are phenomenal works of engineering; the usage of it is utterly pathetic Perhaps they don't want their programs to bloat until they can read email.

setr 7y ago
Enhancing management of your relational database seems to me quite in scope of your relational database management system. Whether the functionality exists as an arbitrary other program, in whatever miniscule chunk that fits your preference, or as part of an additional arbitrary SQL extension (we would all certainly love more random keywords/syntax), is unimportant. The functionality/tooling is missing, or at best, lacking, and has nothing to do with a preference for no-bloat. It simply means that we have arbitrary, adhoc implementations to enhance the management of our failing management system. That the database must be babied is not a positive, and RDBMS are meant to remedy that.
- paulddraper 7y ago
  You are vastly overstating the perceived deficiency. PostgreSQL gives you functions, views, rules for query writing. Plus it gives you ephemeral versions of all those so you don't have manage it separately from the client code.
  - setr 7y ago
    >You are vastly overstating the perceived deficiency. How so? There is no versioning support. That's it. I'm not sure how much more deficient you can get. Anti-versioning features? >PostgreSQL gives you functions, views, rules for query writing. Right, which requires an adhoc versioning mechanism, or coupling application + DB updates. Thankfully it was at least realized versioning your data made sense (MVCC), likely a result of how often problems occur trying to manually version it in your application logic with multiple arbitrary threads (read: humans, applications) operating on it, but somehow got lost on the rest of the system (where multiple arbitrary humans, applications fiddle with it). >Plus it gives you ephemeral versions of all those so you don't have manage it separately from the client code. Moving all of your database logic into your application code is very much a poor state of affairs, and defeats much of the purpose of offering functions, views, etc in the first place. Ideally, you want them to live for more than a single transaction, and be used by multiple applications, and presumably written & maintained by your DBA, who presumably knows the database engine, and its usage patterns, better than your application developer. The ephemeral version is ideally a method of last resort (for one-off usecases); but if you want decent versioning tooling (eg git), this is your method of first resort. Application developers learned this lesson decades ago. What I've never understood about databases is that despite the massive industry, usage, and ecosystem, their tooling is still stuck in the 80's.
    - paulddraper 7y ago
      This is perhaps the most confusing comment I've ever read. > versioning your data made sense (MVCC) In PostgreSQL, functions can be created and versioned with MVCC exactly like data. > Moving all of your database logic into your application code is very much a poor state of affairs Okay, then deploy it separarely. > written & maintained by your DBA But isn't that the "ceremony" you railed so hard against? > tooling is still stuck in the 80's Rather I think you want them to do something (though I'm not exactly sure what) that most other people don't. The tooling for Apache config files is stuck in the 90s too. > Application developers learned this lesson decades ago. What lesson? Is it exactly as hard to install updates to your application, and is it to install updates to your database. Is it exactly as hard to offer a new API version from your HTTP server (/v2/) as it is from your SQL server.