与其创建 15 个额外的充满稀疏二进制数据的列，我可以：
1) 使用前 15 个素数作为 15 个类别的索引
2) 通过将类别的素数相乘来存储数据，否则这些类别在 one-hot 编码中的值为 1
3）通过分解乘以唯一素数生成的值来检索数据
例如：1914 将产生列表 [2, 3, 11, 29]，它会让您知道具有 1914 值的用户具有属性 2、3、11 和 29，但没有其他属性。
我知道这是有限的，因为 BIGINT 只能保存前 15 个素数的乘积，但在某些情况下它是否仍然有用并在搜索数据库时节省时间？整个表将小 14 列。我想这不是关于机器学习算法，而是更多关于存储和检索数据。
我想你可以这样做，但如果你的目标只是在单个列中存储 15 个布尔值，那么你会不必要地使事情复杂化。与其费力地计算存储值的主要因素，不如将标志存储为位字符串？您的 15 个不同可能值的示例可以存储在单个 SMALLINT（2 字节）SQL 列中。检索该值后，您只需要使用一些基本的按位算术来提取记录中感兴趣的位。
“过早的优化是万恶之源”。——克努斯
你可以这样做，但为什么呢？如果您要将结果输入分类器，您绝对不想这样做：大多数分类器在此转换后会表现更差。如果您想在数据库中节省空间，那么这样做是没有意义的：硬盘可以存储数百 GB 的数据，因此区区 15 列可能不会产生任何明显的差异。
15 个额外的列是很小的。只需保存额外的 15 列，就不用担心了。您对其进行编程并解决它在下游引起的所有问题的时间成本几乎肯定会超过计算或存储以自然格式存储数据的微不足道的成本。
如果你真的拥有真正需要做一些优化的大数据，那么第一步就是测量：测量你实际消耗了多少空间/时间，以及总成本的主要贡献者是什么，然后关注关于优化那些主导因素。优化应该以数据为指导；否则，您可能会实施复杂的优化，这些优化总体上几乎没有什么区别，但会给您的数据处理工作流程增加不必要的复杂性和本轮。
简单地列举它们有什么问题？
即 0 = 苹果，1 = 香蕉，2 = 橙子？
根据一种热编码的定义，一次只能设置一种。无需处理位编码（即幂集）或素数编码（bag-of-x）。
但主要问题是您（计划）如何使用数据，而不是如何编码。稀疏数据可以通过压缩和稀疏格式紧凑地存储（这几乎可以简化为上述方法）。但是存储必须适合您的访问模式，否则性能会很差。