Database is a huge city - Understanding DB intuitively by designing a city with Rails

Until now, we have likened the database (DB) to a drawer or a box.

This time, let's go to a completely different world.

Let's think of DB as a city.

A city has zones, buildings, and many rooms inside.

Database = Entire city
Table = Building
Record = Room
Column = Attributes inside the room (size, usage, price, etc.)

The city analogy is the most natural analogy to understand the structural concept of DB and relational data model.

Now, let's directly design a "city" with Rails and experience how the DB is structured.

Part 1. Building the first building in the city called DB

In the terminal:

rails generate model Building name:string floors:integer
rails db:migrate

This command can be interpreted as follows.

"I will build a building called Building in the city (DB).

The building has two attributes, name and floors."

Based on this command, Rails builds buildings in the city and defines attributes (rooms) that exist commonly for each building.

Now, in our city, there exists a building called Building.

Part 2. Allowing to create "rooms" inside the building

There should be actual rooms in the building (Building)

so that people can live,

collect rent,

and the city has meaning.

Let's create a Room table.

rails generate model Room number:string size:integer building:references
rails db:migrate

This means:

"Create a room called Room,

and indicate which Building the rooms belong to."

Rails automatically creates a column called building_id to connect which building the room belongs to.

This is the relationship of the DB.

(It's so natural in the city analogy that it doesn't need much explanation!)

Part 3. Teaching Rails the "relationship between buildings and rooms"

app/models/building.rb

class Building < ApplicationRecord
  has_many :rooms
end

app/models/room.rb

class Room < ApplicationRecord
  belongs_to :building
end

Now Rails fully understands.

There are multiple rooms in a building (Building)
A room (Room) must belong to a specific building (Building)

In the city analogy, the obvious structure is the core principle of the DB.

Part 4. Directly "building a building" in the console

In the Rails console:

b = Building.create(name: "Star Tower", floors: 30)

Here, we have built an actual building named 'Star Tower' in the city (DB).

Part 5. Creating rooms inside the building

b.rooms.create(number: "101", size: 28)
b.rooms.create(number: "102", size: 33)
b.rooms.create(number: "201", size: 40)

Now, inside the 'Star Tower' building,

3 rooms have been created.

At this moment,

the structure of city → building → room

perfectly aligns with the structural essence of the DB.

Part 6. Let's look at the rooms

(Feeling like viewing a list of rooms in a specific building in the city)

b.rooms

Rails requests like this.

"Show all rooms in this building!"

The DB accurately finds only the rooms belonging to 'Star Tower'

among the millions of buildings in the city.

This is why the database can manage all data quickly and accurately

like the 'city administration system' of modern web services.

Part 7. Finding rooms based on specific attributes

(Feeling like searching for real estate)

Room.where(size: 33)

This command means:

"Find only rooms with a size of 33 in the entire city."

Just like searching for room information on the web,

the DB selects only the rooms that meet the conditions

from thousands or tens of thousands.

Part 8. Now the reader realizes

"Ah... DB is a city,

tables are buildings,

and records are rooms, which sounds so natural."

"Actually, it feels like building a city with Rails,

and the concepts become clear in my mind."

"Then, I could design web service data

just like designing a city!"

The moment this feeling arises,

the DB is no longer an abstract technology.

You have now become a developer

with the mindset of an architect.

Database is a huge city