亚马逊 MWS FeedSubmissionID 类型？
通过 Amazon MWS API 提交 Feed 时，它会返回一个类型为 string 的 Feed 提交 ID，而它返回的所有数字似乎都是 int 类型。
问题：他们将其作为字符串是否有原因，并且始终将此值转换为int是否安全（我的意思是我可以确定他们不会在该 ID 中添加字母（如“123abc”）。
问题原因：如何将值存储在数据库中：char()、varchar() 或 int >？我想我们可以预期这个 ID 最终会有更长的长度，因为 ID 是递增的。因此 char() 将不起作用。接下来，varchar(how_long?) - 当前 ID 的长度为 10 个字符 - 为其添加一些额外的空间（例如 varchar(15)）？或者也许只使用 int - 搜索速度会更快，并容纳 ID，直到它增长到 bigint （如果有的话），或者只是使其成为 bigint 和最终？
这就是困境。
When submitting a feed via Amazon MWS API it returns a feed submission ID which is typed as string, while all the figures it returns seem to be of type int.
Question: is there a reason they have it as string and is it safe to always convert this value to int (I mean may I be sure they won't add a letter to that ID like "123abc").
Reason for the question: how to store the value in the database: char(), varchar() or int? I suppose we can expect this ID to have more length eventually, since the ID is incremented. Thus char() won't work. Next, varchar(how_long?) - currently the ID is 10 chars long - add some extra room to it (say varchar(15))? Or maybe just use int - will be faster in search and accommodate the ID until it grows to a bigint (if ever), or just make it bigint and final?
This is the dilemma.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
除非您打算在数学上使用它，否则我不会将此值转换为
int。你永远无法确定这一点。这是一个标识符，他们将来完全有可能开始向其中添加非数字字符。
我不是数据库专家，因此我无法真正建议您某些情况下最好的类型是什么。确实的一件事是，在对应用程序进行基准测试之前，您将无法判断哪个更快或更有效。
我的建议是将值存储为
varchar(25)，这将为您的未来提供足够的空间。我还建议您更多地关注应用程序的可维护性，而不是性能或效率。I would not convert this value to an
intunless you plan on using it mathematically.You can never be sure of this. This is an identifier and it is completely possible that they will start adding non-numeric characters to it in the future.
I am not a database expert so I can not really advise you as to what the best types are for certain scenarios. One thing that will hold true is that you will not be able to tell which is faster or more efficient until you benchmark your application.
My recommendation is to store the value as a
varchar(25)which will give you plenty of space for the future. I would also advise you to focus more on the maintainability of your application than on the performance or efficiency.