Question

我正在建立一个当地的咖啡馆列表网站，我希望得到一些关于我的数据库结构的反馈。

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

表：'cafes'

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 ;

表：'cafes_option_map'

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;

TABlE：'cafes_option_name'

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;

columns cafe_types，location_types，amenities和parking是多选的，有很多“选项”。这些选项需要进行排序和筛选。

我的问题是：

这是一个很好的存储数据的原因吗？
是否有更好的方法可以做到。

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

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

您如何建议存储此类数据？我不想要EAV结构。

Answer 1

这是一个很好的存储数据的原因吗？

地狱不！

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

有没有更好的方法来做到这一点。

EAV会比CSV好很多。

但我不想要EAV

认真对待你。 EAV只是一种止损措施如果要将n属性链接到n-cafes，则需要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那么灵活。

存储没有EAV的属性/选项数据

1 个答案: