【问题标题】:Database Design Flaw数据库设计缺陷
【发布时间】:2012-02-27 02:07:12
【问题描述】:

我很难解决一个设计缺陷,我真的希望社区可以帮助我。我目前的设计是:

SUBMISSIONS table

submission_ID (pk, int)
company_id (fk, int)
product_id (fk, int)
vendor_id (fk, int)
category (VARCHAR)
price (INT)
approval_status (TINYINT)
notes (MEDIUMTEXT)

VENDOR table

vendor_ID (pk, int)
vendor_name (VARCHAR)    

COMPANY table

company_id (pk, int)
company_name (VARCHAR)

PRODUCTS table

product_id (pk, int)
product_name(VARCHAR)

我的项目是供应商向公司提交产品以供审核。这些公司有一个仪表板,其中包含一个网格,可以提取供应商提交给他们的所有产品,他们对其进行审查,然后批准或拒绝使用这些产品。

我的问题是......当拉起待处理的产品网格时,我按其类别对提交进行分组。这样,如果一个类别中有 100 个产品(这很常见),他们只需要查看该类别,而不是单个产品。他们可以在从网格弹出的模式窗口中输入关于提交组的注释。窗口的 id 是组中的第一个提交,该提交是存储笔记的位置。我主要担心的是,他们可以单独批准或拒绝来自该组的提交,所以当他们为该组输入附加到该组中的第一个提交的注释然后他们拒绝该第一次提交时会发生什么。现在,当他们再次登录时,该组的所有注释似乎都消失了,因为这些注释附加到第一次提交,现在位于他们的拒绝产品文件夹中。必须有一种更好的方法来跟踪最初对组的注释,然后将这些注释提供给以后的个人提交,但我没有看到我有限的数据库设计技能。在这一点上的任何建议都是有帮助的。

【问题讨论】:

  • 您可以在提交中包含多个产品吗?
  • 另外,如果在模态中输入注释,是否表示所有显示的行都被拒绝?
  • 每次提交的产品只是一个有自己价格的产品。在模式中输入注释以简单地跟踪公司是否要批准产品。在大多数情况下,一个组中的所有提交都将被一起批准或拒绝。该类别基本上是一起批准或拒绝的。但有时一个提交将被拒绝,而该组中的其他 99 个将被批准。在我目前的设计中,如果一个提交/被拒绝的产品是第一个提交的,那我就完蛋了,因为在评估提交组时以及以后参考时,这些注释都会丢失。
  • "在大多数情况下,一个组中的所有提交都将被一起批准或拒绝。"当你有更多经验时,你不会这么说。你会说“不是一个组中的所有提交都会被一起批准或拒绝。”

标签: mysql database database-design


【解决方案1】:

我的建议是

  • CREATE TABLE 类别(id int AUTO_INCREMENT PRIMARY KEY,name VARCHAR(250) not NULL,UNIQUE INDEX(name),note MEDIUMEXT)
  • SUBMISSIONS 中将category (VARCHAR) 替换为category (fk, int)
  • notes (MEDIUMTEXT) 放入SUBMISSIONS
  • 现在将注释附加到类别表

【讨论】:

  • 非常感谢您的反馈。我认为这已经接近我所需要的了。我只是对如何将其与提交表联系起来有点困惑。当供应商提交产品并在提交表中创建一行时,您是否建议我也在类别表中创建一行。然后所有后续提交都会检查类别表,如果存在条目,则在该类别的提交中创建一个 FK 条目?我正在脑海中运行一些场景,所以如果我知道这就是你使用这个设计的地方,那将会很有帮助。再次感谢...
  • 投稿不只是针对某个类别,所以这行不通。
  • @TheGeekYouNeed 显然您需要为单个提交创建一个类别。
  • @DevNewb 这正是我的意思:如果你想一想,注释总是属于一个类别 - 但也有可能发生,一个类别只有一个条目.
  • 非常感谢你们。这正是我一直在寻找的。它完美地回答了我的问题。
【解决方案2】:

如前所述,您应该为类别创建一个表,提交将存储一个类别ID。

您正在执行查询以检索模式中显示的所有项目。当您更新组中的提交时,您还必须更新所有记录。

所以基本上你的更新声明是:

UPDATE Submissions
SET notes = @notes, approval_status = @approval_status
WHERE (same criteria from your select statement)

由于您已经缩小了在模式中显示的范围,我假设您知道如何将值发送到 SQL 语句的参数。

【讨论】:

  • 您的模式增加了用户友好性,但不要忘记,一个类别将包含许多产品。因此,输入的注释将附加到类别/产品组合的提交,而不是类别。例如,您有一个食品类别。因此,您在该类别中已经批准了许多项目。您的用户使用您的应用程序来批准/拒绝未经批准的食品。出于某种原因,他们被拒绝了;拒绝并不适用于整个类别-您已经在那里批准了食品。拒绝属于食品类别中产品的每次提交。
  • +1 以获得所有见解和帮助。再次感谢。因此,我认为您所说的是使用此新模式,所有提交都将与产品/类别组合相关联,因此,如果该组合中的产品被拒绝,它仍将与已正确批准的产品共享相同的注释?如果这就是你所说的,我可以接受。只要公司可以查看他们批准的产品并查看有关他们为什么批准该产品的说明,那么它就会起作用。您是否担心他们无法在被拒绝的产品上附加特定说明?
  • 只要重新阅读你的评论,我想我明白你在说什么了。实际上,我已经有另一个表,其中包含 4000 个产品类别,因此使用此处提出的新模式,我将有一个提交/注释表,该表将具有类别表的外键。听起来您担心的是注释将附加到整个类别,但我不会那样设置。注释将附加到提交/类别组合中。
  • 嗯,不完全是。当您更新 SUBMISSIONS 表时,您需要根据用于为模式选择项目的条件进行更新。只有那些提交的内容会共享相同的注释。我建议您为具有批准状态 = 未批准的提交的模式选择类别。然后,当您更新您的数据时,您只更新其approval_status = 未批准(或任何适当的状态)和CategoryID = 未批准提交的类别的提交。
  • 是的,这正是我所关心的。无需在与模式中选择的内容无关的记录上添加注释。
猜你喜欢
  • 2011-07-11
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2011-08-29
  • 1970-01-01
  • 2021-10-13
相关资源
最近更新 更多