6 ms·

Imagine SQL databases worked exactly like they do now under the hood, but instead of current SELECT/UPDATE/INSERT/DELETE they used like 15 different commands wi

by ajuc 6y ago

Imagine SQL databases worked exactly like they do now under the hood, but instead of current SELECT/UPDATE/INSERT/DELETE they used like 15 different commands with at least 4 switches each. So instead of SELECT you'd have FETCH, PULL, CHECKOUT, CLONE, READ, PEEK, and OBSERVE. And each of them could in some cases also modify or even delete the data depending on the switches. Imagine there was no division between DML and DDL - you just have to remember which option switches change the schema in addition to doing some other things. And then people would say "SQL is very simple, just learn relational algebra". That's how I feel about git :) With SQL I know for sure I can't break the database by doing a select. I know I can't change schema by doing a DML. With git I'm pretty sure I can't break anything by doing git status, but other than that all bets are off.

drran 6y ago
In distributed databases, with support for merges and conflict resolution, we have these commands. :-/
thrwyoilarticle 6y ago
Imagine if SQL databases had reflog.
- tremon 6y ago
  https://en.wikipedia.org/wiki/Temporal_database https://en.wikipedia.org/wiki/Temporal_database
  - yencabulator 6y ago
    You're still imagining a centralized solution with a single source of truth and less power than Git. Git history is a directed acyclic graph, not a single linear timeline.
    - refset 6y ago
      "less power" definitely depends on what you value when comparing Git against real databases, e.g. https://stackoverflow.com/questions/984707/what-are-the-file-limits-in-git-number-and-size https://stackoverflow.com/questions/984707/what-are-the-file... There is at least one database that exists which does support a Git-like DAG for transaction-time temporality: https://terminusdb.com/ https://terminusdb.com/ It should also be pointed out that "temporal databases" usually offer a lot more besides a linear transaction-time history. Although I've not seen anything that offers a DAG for valid-time histories yet :)
rusk 6y ago
SQL presents an static picture. It doesn't really provide a way for you to manage and integrate several different views of the world or provide a means to retrieve the history of all changes you have made throughout all of history. In your list of shout commands I don't see anything that could be used for merging? I guess the "language" of git could be tweaked to make it more consistent, but otherwise the problems it is trying to solve are more complex than what could be dealt with in a SQL dialect.
- ajuc 6y ago
  > It doesn't really provide a way for you to manage and integrate several different views of the world or provide a means to retrieve the history of all changes you have made throughout all of history. select ... as of timestamp; > In your list of shout commands I don't see anything that could be used for merging? I'm not arguing for using SQL as a git interface, I'm just saying git would greatly benefit from better interface based on some consistent and clear separation of concerns. > the problems it is trying to solve are more complex than what could be dealt with in a SQL dialect. It's not. SQL simplified A LOT of underlying details. There are dozens of types of indexes. There's partitioning and sharding. There's online backups. There are transactions - local and distributed ones. There's savepoints and rollbacks. If SQL databases were like GIT - selects with joins using different indexes would have different syntax because "you need to understand the underlying structure" :)
  - rusk 6y ago
    Perhaps what's needed is an ISO committee to standardise git, or even version control semantics in general, similar to C, and in particular SQL. Once everybody agrees on how it should look, the community can swallow the pain of migration safe in the knowledge that new possibilities are unlocked. Based on how SQL and C/C++ faired in these kinds of processes we could have a standard abstraction layer in perhaps 10-15 years ...

by ajuc 6y ago

drran 6y ago

In distributed databases, with support for merges and conflict resolution, we have these commands. :-/

thrwyoilarticle 6y ago

Imagine if SQL databases had reflog.

tremon 6y ago
https://en.wikipedia.org/wiki/Temporal_database https://en.wikipedia.org/wiki/Temporal_database
- yencabulator 6y ago
  You're still imagining a centralized solution with a single source of truth and less power than Git. Git history is a directed acyclic graph, not a single linear timeline.
  - refset 6y ago
    "less power" definitely depends on what you value when comparing Git against real databases, e.g. https://stackoverflow.com/questions/984707/what-are-the-file-limits-in-git-number-and-size https://stackoverflow.com/questions/984707/what-are-the-file... There is at least one database that exists which does support a Git-like DAG for transaction-time temporality: https://terminusdb.com/ https://terminusdb.com/ It should also be pointed out that "temporal databases" usually offer a lot more besides a linear transaction-time history. Although I've not seen anything that offers a DAG for valid-time histories yet :)

rusk 6y ago

SQL presents an static picture. It doesn't really provide a way for you to manage and integrate several different views of the world or provide a means to retrieve the history of all changes you have made throughout all of history. In your list of shout commands I don't see anything that could be used for merging? I guess the "language" of git could be tweaked to make it more consistent, but otherwise the problems it is trying to solve are more complex than what could be dealt with in a SQL dialect.

ajuc 6y ago
> It doesn't really provide a way for you to manage and integrate several different views of the world or provide a means to retrieve the history of all changes you have made throughout all of history. select ... as of timestamp; > In your list of shout commands I don't see anything that could be used for merging? I'm not arguing for using SQL as a git interface, I'm just saying git would greatly benefit from better interface based on some consistent and clear separation of concerns. > the problems it is trying to solve are more complex than what could be dealt with in a SQL dialect. It's not. SQL simplified A LOT of underlying details. There are dozens of types of indexes. There's partitioning and sharding. There's online backups. There are transactions - local and distributed ones. There's savepoints and rollbacks. If SQL databases were like GIT - selects with joins using different indexes would have different syntax because "you need to understand the underlying structure" :)
- rusk 6y ago
  Perhaps what's needed is an ISO committee to standardise git, or even version control semantics in general, similar to C, and in particular SQL. Once everybody agrees on how it should look, the community can swallow the pain of migration safe in the knowledge that new possibilities are unlocked. Based on how SQL and C/C++ faired in these kinds of processes we could have a standard abstraction layer in perhaps 10-15 years ...