[HN Gopher] What if an SQL Statement Returned a Database?
___________________________________________________________________
What if an SQL Statement Returned a Database?
Author : matt_d
Score : 58 points
Date : 2023-12-11 22:05 UTC (54 minutes ago)
(HTM) web link (arxiv.org)
(TXT) w3m dump (arxiv.org)
| sargstuff wrote:
| sql RBAC views? Needs a corresponding 'lasso' command to merge
| old/new databases.
| liotier wrote:
| Is this question a JSON joke ?
| sargstuff wrote:
| think it's an api wrapper for old school NP complete/unbounded
| delimited query aka (system("dump all database tables in
| delimited format, grep for results, create new database with
| grep'd results while keeping original
| datatypes/functions/etc)). Hopefully with full 8/16/32/64 utf
| suport.
|
| Perhaps sql take on 'view to a kill' aka create view / kill -9
| database view
| Animats wrote:
| It's currying, for SQL. Cute. The functional people have
| discovered SQL.
|
| This is presumably lazy evaluation - the "returned database" is
| just some object that implies a selection from the database. You
| don't want to copy all the records.
| codetrotter wrote:
| > The functional people have discovered SQL
|
| Either that, or the SQL people have discovered functional
| sitkack wrote:
| Both parties are aware of the other. One of the premier
| authors of advanced sql concepts programs in Haskell.
| https://en.wikipedia.org/wiki/Joe_Celko
| mrits wrote:
| Also the clojure guy Rich Hickey has done a ton of SQL
| stuff
| sargstuff wrote:
| so, why 'one ton'/wanting more if have clojure?
| sargstuff wrote:
| What about dbms system call wrapper to advanced OS
| concepts? aka meet on mountain slopes to spin up herds of
| select ram (disk) copies.
|
| The dbms version of OS dining philosopers.[0] Lot less
| haskell.
|
| [0] :
| https://en.wikipedia.org/wiki/Dining_philosophers_problem
| sitkack wrote:
| I like this.
|
| It is like a CTE but you can take a subset of a database that
| satisfies the join condition. I could see this being used in a
| select for update scenario.
| o11c wrote:
| Rant: we should avoid the term "database" in contexts like this.
| The standard terms are "schema" (for the definition of "database"
| that sqlite and mysql use) and "catalog" (for the definition of
| "database" that postgresql uses). It's further overloaded to
| sometimes mean DBMS (database management system, i.e. an
| implementation), and sometimes also "cluster" or "daemon
| instance" (which sometimes overlap with one of the previous
| senses, but in different ways per implementation).
| quietbritishjim wrote:
| The word schema is the format that the data must adhere to, not
| the data itself, at least in the rest of computing, and the
| literal meaning is very close to that. So that is a bad word to
| use for a bunch of data, whereas database is clearly means a
| bunch of data.
| quickthrower2 wrote:
| I think "multiple tables" would be clearest for the
| submission. Or if it is the case "all tables in the database
| schema" or "all tables in all schemas of the database the
| user can access"
|
| The overloading horse has bolted so might as well aim for
| clarity for the intended audience.
|
| When I see just the word "Database" my brain treats it as a
| wildcard could be many things (like State could be a country
| or a state of a country)
| hinkley wrote:
| [delayed]
| sargstuff wrote:
| so, other than having sql abstraction, don't see how's that's
| any different from dbms system call to create ram disk, copy
| current database over to virtual disk, delete irrelevant data,
| and fork process to use the database in ram disk.
| cmrdporcupine wrote:
| I think what the author is awkwardly groping at here is a
| concept of returning multiple relations ("tables") from a
| single query.
|
| Which, well, this person needs to go back and read Codd's
| original paper. They don't understand the domain they're
| attempting to muck around in.
| js8 wrote:
| IIRC this (returning a full database with a schema as a result of
| a query) has been proposed before in categorical databases, see
| https://www.categoricaldata.net/
| crazygringo wrote:
| I'm struggling to understand the purpose of this.
|
| If I understand it correctly, for a query with joins, then
| instead of returning a single combined set of results with the
| information you need, it returns multiple sets of results based
| on each separate table.
|
| But I don't understand why that would ever be desirable.
|
| I always write my queries to return the information I need, per
| whatever "key" I need, in each row. Splitting that up in multiple
| sets of results is not helpful.
|
| Or if I really need multiple sets of data, I write multiple
| queries.
|
| So I really don't get what this is for. It's like it takes one of
| the biggest features of databases -- joins -- and removes it?
| Why?
| sargstuff wrote:
| (humor) if system not set up appropriately, expanded long form
| version of shell fork bomb[0] that drains bank account per pay
| per amount of resources used.
|
| [0] https://www.cyberciti.biz/faq/understanding-bash-fork-bomb/
| irrational wrote:
| Jokes on them. My bank account is already empty.
| cmrdporcupine wrote:
| Reading the abstract... it feels to me like the author doesn't
| know what a relational database _is_.
|
| Chris Date does discuss the concept of nested tuples /
| relation-valued tuples of some kind in his books as an
| extension to the relational model. But that's something else
| entirely.
| oleg_antonyan wrote:
| It could be useful with ORM. For example, in Rails ActiveRecord
| instantiates the class for each row. But when you need to write
| complex query with many joins and instantiate AR models tree
| from it becomes either cumbersome or leads to n+1 queries.
| Still pretty niche usecase, but looks interesting
| mjhay wrote:
| This is pretty cool given the potential backward compatibility -
| which makes widespread adoption much more realistic.
|
| There is some prior art of queries as morphisms between DBs (or
| schemas) in the category theory community.
|
| e.g.,
|
| https://www.categoricaldata.net/
|
| https://arxiv.org/pdf/0904.2012.pdf
| paulsutter wrote:
| This is way better than views
| bob1029 wrote:
| I feel like we could build something like this with SQLite,
| application defined functions and in-memory DB pretty quickly.
|
| But then I ask myself... Why would I want to do any of this? If I
| do Database=>sql command=>Database... Don't I have to write yet-
| more-SQL (or something approximating SQL) to get at my final
| items? I can't write a foreach loop over pile-o-tables. Virtually
| all programming abstractions expect some serial flow and
| enumerations of types.
|
| At some point, you are going to have to map A to B, and I'd argue
| adding another database in the middle probably isn't strictly
| headed in the right direction.
|
| If you want to select 2 different result shapes, just write 2
| different queries. Use some lateral concepts in your programming
| environment to make the SQL part not suck. If you stand on some
| weird "one query only" principle every time you have to populate
| a practical view, you are going to have a super rough time with
| life.
| quickthrower2 wrote:
| I don't get why it is a paper? Just make multiple requests SELECT
| ... FROM TABLE. You can batch them if you like, or just send out
| multiple requests in parallel.
|
| Infact this is what some shitty ORMs do when you _don 't_ want
| them to do this and you actually wanted a join. (Grrrr!).
| Sometimes you want the opposite. The complaint is more that ORMs
| do silly things and there is less control.
|
| I am guessing the paper is really about some nice sugar for doing
| this?
___________________________________________________________________
(page generated 2023-12-11 23:00 UTC)