Relational databases: some simple rules (part 2)

Tweet

This is the second part of the two parts article "Relational databases: some simple rules".

In the first part we have seen the ideas of tables and the way we can relate them.
And now... the conclusion!

Primary and foreign keys
We now need to move on a bit, but please keep in mind the example made in the first part of the article: two tables, with a relation for the state column.
The names table has the following columns: ID, name, surname, address, post code, city, state.
The states table has the following columns: ID, state.
In the persons table, the “state” column will contain only IDs related to the states table.
The ID column in the person table is a primary key. The ID in the state table is a primary key.
The “state” column in the persons table is a foreign key.
Quite easy, isn’t it?

Relational databases: some simple rules (part 1)

Tweet

It doesn't matter what we prefer to use, either Ms Access or SQL Server or Oracle, or even MySql, but when we want to create a new database, we really need to consider its structure, plan it and finally create all the database elements.
To do such a thing might seem easy – and in general it is – but a good development plan is what we need to avoid pitfalls and future issues with the structure of the database. The complexity of a database is surely one of the things to be considered, in fact it is clear that a more complex database will surely be more complex to develop.
Some simple rules can be taken into account and in this two parts article we are going to see some important points we need to keep in mind when planning a new database.