这是一个涉及Java和MySQL的设计问题。Java和MySQL中多标记布尔标志与多路复用整数（位）的效率
客户端需要添加14个布尔标志（T/F）来跟踪现有类/表中的一些新信息。
我可以将这些标记添加到现有的表，或者我可以创建一个新的类和表仅用于此数据。将14个布尔标志添加到现有表格中会给出相当多的属性，我倾向于避免这些属性（特别是如果标志数量随时间增加）。创建一个新的类/表更清洁，但在这种情况下它真的有必要吗？另外，我可以使用一个16位的整数与掩码来复用数据，然后我只将一个变量添加到现有的类/表中。
我的主要问题是：将14个单独的布尔变量存储在MySQL数据库中并将它们加载到类中是否更有效，或者是否更好地存储单个整数，然后（用Java）复用标志使用位操作（即掩码）？
第二个问题，如果单个标记更有效，那么在一个表中包含很多属性还是将它们分开会更好？在一个已经有很多实体的表中存储大量布尔标志会有什么损失？
如果主要问题的答案是“整数+多元”，那么第二个问题就变得没有实际意义。
谢谢。
-R
您可以使用EnumSet。这是模拟标志的最好方法 - 设计中更清晰，并且与int具有几乎相同的性能。可以很容易地转换为int（读取/放入数据库）。有关更多信息，请参见“Effective Java”一书，“EnumSet”一章
在主要问题中，您问什么更有效，哪些更好。这使答案复杂化。
从开发人员和DBA的角度来看，单列是更有效的解决方案。因为您可以腾出空间并使用蒙版，因此可以提高插入和更新的性能。
从数据分析师的角度来看分列的是更高效的解决方案，每列都有明确的作用。
由于去来回我，我喜欢口罩 - 莱斯改变代码 - 更好的管理（有限整数容量是这里的风险）
我个人喜欢有单独的列。我唯一可能考虑屏蔽的地方是数据库和应用程序在极端条件下运行，或者在内存和存储空间不足的存储设备和低端存储设备上运行。
1-空间不应该是一个考虑，除非类/表可以增长到巨大的数量。 来模拟布尔标志一个微小的int（1）就足够了，你需要的只是0/1值。
2-对于任何想在桌面上执行查询或想要使用该查询编写报表的人，变得更加困难。如果你的客户端访问数据库，我相当肯定在大多数情况下屏蔽是不可接受的。
3-这将是更难在此列建立索引在需要的时候，如果这将是不可能的（基于数据库）
4-工作越来越编写更多的代码不应该一个问题。你现在工作得更多，但你将来工作得更少。认为这是程序员/ dba的更少的工作只是一个幻想恕我直言。这里有一些注意事项：
a-维护代码和写入数据库查询将会更困难。也许你现在在你的java代码中做了所有事情，但你永远不知道未来会如何。
b-使结构变化变得更加困难。如果客户需要移除两个标志并添加4，该怎么办？你是否保留在数据库中保留已删除标志的原始两位并添加4位？或者您将它们用于两个新标志，然后再添加两个位？这将如何影响已写入的代码？以及追踪所有地点并在代码中实际进行更改会有多容易？
在一个小应用程序中，这不是一个大问题。但应用程序随着时间而增长如果桌子被广泛使用，这是非常危险的。如果你的代码使用了第7和第8个标志，并且它们被移除了，并且决定（由其他程序员说）重复使用相同的地方，任何用于访问第7和第8位的代码都将继续运行（错误地），直到注意到。它可能已经做了有害的事情，直到问题被发现并修复。如果你有单独的列，并且你删除了它们，那么错误就会在第一次使用该代码时弹出到表面，因为列不会在那里。
c-毫无疑问，制作升级数据和/或更改dba结构的脚本将变得更加困难。有经验的dba不会坐下来一个接一个地写列名，并且会使用它的工具来生成脚本。通过位操作，他将不得不手动工作，并且在各种选择/更新中产生的表达式中没有错误
5-上述所有内容均与数据库相关。一旦它到达你的应用程序，你是免费的。 您可以从数据库中读取16个标志并产生整数，从现在起，您的代码可以使用位操作，并且可以节省时间（通过编写处理它的函数并使用它们）。我个人认为在这里最好不要这样做，但无论如何它是你的选择。
我知道我没有专注，我可能在这里和那里重复。但我也希望我能够帮助你看到长期的考虑因素，这将有助于你为你的案例做出正确的选择。
原来我不能使用布尔类型。客户改变了规格，因此需要多种选择。结束在类中使用int []数组，然后从int []转换为单个字符串（并返回）。由于接口要求，将字符串存储在数据库中。工作很好。 – Huntrods