什么时候元组长度太长？
这是我最大的关系的逻辑模式：
{(id, uName, Supply, Score,playerType, storageSupplies, SupplyDrop, barracks,armourDepot,hangar,droneHangar,storage,attraction,defense,infantry,vehicles,air,fuel ,explored,morale,cash,population,tax,food,aSector,cSector,iSector,XP)}
如您所见，每个元组都会很长。随着属性的添加，这开始变得非常麻烦。问题是，只存在一对一的关系，因此虽然通过将这种关系分解为更小的、元相关的关系来帮助组织并避免混淆，但这不会增加更多的开销吗？或者说，当这个关系实际上最多有数万个元组时，我是否应该担心 mysql 的效率。
Here is a logical schema for my largest relation:
{(id, uName, supplies, score, playerType, storageSupplies, supplyDrop, barracks, armourDepot, hangar, droneHangar, storage, offensive, defensive, infantry, vehicles, air, fuel, explored, morale, cash, population, tax, food, aSector, cSector, iSector, XP)}
As you can see, each tuple is going to be very long. This is starting to become very cumbersome as attributes are added. The thing is, there is only ever a 1-to-1 relationship so while it would help organisation and avoid obfuscation by breaking this relation up into smaller, meta related relations, wouldn't it add more overhead? Or should I not worry about mysql efficiency when this relation will have tens of thousands of tuples at the most, realistically.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
1) 假设你的表最多有 10k 行，很少更新，也很少读取（与数据库中的其他实体相比） - 你是对的，效率不会有很大的好处，但是......
2）每一点都很重要；例如，对于这么小的表，它的大部分可以保存在内存中，并且您将拥有非常快的选择；如果很多属性大多为 NULL，那么拆分表会减少表的大小，并为其他缓存释放 RAM；更新时减少必要的 I/O（通常使事物更具可扩展性）。代价是复杂性略有增加（对于更新，SELECTS 可以使用 VIEW）。
3) 拆分一对一关系的“开销”是一种误解；这在很大程度上取决于工作负载 - 您可以构建更喜欢将事物分解为两个较小表的案例，并且可以构建受益于将数据存储在一个表中的案例。
1) Assuming your table is max 10k rows, rarely updated and rarely read (compared to other entities in the database) - you are right efficiency will see no great benefit, however...
2) Every little bit counts; for example with table this small most of it can be kept in memory and you will have very fast SELECTS; if a lot of attributes are mostly NULLS then splitting the table would reduce the SIZE of it and would free RAM for other caches; reduce necessary I/O when updating (generally make the things more scalable). The expense is the slight increase of complexity (for updates, SELECTS can use a VIEW).
3) 'Overhead' for splitting 1-to-1 relations is misconception; it largely depends on the workload - you can construct cases that prefer things broken down into two smaller tables and you can construct cases that benefit from having the data stored in one table.
效率取决于 MySQL 版本和您使用的存储引擎。但您应该知道，这样做会增加要缓存的数据，而这可能是不必要的。
例如，如果我们添加用户的地址数据，
Users表可能会增加，而这些数据可能并不经常需要，因此，将其拆分为 2 个表：Users和 < code>Users_address 会更有效，因为如果表 Users 被大量读取，它可能会被缓存。还有其他考虑因素，例如维护和索引工作。
Eficiency depends on the MySQL version and the Storage Engine you are using. But you should know that doing this will increase data to be cached that might not be necesary.
For example, a
Userstable might increase if we add address data of users, and that data maybe is not needed frequently, so, spliting it into 2 tables:UsersandUsers_addresswill be more efficient becouse if the table Users is heavily read it could be cached.There are other considerations like maintenance and index work.