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 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.
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.
> 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
SQL Server (since 2005) can actually even have multiple active resultsets on a single connection. Assume same is true for most other database servers.
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.
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.