Question

现有系统：

我有一个mySQL数据库，可存储大约200个不同的唯一用户的类别相关信息。为每个用户存储和检索的信息位于

的层次结构中

imageCategories
    > Parent Category 1
        > Child Category 1 : "45,19,3,4,8"
        > Child Category 2 : "17,1,99"
        > ... etc
    > Parent Category 2
        > Child Category 1 : "83,6"
        > Child Category 2 : "19,74,26"
        ... etc
    > etc

每个子类别的字符串值是一系列逗号分隔的ID，它们引用存储在该子类别下的描述（在单独的表上）。我通过以下形式的json_encoded字符串将所有这些作为数组存储在每个用户的列中：

{"Parent Category 1":{"Child Category 1":["45,19,3,4,8"],"Child Category 2":["17,1,99"]},"Parent Category 2":{"Child Category 1":["83,6"],"Child Category 2":["19,74,26"]}}

系统通过在用户登录并将其解码为会话数组时检索此json_string来工作。每当对其进行任何更改时，它都会重新编码为json字符串，保存到数据库并更新会话数组以反映这一点。这很好用。虽然我的研究方式让我这样做，但我从未确定在mySQL中存储多维数组是否是最佳实践。我所知道的是，它一直在组织它没有压力，我没有注意到它导致了很多开销，这并不是说它没有。

难题：

我现在要做的是为数据库中的每个子类别添加一个字符串描述。可能会在每个家长类别之后，但宝贝先步骤。

我最初将为整个阵列启动第三个维度。而不是：

"Child Category Key" : "id string"

我会将其更改为：

"Child Category Key" : ["id string", "description string"]

或：

"Child Category Key" : ["id string", id for description on another table]

我也没有看到任何一个问题，但我想知道是否能够改进最佳做法。我是否应该为整个类别结构创建一个新表，而不是将其全部存储为具有其他用户设置的列中的json字符串（它在字符长度方面永远不会变得过于笨拙）。目前的结构非常容易理解，我不一定会跳到一个解决方案，如果它的结构使管理数据库变得非常复杂，那么它将带来最小的开销优势（请记住我们中的一些人并不是＃39;自然在这和我们的大脑处理这种结构比其他结构慢一点。）

设计要求：

我可能会错过描述所需的细节，因为我不确定哪些相关信息来自哪些相关信息。我可以在需要的地方详细说明。似乎最重要的设计要求是每个用户都有唯一的类别键和值。它们只能采用parent＆gt;的形式。 child＆gt; csv of ids但每个用户都有自定义键标题和每个用户的不同数量。每个的顺序也很重要。

我目前正在使用ssd磁盘，1GB内存和来自Intel hexcore的单个2ghz核心的服务器上运行。对数据库的请求主要是检索前端和后端的类别。大多数人使用的交通量很少，因此除了偶尔的峰值之外什么都没有。当我看到瓶颈逼近时，我会升级。只是尝试尽可能有效地利用我拥有的东西并保持最佳实践。

数据库结构：

现在我的表格结构是（省略与问题无关的其他列）：

表用户设置：

+-----+----------------------+-----+
| id  |   imageCategories    | ... |
+-----+----------------------+-----+
|   1 | {"Parent Category... | ... |
|   2 | {"Parent Category... | ... |
|   3 | {"Parent Category... | ... |
| ... |                      |     |
+-----+----------------------+-----+

表用户：

+-----+----------------------+---------+--------+
| id  |   username           | cluster | server |
+-----+----------------------+---------+--------+
|   1 | johndoe              |       1 |      1 |
|   2 | katedoe              |       1 |      1 |
|   3 | ellendoe             |       1 |      1 |
| ... |                      |         |        |
+-----+----------------------+---------+--------+

表格说明_0001：

+-----+---------+---------------+-----+
| id  |  title  | descriptions  | ... |
+-----+---------+---------------+-----+
|  11 | Title 1 | Description 1 | ... |
|  56 | Title 2 | Description 2 | ... |
|  78 | Title 3 | Description 3 | ... |
| ... |         |               |     |
+-----+---------+---------------+-----+

用户中的每个 usersettings 条目都有一个相等的行，其中包含匹配的ID。因此，他们的用户名等总是可以通过知道自己的ID号从用户设置中引用。目前我只有一个数据库但是为了将来证明它在某种程度上我将描述存储在名称中有索引的表中，并且每个用户都有一个簇号值和一个服务器号值。平均而言，每个用户有大约100个描述行，因此此刻将达到20,000行。当这会产生瓶颈时，我将启动描述表0002 ，稍后需要第二台服务器。也许我在我的工作流程中很天真，但它似乎应该有所帮助。

要点：

总而言之，我应该调整我的categories数组来存储子类别的字符串描述：

使子类别键具有数组值而不是当前字符串值，包含当前字符串值和附加字符串说明。
与1类似，但将字符串描述作为引用的id号新表上的字符串
看看根本不使用json编码数组并移动整个数组类别结构进入自己的表
为父类别创建一个表，一个用于子类别，一个用于csv内容。在每个中包含一个描述列（根据上面的难题）和一个订单列（根据上面的设计要求必不可少） - 或者有更好的存储顺序的方法，而不是检索和更新每个相关行的订单列。包含多个用户的唯一类别信息？听起来它可能需要很多开销。

Answer 1

我最终找到了与（4）类似的解决方案。我现在也更好地理解描述设计要求的重要性，因为我认为这个决定是因为它更有效地处理（我相信？）并且更容易理解一次使用层次结构的选择级别。 / p>

例如，如果我处理父类别2，子类别1下的所有描述，我只是在描述表中使用共享标识符获取或插入所有描述，而不是处理包含多维数组的多维数组所有层次结构。后者使得在数据库中组织用户变得更容易，但分类变得足够大，以至于我确定它确保为层次结构的每个级别保证单独的表。在足够多的情况下，我只使用一个独立的分类层次结构，将整个分类放入单个md数组中，感觉就像是较差的选择。

就开销差异而言，我现在不确定。在PHP中发生的数组排序较少，以隔离我需要的数据，但是对数据库的调用要多得多。

我对理解设计要求的犹豫（并且仍未对此做出彻底的回答）是我对大型用户数据库的新手并不擅长预测需求。我设计它的方式让我感觉可扩展，因此，层次结构的每个级别的表格感觉最不麻烦（在繁琐的设置之后 - 我目前正在重做吨数用于使函数与新设置一起工作的代码，并且随着需求的变化更加可扩展。

用于多维分类的mySQL表组织

现有系统：

难题：

设计要求：

数据库结构：

要点：

1 个答案: