Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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).


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.


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)


A schema is not just tables, though - there are also views, types, functions and other stuff that lives in a schema too.


Schema covers the definition of a bunch of related tables.

A database can run as many schemas at it wants, for as many applications as it wants. I might not be able to see them all.

"My database" doesn't mean anything in an enterprise environment. It might not even be 'mine' for any of several competing definitions.

Also there are several ways I could break "my database" which would result in every single employee at the company being pissed off, at the same time. Even if they've never heard of my project.


> Schema covers the definition of a bunch of related tables. A database can run as many schemas at it wants, ...

You're really getting hung up on the way that many DBMSs conflate the traditional meaning of schema (the names and types of the columns) with something slightly different (the database schema along with the actual data in it and some other metadata).

In fact your own comment conflates those meanings too! You say "the definition of a bunch of tables" but you seem to be talking about the data in them as well as their definition. This seems like extra evidence that it is better to avoid this term.

At least when you're talking about the multiple different schemas (in the DBMS sense) in a database, they very often (not always) have different sets of tables with different column names and types, so they really do have different schemas (in the traditional sense). But here, the focus is really on the data itself being returned (albeit the benefit of it is that it has a more usefully rich schema than a traditional SQL result), so I think calling that data a schema is a bad word choice.


> Schema covers the definition of a bunch of related tables.

> A database can run as many schemas at it wants, for as many applications as it wants.

Even in the scope of a single application, the word “schema” can be ambiguous. For example, I have a Spring Boot application, which stores its data in Postgres. Inside the JAR there is a collection of SQL files which are executed by Flyway at startup, and we call those files “the schema”. At the same time, we have a configuration option to tell the application which Postgres schema to use within its database, and we actually use that so multiple QA environments can all share the same database. [0] So even in this single app the word “schema” is being used in two different (albeit related) ways. Maybe we just need to accept that language is like that, many words have multiple meanings (sometimes even related meanings) and the context determines which of those meanings applies in any particular case.

[0] maybe should have put them in separate catalogs, but ended up going with separate schemas in the same catalog because that was the simplest configuration that met the need


It's true that database schemas have a tendency to evolve into Conway's Law.


Abstractions are just technical terms for analogies, and they commonly break down as you go deeper down the stack ;).


Multiple resultsets is a common term. Where a resultset is a table basically.

SQL Server (since 2005) can actually even have multiple active resultsets on a single connection. Assume same is true for most other database servers.


Long time ago I learned that a database is any kind of structured, machine readable data. A database management system is the software that manages these databases and databases + database management system = database system. Dunno if recalled correctly.

Directly afterwards I got told that no one ever uses these words correctly, but the professor felt obliged to at least tell us the academic definition once.

Since this was a German lecture, some time was spent on the correct plural of schema (german: Schema). The options presented were Schema, Schemas, Schemata and everything was allowed as long as it is not Schemen (multiple shadowy figures).

Dunno why I remember this. It's the only part of the lecture I really remember.


you must have visited the same school as i did. maybe the prof also said: there is no science in informatics, only in RDMS you can prove something. pulls out ms access

https://bbsw-koblenz.de/


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.


What are you refering to, more specifically, from Codd's original paper?


IMO the title is actually pretty great. Yes its not very precise, but on the positive side its catchy and gets the point across quick.


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.




Consider applying for YC's Fall 2026 batch! Applications are open till July 27.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: