4 ms·

> - it's insecure (update anything, anywhere! just need to get by check constraints) It's entirely possible to add permissions and access control on any modern

> - it's insecure (update anything, anywhere! just need to get by check constraints) It's entirely possible to add permissions and access control on any modern dbms. > - it's slow (table scans, when I meant to use index) Maybe you are using an OLTP when you meant to use an OLAP dbms? > - it's bad for horizontal scaling (things like sharding fundamentally relies on shrinking the domain of access patterns). See above. SQL is more adequate as a "language" or "standard" because that's what it is. What matters is that the underlying dbms that offers this functionality is appropriate.

PartiallyTyped 3y ago
Sorry, grammar correction, meant to say: SQL is more than adequate as a "language" or a "standard".
Ericson2314 3y ago
> It's entirely possible to add permissions and access control on any modern dbms. My understanding is this is all mandatory access control which is cumbersome as usual. > Maybe you are using an OLTP when you meant to use an OLAP dbms? "It's slow" was too pithy. When it's fast it great, but it's too easy to write things that are slow my mistake. I want things to be rejected if it they don't use an index in many cases, not fall back on a slow table scan. The most key part is that I posit that the "when are table scans allowed?" policy is very similar to the security policy.
- dventimi 3y ago
  "cumbersome" is a matter of judgement. As for table scans, again as I've written elsewhere here, statement timeouts will put an end to those [concerns].
  - Ericson2314 3y ago
    I don't disagree with that. I want something better. The dream I have is that if one carefully writes a schema (in a whitelist, not blacklist manner), all the information is there to make: 1. Exposing the database to the public safe. 2. Automatically know how to scale out if more machines are added. 3. Easier to understand cost of operations from the syntax alone, without needing to consult the query planer. This is very exciting to me!
    - dventimi 3y ago
      That's fair. You do "you", I'll do "me", and we'll both have a very merry [seasonal holiday of togetherness of your choice]. So long as we're saying what we want in the way of gifts, here's what I want. What I want is to push the envelope of what can be done with SQL well past what should be done, not as a practical matter but as a theoretical one. In my view, accumulated received wisdom causes people to err too far in the other direction. They stop well short of what can be done practically with just SQL, out of an outsized an unexamined fear of what shouldn't be done in SQL. I don't literally want just a SQL user interface to my applications, but I like to imagine if I did, think about the potential problems, then try to be resourceful in solving those problems right within SQL before giving up and resorting to other tools. I believe you can go very far with this approach, maybe not all the way, but farther than people tend to give SQL credit for. At the end of the day, I still need something else in addition to SQL, but the "something else" turns out to be smaller and less involved than it would have been had I been governed by the accumulated received wisdom.

PartiallyTyped 3y ago

Sorry, grammar correction, meant to say: SQL is more than adequate as a "language" or a "standard".

Ericson2314 3y ago

> It's entirely possible to add permissions and access control on any modern dbms. My understanding is this is all mandatory access control which is cumbersome as usual. > Maybe you are using an OLTP when you meant to use an OLAP dbms? "It's slow" was too pithy. When it's fast it great, but it's too easy to write things that are slow my mistake. I want things to be rejected if it they don't use an index in many cases, not fall back on a slow table scan. The most key part is that I posit that the "when are table scans allowed?" policy is very similar to the security policy.

dventimi 3y ago
"cumbersome" is a matter of judgement. As for table scans, again as I've written elsewhere here, statement timeouts will put an end to those [concerns].
- Ericson2314 3y ago
  I don't disagree with that. I want something better. The dream I have is that if one carefully writes a schema (in a whitelist, not blacklist manner), all the information is there to make: 1. Exposing the database to the public safe. 2. Automatically know how to scale out if more machines are added. 3. Easier to understand cost of operations from the syntax alone, without needing to consult the query planer. This is very exciting to me!
  - dventimi 3y ago
    That's fair. You do "you", I'll do "me", and we'll both have a very merry [seasonal holiday of togetherness of your choice]. So long as we're saying what we want in the way of gifts, here's what I want. What I want is to push the envelope of what can be done with SQL well past what should be done, not as a practical matter but as a theoretical one. In my view, accumulated received wisdom causes people to err too far in the other direction. They stop well short of what can be done practically with just SQL, out of an outsized an unexamined fear of what shouldn't be done in SQL. I don't literally want just a SQL user interface to my applications, but I like to imagine if I did, think about the potential problems, then try to be resourceful in solving those problems right within SQL before giving up and resorting to other tools. I believe you can go very far with this approach, maybe not all the way, but farther than people tend to give SQL credit for. At the end of the day, I still need something else in addition to SQL, but the "something else" turns out to be smaller and less involved than it would have been had I been governed by the accumulated received wisdom.