我正在尝试创建一个类似于Yelp(规模较小,市场较小)的网站,现在我正处于数据库设计阶段,并且想知道如何对表进行建模以存储“其他业务信息”功能偶尔会在某些商家信息中找到,例如:
请注意,此信息中的某些信息仅适用于特定类别的商家,例如 服装和提供信息可能只适用于餐馆内的商家 因此,将所有内容存储在主 business 表中是没有意义的。
我想知道的是如何存储这些额外功能/有关业务的其他信息,因为它们不适用于所有业务,而不适用于所有业务。
我在考虑将每个功能放在自己的表中,并通过* biz_id * FK链接到主要业务表,例如
Businesses
-------------
biz_id (PK)
name
website
isnew
...
Biz_accepts_credit_card
-----------------------
biz_id (FK)
accepts_credit_card (bit field)
Biz_parking (biz can have multiple parking types)
-----------
auto_id (PK)
biz_id (FK)
parking_type {any combination of: street,garage,valet,etc}
...
我的想法是,虽然这会创建大量的表只是为了存储这些额外的信息,但它也会非常灵活,特别是在未来的路上添加新的信息/功能方面,但它可能意味着我必须加入许多表格(最坏情况下为15+),仅供参考:/
我也想知道一个企业可能陷入的各种类别是否会对此产生任何影响。
编辑:阅读@Daveo的回复
Features{id, name, ismultiVal} (defines all possible features)
FeatureValues{id, feature_id, value} (defines the possible values each feature can have)
BusinessFeatures{id, biz_id, feature_id, feature_value} (stores the features applicable to each business)
CategoryFeatures_{category_id, feature_id} (what features are found in which categories)
FeatureReviews_{review_id, feature_id, feature_value} (stores the feature values that users voted on in their review of a business)
答案 0 :(得分:2)
我不会为每个功能制作单独的表格。我会建立一个通用的数据库结构。
Businesses
-------------
biz_id (PK)
name
website
isnew
...
Biz_Feature
-----------------------
biz_id (FK)
feature(FK)
Feature
-----------
Feature_id (PK)
FeatureType_id (FK)
name
Feature_Type
-----------
Feature_Type (PK)
Name
E.g。
Feature_Type
1 good for kids
2 parking
Feature
id type_id name
1 1 yes
2 1 no
3 2 street
4 2 garage
这是我要开始的地方。但随后添加额外信息以确定功能是否应显示为复选框。
答案 1 :(得分:1)
您可能最终需要按功能搜索商家,这意味着需要将这些功能编入索引。
Daveo建议添加EAV商店的数量 - 这正是您所做的 NOT 想要imo。您无法有效地索引EAV商店。
我正在考虑将每个功能放在自己的表中,并通过* biz_id *
链接到主要业务表
如果您最终需要挖掘数据,这确实是正确的方法。