组织大量列和数据的更好方法？

Question

我正在创建一个 real-estate 网站，我想知道是否有更好的方法来组织我的列或表，不确定什么是最好的方法，我目前有一个很多列，我担心性能问题。

栏目如下

5 用于属性 id、添加日期、持续时间、owner/user id。
35 列用于标题、描述、价格、能效等级、位置等
40 列功能，例如 swimming-pool、中央供暖、河滨、车库、水井等
15 用于存储在服务器上的图像位置
15 个图像描述

在 MySQL 中 110 多列是不好的做法吗？一切都快如闪电，但我在 mo 的本地主机中，表格的巨大尺寸不会减慢查询速度吗？特别是如果我有几百个属性？

我现在的设置还好吗？最佳做法是什么？ e-commerce 具有许多功能选项的网站如何处理此问题？

Answer 1

最有可能的是，属性特征最好存储在单独的 table 中，每个属性特征一行，而不是作为主 [=29= 中的列].我将其理解为属性与其特征之间的多对多关系，因此这表明还有两个 tables:

properties          (property_id (pk), date_added, title, description)
features            (feature_id (pk), description)
property_features   (property_id (fk), feature_id (fk))

与每个特征一列相比，这种结构更加灵活且更易于查询。例如：

通过在 features table 中创建新行来轻松添加功能（而在旧结构中您必须创建一个新列）
容易聚合特征，并回答类似这样的问题：计算每个属性有多少特征

至于图像，他们也应该有自己的作品 table。如果一张图片可能属于多个用户，那么就是多对多的关系，可以按照上面的模式。如果每张图片都属于一个用户，那么多一张 table 就足够了：

properties          (property_id (pk), date_added, title, description)
features            (feature_id (pk), description)
property_features   (property_id (fk), feature_id (fk))
images              (image_id, location, description, property_id (fk))

Answer 2

这不是一个好的做法，因为数据可以存储在单独的 table 中。对您最有帮助的是创建一个 ERD 来可视化如何组织您的 tables。即使你不了解ERD的来龙去脉，你仍然可以用它至少来整理你的思路。

您的 table 似乎已经根据您在问题中提出的要点分开了。我要添加到您的项目符号中的一件事可能是将您的功能分解为类别并为每个类别创建一个 table。

For example, swimming pools and riverfront can be placed in a table called LandscapeFeatures or OutdoorFeatures.

Answer 3

一个table:

您最有可能搜索的十几个值的列。
设计几个涉及这些列的复合索引，从更常搜索的列开始。
设计一个 TEXT 列并将“单词”放入其中作为 FULLTEXT 索引。如果这是房屋销售，请考虑“游泳池化粪池凉亭 Eichler”之类的词。这将有助于某些“布尔”类型的查询。（如果你喜欢这个想法，让我们讨论如何使用索引 and/or 全文进行过滤；它变得很棘手。）
将其余部分放入 JSON（或 TEXT 列）。不计划搜索它；在按实际 INDEXes

组织大量列和数据的更好方法？

Better way to organize lots of columns and data?

mysql

sql

database

database-design

query-optimization