【发布时间】:2011-12-29 13:58:24
【问题描述】:
我是 MySQL 新手,正在寻找以下问题的解决方案:
我想用 cppcms 创建一个 CMS,它应该能够有模块。由于我想减少(意外)访问私人数据的机会,我想要一个处理数据访问和权限的模块。由于这个模块应该不知道其他模块创建的数据结构,我希望它通过 外键 关系推断数据所有者。我的想法是搜索将一行链接到用户 ID 的路径(通过外键)。
总结一下: 我想做什么
- 随机查询,确定受影响的行
- 为受影响的行确定与用户/用户 ID(现有表中的列)的关系/路径(通过外键)
- 仅返回可以确定关系且条件成立的行(例如,在相关查询中找到的用户 ID 与固定用户 ID 匹配,例如当前访问系统的用户)
(据我所知,外键只强制另一个表中存在一个键,但我假设的前提是,每一行都通过外键关系路径链接到用户)
我的问题/问题:
是否存在解决问题的现有解决方案/更好的方法?准备好的语句不会起作用,因为我事先不知道所有数据结构/查询。
如何获取外键关系?除了“SHOW CREATE TABLE”然后解析结果字符串还有其他方法吗?
如何在不修改行的情况下确定受影响的行?我想通过确定是否可以将其链接到当前用户(不是 mysql 用户而是系统用户)来过滤这个集合。
我可以尝试执行查询,然后选择受影响的行,如果我确定访问冲突,只需执行回滚吗?问题在于:如何对合法的行子集进行更改(例如,我尝试更改 5 行,可能只更改 2 行,如何只更改这 2 行)。一个想法是寻找一种方法来创建一个带有结果集的临时表。这个解决方案有几个缺点:临时表不可能有外键关系,它们会“丢失”。
P.S.:我正在使用 c++ 进行编码,因此我更喜欢与 cpp 兼容的库建议,但我愿意接受其他建议。在谷歌搜索时,我偶然发现了教义,我目前正在研究它。 P.P.S.:数据库引擎是 InnoDB(由于外键而不得不)
更新:第 2 部分的解释尝试: 我正在尝试过滤允许用户查看表格的哪些列。为此,我想通过外键在数据库中找到一个连接(通过外键,我确保我可以通过连接获取所有数据,它们提示我必须连接哪些列)。由于我计划使用更复杂的系统(例如论坛),我不想将所有数据加入临时表并对其运行用户查询。如果我可以将它与用户 ID 的连接映射,我宁愿评估用户查询并检查结果。例如,我可以使用它来强制只为用户创建的帖子启用编辑按钮。 (我知道有更简单的方法可以做到这一点,但我基本上希望允许程序员编写自己的查询,而不给他们机会编辑或查看他们不允许看到的数据。我的假设是程序员不是evildoer 但只是忘记了约束,因此我想在软件中强制执行它们。
到这里会很不错,但我有更复杂的需求。
首先是一个基本的例子。假设它像 facebook,一个人的所有朋友都可以看到他的照片。
pictures = id **userid** file (bool)visibleForFriends album
friendship = **userid1** **userid2**
users = userid
我想要发生的是:
- 程序员输入“SELECT * FROM pictures WHERE album=2”
- 系统获取所有匹配记录(例如一组 id)
- 系统看到外键 userid,尝试将当前 userid 与图片 userid 进行匹配,将所有匹配添加到返回的结果部分
- 系统通知特殊栏目visibleForFriends
- 系统尝试确定所有好友(SELECT userid1 FROM Friendship WHERE userid2=currentUserID join(必须阅读加入)SELECT userid2 FROM Friendship WHERE userid1 =currentUserID)
- 系统添加所有 visibleForFriends 为 true 且pictures.userid=Result from 5 的行。
虽然友谊部分是一些额外的代码(我认为如果 igot 从第一点开始就可行),我仍然需要弄清楚如何自动跟随外键来查看连接。忽略特殊的友谊情况(特殊情况),我希望系统也能解决这个问题:
pictures = id **albumid** file (bool)visibleForFriends album
albums = id **userid**
users = userid
现在系统应该去图片了。albumid ==> albums.id -> albums.userid ==> users.userid.
我希望这些例子能稍微澄清一下这个问题。一个问题是,在示例的第一点(程序员查询输入)中,我不想让“DELETE *”对用户不拥有的任何东西生效。所以我必须过滤哪些行要实际删除。
【问题讨论】:
标签: mysql foreign-keys innodb foreign-key-relationship multi-tenant