我正在考虑是否应该在 MySQL 中使用大型多维数组或数据库。我正在为一个业务有很多产品的客户开发。在这个多维数组中,我将包含每个产品的产品标题、描述、图像链接和类别。
我的客户可能有 1000 多种产品。我研究了其他类似的问题,其中许多人说数组可能更快,但是他们都没有处理这种规模的数组。
我个人更愿意使用数组,因为我对 MySQL 的了解非常有限,但如果这意味着要牺牲大量的速度,那么我宁愿使用数据库。对于我的情况,您认为哪个更合适?
我正在考虑是否应该在 MySQL 中使用大型多维数组或数据库。我正在为一个业务有很多产品的客户开发。在这个多维数组中,我将包含每个产品的产品标题、描述、图像链接和类别。
我的客户可能有 1000 多种产品。我研究了其他类似的问题,其中许多人说数组可能更快,但是他们都没有处理这种规模的数组。
我个人更愿意使用数组,因为我对 MySQL 的了解非常有限,但如果这意味着要牺牲大量的速度,那么我宁愿使用数据库。对于我的情况,您认为哪个更合适?
其他答案是正确的 - 但出于错误的原因。
将数据保存在 PHP 数组中将比从数据库中获取快得多 - 即使数据集缓存在内存中。问题在于,在普通 PHP 架构中,每个请求都由单独的进程处理。因此,每个需要访问数据的请求都必须将整个数据集加载到内存中。这需要时间。执行此操作而不是从数据库中检索项目变得更加昂贵的点取决于许多不同的因素 - 但作为粗略的经验法则,它在 100 条记录的区域内。在某些应用程序中,这种模型是有意义的——但它们依赖于非常小的数据量和更改/管理数据的受控过程。
您的下一个问题是您可能想要记录一些针对股票的交易——这意味着更改数据——这意味着序列化访问以确保不会同时发生 2 个单独的交易。在没有死锁的情况下,不可能在 PHP 中实现这一点(没有专门的守护进程来裁决)。
如果你为实现代码向某人收费,那么很明显,试图在内存中实现它是一个非常非常糟糕的主意。
老实说,我会选择数据库。这是我的推理。
使用数据库,您将在连接时间、通信和查询时间方面获得少量性能损失。但是,收益将来自几个方面。
此外,使用肉眼查看数据库将更容易。
希望这可以帮助!
使用数组的代码会更简单,不会有 MySQL 数据库的复杂性。如果该数据是静态的,并且该数据没有其他用途或用户,那么该数组就可以了。
另一方面,如果该数据需要更改,或者该数据对某些其他业务功能有用,那么 MySQL 数据库将是可行的方法。
让我们稍微谈谈内存消耗。
PHP 中的一个数组元素消耗 144 字节的数据,不包括任何字符串文本(额外的)。
然后,一个包含 1000 个元素的数组使用 144.000 个字节加上文本字符串——这看起来并不多。
但是你不能只用一个值创建一个有用的数据结构,所以你的 1000 个元素可能是一个包含子元素的数组。让我们假设每个数组只有 10 个元素。每个元素的数组将是 1440 字节,乘以 1000 个元素。不是我们正在接近 1.440.000 字节。仍然喜欢“无”,但文字呢?更复杂的子结构呢?最终会有多大?
此外,对于每个并发请求,该数组必须在内存中。并且必须以某种方式加载。对阵列进行反序列化确实需要相当多的 CPU 资源。
最后:使用数据库!将所有数据推送到内存中没有任何好处。