数据库就像一个巨大的城市 - 通过Rails设计城市并直观地理解数据库

我们迄今为止

将数据库(DB)比作抽屉或盒子。

这次，让我们去一个完全不同的世界。

让我们想象DB = 城市。

城市有区域，有建筑物，

里面有许多房间。

• Database = 整个城市

• Table = 建筑物(Building)

• Record = 房间(Room)

• Column = 房间内的属性(大小、用途、价格等)

城市的比喻

是对DB的结构概念和

关系型数据模型

最自然的理解比喻。

现在，让我们通过Rails直接“设计城市”，

亲身体验DB是如何组织的。

第1部分 在名为DB的城市中建立第一座建筑物(Building)

在终端中：

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

这个命令可以这样解释：

“在城市(DB)中建造一座名为Building的建筑物。

建筑物有名称(name)和楼层(floors)这两个属性。”

Rails根据这个命令

在城市中建造建筑物，并定义每座建筑物共有的属性(格子)。

现在我们的城市中

存在着名为Building的建筑物。

第2部分 使建筑物内能够创建“房间(Room)”

建筑物(Building)必须有实际的房间

人们才能居住，

也可以收取租金，

城市才有意义。

因此，让我们创建Room表。

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

这意味着：

“创建名为Room的房间，

并指示这些房间属于哪座Building(建筑物)。”

Rails会自动创建一个名为building_id的格子

将房间与建筑物连接。

这就是

DB的关系(relationship)。

(在城市的比喻中，这是如此自然，无需解释！)

第3部分 教会Rails“建筑物和房间的关系”

app/models/building.rb

class Building < ApplicationRecord
  has_many :rooms
end

app/models/room.rb

class Room < ApplicationRecord
  belongs_to :building
end

现在Rails完全理解了。

• 建筑物(Building)内有多个房间(Room)

• 房间(Room)必定属于某座建筑物(Building)

在城市的比喻中

如此理所当然的结构

正是DB核心原则的体现。

第4部分 在控制台中直接“建造一座建筑物”

在Rails控制台中：

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

在这里，我们

在城市(DB)中

建造了一座名为“Star Tower”的实际建筑物。

第5部分 在建筑物内创建房间(Room)

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

现在“Star Tower”建筑物内

有3个房间。

这一刻，

城市 → 建筑物 → 房间

这种结构

与DB的结构本质一一对应。

第6部分 让我们查看房间

(就像在城市中查看特定建筑物的房间列表一样)

b.rooms

Rails这样请求：

“展示这座建筑物(Building)的所有房间(Room)！”

DB会

在城市的100万座建筑物中

准确找到属于“Star Tower”的房间。

这就是数据库

像现代网络服务的‘城市行政系统’一样

能够快速而准确地管理所有数据的原因。

第7部分 根据特定属性查找房间

(就像房地产搜索一样)

Room.where(size: 33)

这个命令是：

“在整个城市中找到大小为33的房间。”

就像在网上搜索房间信息一样

DB会从成千上万个中

挑选出符合条件的房间。

第8部分 现在读者明白了

“啊…DB就是城市，

表就是建筑物，

记录就是房间，这说法太自然了。”

“实际上通过Rails建造城市的感觉，

让概念在脑海中清晰了。”

“那么我也可以像设计城市一样

设计网络服务的数据！？”

当产生这种感觉时，

DB不再是抽象的技术。

您现在是

具有建筑师思维的开发人员。