数据库就像一个巨大的城市 - 通过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不再是抽象的技术。
您现在是
具有建筑师思维的开发人员。