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.