当前位置：文江博客话题详情

网站：存储大量用户变量的最佳方式是什么？

发布于 2024-08-21 10:32:05 字数 273 浏览 6 评论 0原文

我目前正在使用 PHP 和 MySQL 设计一个网站，随着网站的进展，我发现自己向用户表添加了越来越多的列来存储各种变量。

这让我思考，是否有更好的方法来存储这些信息？需要澄清的是，这些信息是全球性的，可能会受到其他用户的影响，因此 cookie 不起作用，而且如果他们清除 cookie，我也会丢失这些信息。

我的问题的第二部分是，如果事实证明将其存储在数据库中是最好的方法，那么拥有大量列或者将相关列组合成分隔的 varchar 列然后分解它们是否会更便宜在 PHP 中？

谢谢！

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

转身以后 2024-08-28 10:32:05

根据我的经验，我宁愿让数据库正确，也不愿开始添加包含多个项目的逗号分隔字段。必须筛选多个逗号分隔的字段只会损害程序的效率和代码的可读性。

另外，如果您的表增长得太多，那么您可能需要考虑将其拆分为由外部依赖项连接的多个表？

回复收藏 0 原文

爱的故事 2024-08-28 10:32:05

我将创建一个 user_meta 表，其中包含三列：user_id、key、value。

回复收藏 0 原文

煮酒 2024-08-28 10:32:05

我不会选择将列分组在一起并分解它们。这是一项杂乱的工作，而且非常难以管理。相反，也许可以尝试将这些列分散到几个表中并使用 InnoDb 的事务功能。

如果您仍然不喜欢频繁更新数据库的想法，并且此方法符合您想要实现的目标，则可以使用 APC 的缓存功能在服务器上“全局”存储（缓存）信息。

回复收藏 0 原文

风铃鹿 2024-08-28 10:32:05

MongoDB（及其 NoSQL 同类）非常适合此类任务。

回复收藏 0 原文

酒解孤独 2024-08-28 10:32:05

数据库是存储此类数据的完美场所，只要它们是变量而不是巨大的图像文件。该数据库具有用于存储和检索大量数据的所有优化和规范。您在文件系统级别设置的任何内容在速度和功能方面总是会被数据库已有的内容击败。

拥有大量列或者将相关列组合成分隔的 varchar 列然后在 PHP 中分解它们会更便宜吗？

在我看来，这实际上并不是一个性能问题，而是一个维护问题 - 管理数百个列并不有趣。存储此类数据 - 可能作为 序列化d 对象 - 在 中TEXT 字段是一个可行的选项 - 只要它 100% 确定您永远不必对该数据进行任何查询。

但为什么不使用规范化的 user_variables 表，如下所示：

id  | user_id | variable_name | variable_value

？

它的查询有点复杂，但提供了一个非常干净的表结构。您可以通过这种方式轻松添加任意用户变量。

如果您正在进行大量查询，例如 SELECT FROM USERS WHERE variable257 = 'green'，您可能必须坚持使用特定列。

The database a perfectly fine place to store such data, as long as they're variables and not, say, huge image files. The database has all the optimizations and specifications for storing and retrieving large amounts of data. Anything you set up on file system level will always be beaten by what the database already has in terms of speed and functionality.

would it be less expensive to have a large number of columns or rather to combine related columns into delimited varchar columns and then explode them in PHP?

It's not really that much of a performance than a maintenance question IMO - it's not fun to manage hundreds of columns. Storing such data - perhaps as serialized objects - in a TEXT field is a viable option - as long as it's 100% sure you will never have to make any queries on that data.

But why not use a normalized user_variables table like so:

id  | user_id | variable_name | variable_value

It is a bit more complex to query, but provides for a very clean table structure all round. You can easily add arbitrary user variables that way.

If you are doing a lot of queries like SELECT FROM USERS WHERE variable257 = 'green' you may have to stick to have specific columns.

回复收藏 0 原文

断念 2024-08-28 10:32:05

数据库绝对是存储数据的最佳场所。（我假设您正在考虑将其存储在平面文件中）与存储在文件中相比，使用数据库肯定会获得更好的性能和安全性。

关于将数据存储在多列中或对它们进行分隔...这是个人选择，但您应该考虑一些事项

如果要对项目进行分隔，您需要考虑要对它们进行分隔的内容与（在你的定界文本中不太可能出现的东西）
我经常发现，尝试想象与你水平相当的另一个程序员是否能够在很少的帮助下理解你所做的事情是有帮助的。
是的，正如 Pekka 所说，如果你想对存储的数据执行查询，你应该坚持使用单独的列，
如果你只想要几个字段，那么你也可以通过不每次检索和解析所有数据来获得轻微的性能提升。我建议您

使用单独的列，因为它为您提供了未来更大灵活性的选择。没有什么比必须彻底改变数据结构并沿着轨道迁移信息更糟糕的了！

回复收藏 0 原文

喵星人汪星人 2024-08-28 10:32:05

我建议设置一个 memcached 服务器（参见 http://memcached.org/）。事实证明，它对于许多大型网站都是可行的。 PHP 有两个扩展可将客户端集成到运行时（请参阅 http://php.net /manual/en/book.memcached.php）。

尝试一下，你不会后悔的。

编辑
当然，这只是经常使用的数据的一个选项，否则必须一次又一次地从数据库加载。但请记住，您仍然需要将数据保存到某种持久存储中。

回复收藏 0 原文

对你而言 2024-08-28 10:32:05

面向文档的数据库可能正是您所需要的。

如果您想坚持使用关系数据库，请不要采用仅创建包含如此多字段的表的天真的方法：

CREATE TABLE SomeEntity (
    ENTITY_ID    CHAR(10)    NOT NULL,
    PROPERTY_1   VARCHAR(50),
    PROPERTY_2   VARCHAR(50),
    PROPERTY_3   VARCHAR(50),
    ...
    PROPERTY_915 VARCHAR(50),
    PRIMARY KEY  (ENTITY_ID)
);

而是定义一个属性表：

CREATE TABLE Attribute (
    ATTRIBUTE_ID  CHAR(10) NOT NULL,
    DESCRIPTION   VARCHAR(30),
    /* optionally */
    DEFAULT_VALUE /* whatever type you want */,
    /* end_optionally */
    PRIMARY KEY   (ATTRIBUTE_ID)
);

然后定义您的 SomeEntity 表，其中仅包含基本属性（例如注册表中的必填字段）：

CREATE TABLE SomeEntity (
    ENTITY_ID   CHAR(10) NOT NULL
    ESSENTIAL_1 VARCHAR(30),
    ESSENTIAL_2 VARCHAR(30),
    ESSENTIAL_3 VARCHAR(30),
    PRIMARY KEY (ENTITY_ID)
);

然后为您可能想要或不想存储的那些属性定义一个表。

CREATE TABLE EntityAttribute (
    ATTRIBUTE_ID    CHAR(10) NOT NULL,
    ENTITY_ID       CHAR(10) NOT NULL,
    ATTRIBUTE_VALUE /* the same type as SomeEntity.DEFAULT_VALUE;
                       if you didn't create that field, then any type */,
    PRIMARY KEY     (ATTRIBUTE_ID, ENTITY_ID)
);

显然，在您的情况下， SomeEntity 是用户。

A document-oriented database might be what you need.

If you want to stick to a relational database, don't take the naïve approach of just creating a table with oh so many fields:

CREATE TABLE SomeEntity (
    ENTITY_ID    CHAR(10)    NOT NULL,
    PROPERTY_1   VARCHAR(50),
    PROPERTY_2   VARCHAR(50),
    PROPERTY_3   VARCHAR(50),
    ...
    PROPERTY_915 VARCHAR(50),
    PRIMARY KEY  (ENTITY_ID)
);

Instead define a Attribute table:

CREATE TABLE Attribute (
    ATTRIBUTE_ID  CHAR(10) NOT NULL,
    DESCRIPTION   VARCHAR(30),
    /* optionally */
    DEFAULT_VALUE /* whatever type you want */,
    /* end_optionally */
    PRIMARY KEY   (ATTRIBUTE_ID)
);

Then define your SomeEntity table, which only includes the essential attributes (for example, required fields in a registration form):

CREATE TABLE SomeEntity (
    ENTITY_ID   CHAR(10) NOT NULL
    ESSENTIAL_1 VARCHAR(30),
    ESSENTIAL_2 VARCHAR(30),
    ESSENTIAL_3 VARCHAR(30),
    PRIMARY KEY (ENTITY_ID)
);

And then define a table for those attributes that you might or might not want to store.

CREATE TABLE EntityAttribute (
    ATTRIBUTE_ID    CHAR(10) NOT NULL,
    ENTITY_ID       CHAR(10) NOT NULL,
    ATTRIBUTE_VALUE /* the same type as SomeEntity.DEFAULT_VALUE;
                       if you didn't create that field, then any type */,
    PRIMARY KEY     (ATTRIBUTE_ID, ENTITY_ID)
);

Evidently, in your case, that SomeEntity is the user.

回复收藏 0 原文