我存储 facebook 个人资料 ID 的 SQL 表中 int 的长度应该是多少?

发布于 2024-11-09 17:58:14 字数 686 浏览 0 评论 0原文

我最常使用 cms,但之前没有太多直接使用 sql。我正在制作一个 Facebook 页面目录,其中保存页面 ID,Facebook 页面 ID 的长度有时为 10-13 位。那么我应该使用什么类型的 int 。我正在考虑 BIGINT 但它的长度应该是多少?

这是直观的表格。如果您可以建议字段的长度,我将很高兴。数据库表

这是我的数据类型和长度拿出来。但我很困惑这些是否有效:

  1. ID: 页面的数据库 id (int 5)
  2. page_id:Facebook 页面 id (bigint)
  3. page_name : Facebook 页面名称 (varchar 50)
  4. 用户名: 页面的用户名 (varchar 50)
  5. 喜欢: 喜欢的数量 (int)
  6. 链接:< /strong> 页面链接 (varchar 100)
  7. Time_added: 当前时间戳

Most often i work with cms but did not worked with sql directly too much before. I am making a facebook page directory where i am saving page ids the length of facebook page id is 10-13 digit sometimes. So what types of int i should use. I am thinking about BIGINT but what should be the length of it ?

Here is the table visually. I would be glad if you can advice the length of the fields.Database Table

Here is the datatype and length i comeup with. But i am confused if these are efficient:

  1. ID: Database id for the pages (int 5)
  2. page_id: Facebook page id (bigint)
  3. page_name: Facebook page name (varchar 50)
  4. username: username of the page (varchar 50)
  5. likes: number of likes (int)
  6. Link: Link to the page (varchar 100)
  7. Time_added: current timestamp

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

沫雨熙 2024-11-16 17:58:14

由于您无法控制 Facebook 将来可能会做什么,因此我会使用对变化最不敏感的类型。

由于您不会对 page_id 进行算术操作,因此我将其存储为 varchar。

As you don't have control over what Facebook might do in the future, I'd use a type that is least sensitive to change.

As you won't be doing an arithmetic manipulation to the page_id, I'd store it as a varchar.

颜漓半夏 2024-11-16 17:58:14

正确,您需要一个BIGINThttp://dev.mysql.com/doc/refman/5.6/en/numeric-types.html

我建议您的 VARCHAR 字段使用更长的长度。它不会造成任何损害,尤其是 URL 可能会变得很长。我可能会将两个 50 个字符的字段增加到 100 个,并在链接字段中允许 1,000 个字符。

Correct, you'll need a BIGINT: http://dev.mysql.com/doc/refman/5.6/en/numeric-types.html.

I'd recommend longer lengths for your VARCHAR fields. It won't hurt anything, and URLs in particular can get very long. I'd probably bump up the two 50-character fields to 100, and allow for 1,000 characters in the Link field.

梦年海沫深 2024-11-16 17:58:14

最简单的方法是将这些 ID 视为字符串或 15 个字符的 varchar。
使用 php 在处理 64 位整数时可能会导致问题。

性能差异可以忽略不计!

the easiest thing is to treat those IDs as string or varchar with 15 characters.
using php it can cause problems when working with 64-bit integers.

the performance difference is negligible!

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文