php - MySQL表组织进行多维分类

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，这些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字符串存储在具有其他用户设置的列中（从字符长度的角度来看，它永远不会太笨拙）。当前的结构很容易引起我的注意，如果它的结构使数据库的管理变得不必要地复杂，我不一定会跳到提供最小开销的解决方案（请记住，我们中的某些人对此并不自然，我们的大脑比其他人处理这种结构要慢一些。



设计要求：

我不确定所需的具体细节，因为我不确定最相关的信息来自于哪些相关信息。我可以在需要的地方详细说明。似乎最重要的设计要求是每个用户都有唯一的类别键和值。它们只能采用parent> child> 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 | ... |
| ... |         |               |     |
+-----+---------+---------------+-----+

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

 

摘要：

因此，总而言之，我应该通过以下方式调整我的类别数组以存储子类别的字符串描述：


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

Answer 1

我最终寻求了一种类似于（4）的解决方案。我也更好地理解了现在描述设计需求的重要性，因为促使我做出这个决定的是认识到它在处理上效率更高（我相信吗？），并且更容易理解每​​次选择层次结构的选定级别。

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

关于开销差异，我现在不确定。在php中发生的数组排序较少，可以隔离我需要的数据，但对数据库的调用却更多。

我在理解设计要求时犹豫不决（仍然对此没有给出完整的答案）是，我是大型用户数据库的新手，并且不擅长预测需求。我以一种对我来说可扩展的方式进行设计，因此，同样，层次结构的每个级别的表都变得最不麻烦（设置繁琐之后，我目前正在重做大量代码以实现功能）使用新的设置），并且可以根据需求的变化进行扩展。