5 ms·

It's interesting the focus this article places on relational databases. The author insists that Salesforce must run on top of Oracle, or Postgres. The notion th

It's interesting the focus this article places on relational databases. The author insists that Salesforce must run on top of Oracle, or Postgres. The notion that any modern company wouldn't be using SQL somewhere in their daily process is outlandish. ...which is interesting, right? SQL won. There are no competitors. Everybody uses SQL. But if you ask developers how they develop their interfaces, you'll get a million answers, ranging from DOS terminals, Electron apps, PWAs, .NET forms, whatever. Maybe what we need is SQL for the view layer to complement the relational backend? SQL is famously easy to pick up because it allows the user to describe what they want, not how to get it. React and friends get us closer to this goal of universal reactive programming, but nothing/nobody has capitalized on providing an all-in-one "put words in this box and get what you want" type application. I guess the assumption is that building such a language is functionally impossible, but I really wonder if that's true. The app-building app that ultimately wins is going to be the one that lets you build any app, not just an app that serves a particular niche or business process.

void_mint 5y ago
> It's interesting the focus this article places on relational databases. The author insists that Salesforce must run on top of Oracle, or Postgres. The notion that any modern company wouldn't be using SQL somewhere in their daily process is outlandish. I think it's mostly that Salesforce was founded by an Oracle executive (and is just generally a bastion of enterprise software mess).
valenterry 5y ago
Isn't SQL more like the browser? Everyone uses SQL, everyone uses the browser. But the way they are used can be very different. You can also use SQL databases like a dump key-value store or with more sophistication like foreign-constraints etc.
- jasfi 5y ago
  It's closer to HTML than the browser.
bob1029 5y ago
> The app-building app that ultimately wins is going to be the one that lets you build any app, not just an app that serves a particular niche or business process. The reality is that you still have to model some specific domain against which SQL queries can be written. I 100% agree with doing implementations in SQL, but you still need imperative code wiring your well-normalized interpretation of the matrix into the outside world. That said, SQL is more powerful than most developers are aware. Using providers like SQLite allows authoring UDFs which blur the lines between code and SQL. The nastiest bits of our product are implemented by business owners in SQL now. We have written UDFs like format_date() which are simply thin wrappers for things like Datetime in C#. Developers just ensure stability of the schema/UDFs and any relevant Code-to-sql mappers. Also note the in-memory mode of operation for SQLite makes it a perfect fit for large numbers of ad-hoc projections in parallel.
goatinaboat 5y ago
The app-building app that ultimately wins is going to be the one that lets you build any app, not just an app that serves a particular niche or business process. We have those already. They're called IDEs. It turns out there's only so much complexity you can hide if you need to describe what you want to do unambiguously enough to be executed by a machine. Something like Visual Basic is probably as far as you can bury complexity while still being widely useful. Go much further and you start to drastically constrain the range of apps that can be built with your app-building-app. SQL is just the lowest-common-denominator notation for accessing and manipulating data by performing operations that can be represented by relational algebra and relational calculus. Fixating on the language itself misses the point that there is a theoretical underpinning to why data is handled this was in many practical applications.

void_mint 5y ago

> It's interesting the focus this article places on relational databases. The author insists that Salesforce must run on top of Oracle, or Postgres. The notion that any modern company wouldn't be using SQL somewhere in their daily process is outlandish. I think it's mostly that Salesforce was founded by an Oracle executive (and is just generally a bastion of enterprise software mess).

valenterry 5y ago

Isn't SQL more like the browser? Everyone uses SQL, everyone uses the browser. But the way they are used can be very different. You can also use SQL databases like a dump key-value store or with more sophistication like foreign-constraints etc.

jasfi 5y ago
It's closer to HTML than the browser.

bob1029 5y ago

> The app-building app that ultimately wins is going to be the one that lets you build any app, not just an app that serves a particular niche or business process. The reality is that you still have to model some specific domain against which SQL queries can be written. I 100% agree with doing implementations in SQL, but you still need imperative code wiring your well-normalized interpretation of the matrix into the outside world. That said, SQL is more powerful than most developers are aware. Using providers like SQLite allows authoring UDFs which blur the lines between code and SQL. The nastiest bits of our product are implemented by business owners in SQL now. We have written UDFs like format_date() which are simply thin wrappers for things like Datetime in C#. Developers just ensure stability of the schema/UDFs and any relevant Code-to-sql mappers. Also note the in-memory mode of operation for SQLite makes it a perfect fit for large numbers of ad-hoc projections in parallel.

goatinaboat 5y ago

The app-building app that ultimately wins is going to be the one that lets you build any app, not just an app that serves a particular niche or business process. We have those already. They're called IDEs. It turns out there's only so much complexity you can hide if you need to describe what you want to do unambiguously enough to be executed by a machine. Something like Visual Basic is probably as far as you can bury complexity while still being widely useful. Go much further and you start to drastically constrain the range of apps that can be built with your app-building-app. SQL is just the lowest-common-denominator notation for accessing and manipulating data by performing operations that can be represented by relational algebra and relational calculus. Fixating on the language itself misses the point that there is a theoretical underpinning to why data is handled this was in many practical applications.