推荐的 SQL 类型和长度
我是 SQL 新手，正在开发一个存储多人游戏帐户信息的表。我想知道存储大量数据的最有效方法是什么。
对于这三个专栏，我想，我已经想通了：
username: VARCHAR(20)
password: VARBINARY(16) for MD5-Hashes
email: VARCHAR(70)
你对此有何看法？
除此之外，还会有很多更灵活的数据（保存游戏数据），我无法真正预测。将此数据作为 XML 数据保存在 TEXT 类型的字段中是否明智？或者有更好的方法来保存它（使用 PHP）？
谢谢。 抢
I'm new to SQL and I'm working on a table that stores account information for a multiplayer game. I'm wondering what is the most efficient way to store a lot of data.
For these three columns, I think, I've already figured it out:
username: VARCHAR(20)
password: VARBINARY(16) for MD5-Hashes
email: VARCHAR(70)
What do you think about this?
Besides that, there will be a lot of more flexible data (savegame data), which I can't really predict. Would it be smart to save this data as XML data in a field of type TEXT? Or is there a better way to save it (using PHP)?
Thanks.
Rob
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
一些建议：
与您的具体情况更相关的注释：
A couple of advices :
A note more related to your specific case :
不要将 xml 存储在文本字段中。使用不同的数据库引擎 - 一种允许您存储任意非结构化数据的数据库引擎。 （查找nosql）
Don't store xml in a text field. Use a different database engine - one that lets you store arbitrary unstructured data. (Look up nosql)
我同意，当您还包含域名时，电子邮件地址长度太短。您可能需要了解 Gmail 的最大长度是多少。
此外，您最好将游戏数据保存为文件并将路径保存在数据库中。表上有大量数据总是一个坏主意。
当您在 mySQL innoDB 存储引擎中使用索引时尤其如此，其中使用聚集索引并且行内容存储在索引中。该索引将变得非常大并且效率低下。
此外，涉及 SELECT/INSERT/UPDATE 的查询也会变得非常慢，尤其是后 2 个。
I agree that the email address length is too short when you include the domain names as well. You may want to follow what the maximum Gmail length is.
Also you might be better off saving the game data as a file and saving the path in the database. It is always a bad idea to have large data on the table.
This is especially true when you use indexes in the mySQL innoDB storage engine, where clustered index is used and the row contents are stored in the index. The index would become very large and inefficient.
Also queries involving SELECT/INSERT/UPDATE would become very slow as well, especially the latter 2.