【问题标题】:How to implement this logic in database?如何在数据库中实现这个逻辑?
【发布时间】:2011-03-12 03:14:01
【问题描述】:

情况如下: 我有一个“用户”,它有很多属性。例如,“姓名”、“电子邮件”、“密码”、“电话”。

有些属性是公开的,例如“姓名”、“电子邮件”。 这些信息对访问该网站的人开放。

但有些,仅用于系统中的信任主体,例如“电话”。 这些信息对用户信任的人开放......(假设用户有一个信任列表,可以接受其他用户加入信任列表。)

还有私人的“密码”。 此信息仅供用户使用,其他人无法访问。

用户可以根据自己的需要更改不同的安全级别,例如,用户想要更改仅受信任机构的“电子邮件”,他们可以这样做。它还允许用户将他们的“电话”更改为公开。

我用三个数字来表示三个级别的权利。第一个是3,第二个是2,private是1。所以,我是这样设计数据库的:

User
id(PK) 
nameId(FK) 
emailId(FK) 
passwordId(FK) 
phoneId(FK)

Name:
id(PK)
name(String)
securityLevel(int)

Email:
id(PK)
email(String)
securityLevel(int)

Phone:
id(PK)
phone(int)
securityLevel(int)

Password:
id(PK)
password(String)
securityLevel(int) //It must be 1

问题是,我可以做到,但我的数据库会有很多表,有什么简单的方法可以做到吗?此外,有没有关于这种数据库设计的书籍推荐?谢谢。

【问题讨论】:

  • 除非您要允许您的用户“原始” sql 访问数据库,否则您应该在应用程序中处理这种访问规则。

标签: mysql database-design normalization


【解决方案1】:

您不需要为此使用不同的表,因为每个关系都是1-1 关系

如果用户有多个电子邮件地址,那么您确实应该将电子邮件和安全级别放在不同的表中。但是因为在这种情况下,每个用户正好有 1 个电子邮件、1 个姓名、1 个电话、1 个密码 - 每个用户只需要一个 1 行的表即可。

【讨论】:

    【解决方案2】:

    如果我理解正确,您可以简单地将所有这些信息放在两个表(用户和朋友)中,因为据我所知,用很少的查询获取较大的数据块比较小的块更有效具有许多查询的数据。你会有这样的东西:

    Users:
    id
    name
    name_perm // 1, 2 or 3
    email
    email_perm // 1, 2 or 3
    phone
    phone_perm // 1, 2 or 3
    password // Doesn't need permissions, always 1
    
    Friends:
    user_id
    friend_id
    

    当用户访问另一个用户的页面时,首先检查每个字段的权限级别。如果找到级别 2,您将查询 friends 表并检查当前用户 ID 是否是正在查看其页面的用户的朋友。如果找到,则用户是受信任的,并且可以显示 2 级安全信息。至于 1 级安全性,它非常简单 - 仅当两个 ID 匹配时才显示此信息。

    希望这会有所帮助。

    【讨论】:

    • 我从问题中收集到,问题在于允许用户自定义不同项目的安全级别,以及存储该信息的位置。
    • 哎呀,你是对的。我已更正我的答案以反映该要求。感谢您指出。
    • CSV-ing 朋友是完全错误的 - 朋友是唯一真正需要另一个表的字段,因此您可以编写联接并获取他们的安全级别...
    • 这严重失败了标准化:(
    • -1。这种方法相当有缺陷。请参阅 Konerak 和 joe snyder 的答案。这应该在前端处理。
    【解决方案3】:

    私有数据是否被隔离到单独的表中并不能解决如何防止未经授权的访问的问题。 MySQL 5.1 手册section 5.4.5 讨论了请求验证/权限,但如果您的数据库隐藏在无法直接访问您的表的 Web 应用程序后面,那么仅标准 Web 服务器安全性可能就足够了。您可能应该提及您正在使用的整个 os/server/db/language 包(LAMP、SAMP 等),以便有人可以为您的配置建议最佳安全方案。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 2016-02-14
      • 2022-06-10
      • 1970-01-01
      • 1970-01-01
      • 2011-08-08
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多