我发现以下博客文章的评论建议不要使用mediumint:
即使在MySQL中,也不要使用[24位INT].这是愚蠢的,它很慢,实现它的代码是一个爬行恐怖.
4294967295和MySQL INT(20)语法Blows
stackoverflow的答案还指出SQL Server,Postgres和DB2不支持mediumint.
MySQL中的tinyint,smallint,mediumint,bigint和int有什么区别？
应该避免使用中,还是应该在最能代表我存储数据的情况下继续使用？
我有一个多用户网站，想为每个用户发布一个单独的 icalendar 订阅文件 (.ics)。
我们的 apache 服务器配置为仅通过 https 提供访问。
我考虑过的一种方法是，当用户第一次询问他们的订阅 URL 时，生成一个长的、随机的密钥并将其包含在 URL 中。然后该键的散列将存储在数据库中。示例：https : //site.com/calendar/user_id/dQXeCgtiOmZ5lAXoedmujiuA47VmCgA5OIfE6vZ8BhJT3Rxh20b9Ci.ics
我们 cakephp 应用程序中的所有页面都需要用户登录（显然需要登录页面）。我会将 ics 文件配置为也不需要用户登录，而是仅在提供正确的密钥（针对散列进行测试）时才显示。
这种方法有什么缺点吗？
我应该使用不同的方法吗？
我已经看到人们在订阅 URL 中包含基本身份验证的示例，但这听起来会更糟。示例：https://user:password@site.com/calendar/user_id
这是在学校环境中部署的，因此 iCalendar 订阅包含相当平凡的内容，例如课程时间表和作业截止日期，但我仍然希望保持安全。