I think the misusage of the tag schema stems from people not reading the tag's usage guidance or the (non-existant) tag wiki excerpt. There there is the ambiguity of the tag schema itself, because of the two possible meanings of schema.
This if the primary explanation of the tag as it is supposed to be used on DBA.SE and is explained as:
The term "schema" refers to the organization of data as a blueprint of how the database is constructed (divided into database tables in the case of relational databases). The formal definition of a database schema is a set of formulas (sentences) called integrity constraints imposed on a database. These integrity constraints ensure compatibility between parts of the schema. All constraints are expressible in the same language. A database can be considered a structure in realization of the database language.1 The states of a created conceptual schema are transformed into an explicit mapping, the database schema. This describes how real-world entities are modeled in the database.
Reference: Database schema (Wikipedia)
I guess this is similar to the intended usage for "our" schema tag.
This is the second possible usage for schema, when you forget to look at the tag's usage guidance.
Oracles describes the use of schemas in its product as follows:
A schema is a collection of logical structures of data, or schema objects. A schema is owned by a database user and has the same name as that user. Each user owns a single schema. Schema objects can be created and manipulated with SQL and include the following types of objects:
- Database links
- Database triggers
- External procedure libraries
- Index-organized tables
- Java classes, Java resources, Java sources
- Materialized views
- Materialized view logs
- Mining models
- Object tables
- Object types
- Object views
- Stored functions, stored procedures
Reference: Schema Objects (Oracle | Docs | 12.1)
Microsoft SQL Server
SQL Server has its own definition which is explained in the following block of quotes.
A core concept of SQL Server security is that owners of objects have irrevocable permissions to administer them. You cannot remove privileges from an object owner, and you cannot drop users from a database if they own objects in it.
User-schema separation allows for more flexibility in managing database object permissions. A schema is a named container for database objects, which allows you to group objects into separate namespaces. For example, the AdventureWorks sample database contains schemas for Production, Sales, and HumanResources.
Schema Owners and Permissions
Schemas can be owned by any database principal, and a single principal can own multiple schemas. You can apply security rules to a schema, which are inherited by all objects in the schema. Once you set up access permissions for a schema, those permissions are automatically applied as new objects are added to the schema. Users can be assigned a default schema, and multiple database users can share the same schema.
Reference: Ownership and User-Schema Separation in SQL Server (Microsoft | Docs | .NET)
PostgreSQL's definition is defined as:
A database contains one or more named schemas, which in turn contain tables. Schemas also contain other kinds of named objects, including data types, functions, and operators. The same object name can be used in different schemas without conflict; for example, both schema1 and myschema can contain tables named mytable. Unlike databases, schemas are not rigidly separated: a user can access objects in any of the schemas in the database he is connected to, if he has privileges to do so.
There are several reasons why one might want to use schemas:
- To allow many users to use one database without interfering with each other.
- To organize database objects into logical groups to make them more manageable.
- Third-party applications can be put into separate schemas so they do not collide with the names of other objects.
Schemas are analogous to directories at the operating system level, except that schemas cannot be nested.
Reference: Schemas (PostgresSQL 9.1 | Documentation)
MySQL doesn't seem to have the concept of data schemas, but if anybody would like to enlighten me, then please do so.
Instead of burninating schema I would like to propose that we split the tag into its two possible meanings/definitions.
database-schema (as synonym of database-design)
As per the current description found in the schema Usage guidance. Essentialy, we rename schema to database-schema and switch it to being a synonym of database-design
Defined as: "Use this tag when referring to the grouping of objects into a logical data structure for the DBMS: Oracle, SQL Server and PostgreSQL.". This will be a new tag and might be used when referencing the relevant DBMSs.