好的我最近问了一个问题,用户回答说我应该规范化我的数据库,但我认为我不应该这样做..
逻辑就像这样
在数据库中存储脚本,这些脚本是根据用户动态执行的。
例如,有一个脚本表
script_id | script_name
+----------------------+
12345 demo1
54462 demo2
90874 demo3
43058 demo4
现在是用户表
allowed_script_ids
+-----------------+
21345|90874
所以这里很简单,但是如果我删除说script_id
90874
会发生什么,但它不会从用户表中删除记录,所以他们建议我规范化数据库,但是如果用户可以访问1000个脚本怎么办?我需要1000条记录吗?或者我应该继续前进的方式?即使我为每次访问插入每个记录条目,我也需要在每次撤销该用户的访问权限时删除它们。
答案 0 :(得分:6)
1000行不是很多(在同一灯光下,也不是10,000,000),规范化数据库(即将用户与脚本相关联)非常适合这一点。如果你要连接一个字符串,除非你正在使用TEXT
(无论如何都是baaaaad!),你可能会遇到某种形式的字段长度限制,然后才能添加太多的脚本ID
所以,是的,我还建议您将其标准化到这个程度:
Script
script_id
name
User
user_id
...
User_Script
user_script_id
user_id
script_id
..然后每个关系都会进入User_Script
。
这比连接字符串要清晰得多,删除后,搜索/替换字符串。它将更快,更清洁,并帮助您以更加简化的方式实际查看数据库。
目前,您如何从数据库中获取所有脚本名称?使用上面稍微规范化的设计,您可以运行此查询,类似于:
SELECT `user`.`first_name`, `script.name` FROM `User_Script`
INNER JOIN `Script` USING (`script_id`)
INNER JOIN `User` USING (`user_id`)
答案 1 :(得分:2)
我会将这些数据标准化,是的。将用户与脚本相关联的第三个表是您应该做的。
如果用户有权访问1000个脚本,那么这肯定意味着在这个新的第三个表中有1000个条目,但这很好。你会发现数据更容易管理,如果像你说的那样删除了一个脚本,那么删除它在第3个表中的条目也是微不足道的,而不必在其中的分隔字段中使用笨拙的子字符串例程。用户表。
不要担心这会在新表中产生的行数,MySQL完全能够轻松处理表中数百万行,如果你创建了不错的索引,它将允许你加入这3行表格非常快,可能比执行子字符串匹配更快,因为你现在必须这样做。
答案 2 :(得分:0)
您可以使用状态位来指示使用的访问权限。通过这种方式,您可以获得使用唯一脚本ID索引进行快速访问的优势,而对于更新,只需重置布尔位
例如
user access
script_id user_id isGranted
----------------------------
21345 some_user_id yes
并且,如果您必须根据用户的偏好不断提供或访问脚本,那么您最初使用字符串并筛选用户可访问的可能脚本的想法可能效率低下
考虑这个
12|34|45|56|
如果您必须重复授予或撤消对脚本56的访问权限,该怎么办? 。 。 。你不能检索和处理这种重复动作的字符串,这是不必要的,也是低效的。在这种情况下,设置布尔位有助于节省大量处理问题