Mysql 不使用EAV存储属性/选项数据

我正在制作一个本地咖啡馆列表网站，我想获得一些关于我的数据库结构的反馈

咖啡馆有一系列属性，他们可以在任何选项上选择一个或多个。以下是我计划如何存储他们的数据

表：咖啡馆

CREATE TABLE `cafes` (
  `cafe_id` int(11) NOT NULL AUTO_INCREMENT,
  `name` varchar(255) NOT NULL,
  `cafe_types` text NOT NULL,
  `location_types` text NOT NULL,
  `amenities` varchar(255) NOT NULL,
  `parking` varchar(255) NOT NULL,
  PRIMARY KEY (`cafe_id`)
) ENGINE=InnoDB  DEFAULT CHARSET=latin1 ;

表：'咖啡馆\选项\地图'

CREATE TABLE `cafes_option_map` (
  `map_id` int(11) NOT NULL AUTO_INCREMENT,
  `column_name` varchar(30) NOT NULL,
  `cafe_id` int(11) NOT NULL,
  `name_id` int(11) NOT NULL,
  PRIMARY KEY (`map_id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

表：'咖啡馆\选项\名称'

CREATE TABLE `cafes_option_name` (
  `name_id` int(11) NOT NULL AUTO_INCREMENT,
  `name` varchar(255) NOT NULL,
  PRIMARY KEY (`name_id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

列咖啡馆类型、位置类型、便利设施和停车是多选项，有许多“选项”。这些选项需要按进行排序和筛选

我的问题是：

这是存储数据的好方法吗

有没有更好的办法呢

我的想法是，“cafes”表将包含一个逗号分隔的属性名称列表（如人类易读），以便以最少的DB调用轻松显示，然后还有用于筛选和排序查询的选项表

如果更容易理解，我可以为表格制作一些示例数据

您建议如何存储这些数据？我不想要EAV结构

这是存储数据的好方法吗

他妈的不

CSV是邪恶的
CSV无法以正常的方式编制索引。
CSV上的匹配很慢。
加入CSV是一场噩梦。
一旦你开始使用它们，你就会变得大胆，因为每次你需要写一个新的查询时，你都会开始拔头发

有没有更好的办法呢

EAV将比CSV好得多

但我不想要EAV

真的，对你有好处。EAV只是权宜之计。
如果要将n个属性链接到n个cafe，则需要一个n-n关系，这需要一个联接表

table cafe
------------
id integer PK autoincrement
name
address

table cafe_type
----------------
id integer PK autoincrement
name

table cafetype_link
-------------------
cafe_id integer
cafe_type_id integer
primary key PK (cafe_id, cafe_type_id)

然后对咖啡馆类型进行查询，如下所示：

SELECT c.* 
FROM cafe c
INNER JOIN cafetype_link cl ON (c.id = cl.cafe_id)
INNER JOIN cafe_type ct ON (ct.id = cl.cafe_type_id)
WHERE cafe_type.name = 'irish pub'

---

这工作非常简单和快速。然而，它并没有EAV那个么灵活。

“cafes”表将包含一个以逗号分隔的属性名称列表违反了第一个标准格式，因此是一个糟糕的设计。您希望您的属性是动态的。。。不要这样做。顺便说一句，为什么不是EAV？唯一比EAV更糟糕的是CSV，不要这样做，伙计，它会一次又一次地咬你。相信我，数据库中的CSV是一场噩梦。