Attribute names
It's strongly recommended that you define relations with attribute names specific to each relation,
e.g.
SNO
and
PNO
rather than a meaningless
id
for both.
This goes against many current naming conventions which do use something like
id
for
every
SQL table, often to make life easier for the
ORM
systems.
It's also common in such database schemas to use a variety of names for the same thing in different locations, e.g.
id
in one table, a different prefixed name (e.g.
supplier_id) as a foreign key in another table, and sometimes even more e.g.
supplier
in other places.
But why such inconsistency? And why choose your names to suit middleware coding tools?
Think of your relations as building blocks for equations. Names matter: an X here should be the same as the X over there.
Naming things based on their meaning not only helps with schema design and constraint definition but, as we'll see later, it also allows us to use the natural join, and other operators, to combine them sensibly and simply with other relations.
This should also extend to other attributes with common names such as title or name, e.g.
SNAME
and
PNAME
rather than
NAME
for both.
We could still join relations if unrelated attribute names clash by first renaming one of them, e.g. $R{*, r_name:=name} or removing one of them, e.g. $R~{name}.
Relvar names
It's suggested that you use singular nouns within relvar names, e.g.
$supplier rather than $suppliers.
This:
- removes issues with non-standard plurals, e.g. ies
- simplifies possessive references in later code and comments
- is shorter
- simplifies and shortens other names compounded from this one e.g. foreign key constraints
- is closer to the logical meaning, given that the relvar value should be thought of as a single set of tuples with a predicate rather than some kind of container of things