我正在为现有数据库进行升级,该数据库的设计没有任何代码来实现正在考虑的设计 . 现在,我已经在代码中实现数据库设计方面遇到了困难 . 我确定它是否是数据库设计的问题,或者我是否根本没有找到正确的解决方案来解决需要做什么的问题 .
基本逻辑规定如下:
-
用户通过座位访问在线培训 . 用户可以拥有多个席位 .
-
座椅由公司购买,与产品有多对多的关系 .
-
产品与模块具有多对多关系 .
-
模块与课程有多对多的关系 .
-
课程是最终用户对其培训的访问权限 .
-
为了使水变得混乱,由于某种原因,一些用户有多个包含相同产品的座位 .
-
认证基于每个产品进行,而不是基于每个座位 .
-
用户与课程之间存在多对多关系,可以存储课程的当前状态或分数 .
-
用户在完成产品所有模块的所有课程后,即可对产品进行认证 .
-
了解特定模块的所有课程何时由用户完成也很重要 .
-
有些座位将用于重新认证,这意味着之前已通过产品认证的用户可以注册并参加重新认证考试 .
-
由于规则11,用户可以并且将拥有多个认证记录 .
-
编辑:当用户完成课程(分数优于80%)时,用户(根据当前的业务逻辑)完成了所有产品的课程和包含课程的所有席位 .
当我或多或少地描述了当前设计和业务逻辑时我遇到的麻烦是我无法找到一种方法来有效地确定用户是否已经认证特定产品和座位与他们何时没有 . 我一直在试图确定哪些产品的座椅已经为用户认证,哪些没有 . 部分问题是因为如果他们目前在不同的座位下注册了同一产品的多个,那么我只需要计算一次产品 .
下面是涉及的架构部分的副本 . 任何有关如何改进设计或在代码中绘制关联的建议都将受到赞赏 . 如果重要,该站点 Build 在LAMPP堆栈上 .
您可以在此处查看数据库架构的相关部分:http://lpsoftware.com/problem_db_structure.png
4 回答
您正在寻找的是relational division不是直接在SQL中实现,但可以完成 . 搜索谷歌的其他示例 .
在快速查看模式之后,我认为您可以做的一件事就是创建一个'to_be_certified'表 . 将产品分配到席位时(填充product_seat_rtab时),使用user_id,product_id和seat_id填充它 .
在将记录添加到certification_rtab表时,删除“to_be_certified”表中的相应记录 . 这样您就可以轻松访问所有经过用户认证且非用户认证的产品 .
要删除重复的product_id,您可以按product_id进行分组 .
您需要更改lessonstatus_rtab表:
然后,您可以查询用户拥有席位的每个产品,是否经过认证?这假定他所获得的课程数量,例如50%或更高,与产品所有模块的课程数量相同 .
更新:
我已经进一步考虑了这个问题,并考虑是否允许更好地工作以简单地删除user_seat_rtab表,然后使用等效的certification_rtab表(可能已重命名)来保存有关用户座位状态的所有信息 . 这样,在用户,他们的座位,座位内的每个产品以及用户是否已经认证特定产品和座位之间 Build 了直接关系 .
因此,我将以下更改应用于随问题发布的架构:
进一步规范化这种新结构的另一种方法是做这样的事情:
我不确定这是否可以解决问题,或者它是否会在引入新问题时稍微改变问题的性质 . 那么,有没有人有任何其他批评或建议?