公告栏-数据库优化

Question

Closed. This question needs to be more focused. It is not currently accepting answers.

---

想要改进这个问题？通过编辑这篇文章来更新问题，使其仅关注一个问题。

2 年前已关闭。

Answer 1

第一部分

于美国东部时间 10 月 10 日 12 月 9 日 01:00 修订

已查看您的 DDL。好的。我们需要退后一步，首先组织您的数据库。这将解决您一半的问题（您的 SQL 将直接、快速、索引更少、不需要临时表）。有一段时间我想，啊哈，你有你的专栏，它一定很稳定，但没有机会。从头到尾，好吧。看一下这个实体关系图（在我们得到正确的 ER 之前，在数据模型上工作是没有用的，即实体、关系和属性），并检查它是否正确。

• 方法是回答以下问题（简短的回答即可）。这些问题澄清了实体和业务规则。如何理解一般数据库，特别是您的数据至关重要。您已经走了很长的路，靠自己的力量，所以我们可以从那里开始。

• 我认为▶这篇文章◀ 可能对您有所帮助，以了解应遵循的正式阶段；我们在这里短路了。

• 最重要的是，完全彻底地忘记功能和任何编码要求。数据必须独立于应用程序进行建模，就像数据一样。函数建模是一门不同的科学。首先做对；然后得到另一个权利；两人一起演奏优美的曲子。尝试将它们塞在一起；

为了简洁起见，也为了任何人阅读本文，我使用了封闭和开放部分；当一个开放项目（讨论）被关闭时，我会使其简洁，并将其移至“已关闭”部分。保持编号，因为有时事情会再次困扰我们。您可能希望这样做，甚至删除您这边的讨论。

漂亮图片的链接在最后。

抱歉：编辑不起作用；子编号不一致

已关闭问题

1. users.bb_locations_csv 是用户和位置之间的多对多关系：
   • 每个元素都应该是离散列、离散行中的条目
   • 一个用户可以拥有多个位置并且一个位置可以拥有多个用户是多对多
   • 阅读▶这篇文章◀ 讨论如何处理以及处理到什么阶段
   • 在这个逻辑阶段，这只是一个::n关系，正如我所画的，你现在可以忘记它，简单地说，当我们到达物理阶段时，它就会被提供。
   • 相信我，我将提供不比 ...WHERE IN () 更复杂的代码来实现您声明的目的。
   • 转念一想，如果我折断了你的手指，你打字会更慢，所以我最好不要
   • 好的，您的应用程序是基于浏览器的，并且页面是动态的（我的建议是针对需要修改的静态页面）；继续使用复选框。
     .
2. users.bb_categories_csv 是用户和类别之间的多对多关系
   • 同上。
     .

3. 已确认：没有用户，公告（bbs）就不存在；用户发布公告，整个周期就开始了；然后邀请回复和评分。

   3.1 已确认：实际上只有一个公告板，并且它在数据库中不作为事物存在。

   3.2 已确认：该组织永远不会有多个公告板，并且分类和类别都由类别表/函数充分处理

4. 已删除。

5. 已确认：公告和回复之间的区别在于，回复依赖于公告而存在，它们没有标题，并且不按位置或类别进行分类，因为它们依赖于公告本身而存在。

6. 已删除。

7. 已注意到评论。已解决。

7.1.对于另一用户提交的每个公告，每个用户可以发布多个回复。

7.2.对于用户提交的每个公告，该用户可以发布一个或多个回复。

7.3.已删除。

7.4.已删除。

数据模型现在允许每个用户在每个公告上有多个回复；包括提交公告的用户。

.
8.已确认：每个用户最多可以在公告上发布一个评分（可以撤销/更改）
.
9. 已确认：每个用户最多可以对一条回复发表一个评分（同上）

10.1.给定：用户名来自组织，是标识员工的唯一名称。例如，电子邮件是 [email protected] - 身份验证是使用 ldap 完成的需要连接并检索有关员工的其他信息

• 确认：用户名是一个很好的标识符

10.2。已确认：名字、姓氏...出生地等保留为（传统）列，以确保人物不重复。
.
11. 鉴于：目前，我们可以通过组织内普遍熟知的临时名称来识别我们的办事处，因为我们只有大约 3 个主要办事处和许多外地办事处。例如华盛顿特区或弗吉尼亚州办事处。总的来说，我认为我们会尝试将总数保持在 20 以下。我还想记录每个位置的确切地址，因为这可以用于唯一地标识用户的办公室。

• 提供：StateCode+Town 作为PK； IsMainOffice 作为布尔值。

.
12. 已确认：Category 的 Description 和 Name 为必填项。
.
13. 鉴于：用户将无法向某些类别发帖。只有具有足够高权限的用户才有权向某些类别发帖。

• 提供：User, Location, Category 中的Permission 是评估此类权限的方法。

.
14. 已确认：Location.Administrator 是Location 管理员的UserId。
.
15. 鉴于：永远只需要喜欢或不喜欢。我认为不需要保持中立立场，因为这与不投票是一样的？点赞似乎与诚实发布的公告回复更相关。也就是说，“我看到了你的回应，我不会写自己的回应，而是同意你的观点——现有的公告板在某种程度上是组织中的社会方面，我认为喜欢和不喜欢/同意和不同意会产生一定程度的争议，从而鼓励参与。然而，喜欢或不喜欢公告可能并不总是完全合适的。

15.1 提供：Like 作为 BulletinRating 和 ResponseRating 中的布尔值。这将需要对每次访问进行解释。
15.2.当它不再是布尔值时，可以将其更改为RatingCode，并实现为查找表。然后，名称由连接确定，并消除解释。我在第一个数据模型中画了这个，这样你就可以明白我的意思
15.3。在第二个数据模型中删除。
.
16. 已确认：每个用户都有一个家庭位置（除了他们感兴趣的位置列表）。
.
17. 已确认：按照 (13) 的许可。
.
18. 已确认：根据数据模型，可能需要进一步的权限。

18.1.如果您现在这样做，您就不必担心组织何时决定阻止某个人发布响应或公告，或者对他们进行评级；并希望昨天实现该功能。

18.2.即使您没有实施它，也要在您实施的价值观之间留下差距。
.
19 已确认：公告是关于位置。

19.1。已确认：没有位置的公告

19.2。已确认：没有公告没有位置。

19.3 已确认：没有用户（声明性）就没有公告。但到目前为止，我们还没有办法限制该User；因此，任何用户都可以为任何位置插入公告（您可以将其限制在代码中，例如位置每个用户都感兴趣

已确认：没有公告且评级为用户，则不存在BulletinRatings。

19.4 已确认：没有公告就没有响应

19.4 已确认：没有响应和响应就没有响应评级 。评级用户

。但是，可以有独立的用户、位置和类别。

20. 如果您不介意，我将提供命名约定等。它们应该是不言自明的，并且只有当您开始编写 SQL 代码时，该值才会显示。如有不妥请追问。首先，所有名称都是单数。混合大小写更容易阅读（SQL 语言应该使用大写）。

20.1.我的经验是 table_name 相对于 tableName 来说是真正的技术形式，用户不喜欢它们；一致的混合大小写是每个人都喜欢的。这是无法改变的事情之一，因此请谨慎选择。
.
21. 对于您需要将表格分组在一起的需求（这很好），请记住这是一个物理问题。在逻辑数据模型级别，表具有正常的名称，不受物理问题的影响。想象一下，物理表的前缀类似于（请使用大写）：
- REF_ 用于参考（例如用户）和查找表
- BUL_ 用于公告系统
.
我无法用大写字母命名表格？我不知道为什么。我不知道为什么我不能使用大写表名。与使用 MyIsam 数据库表有关吗？

通用约定是SQL语言用大写字母表示；我使用过的每个报告和管理工具都会生成这样的 SQL 代码。所以我们不能使用大写。仅小写或混合大小写。因此，选择归结为 table_name 或 TableName；我们需要某种分隔符。由于已经提供的原因，我强烈建议混合大小写，大写，而不是前导字母不大写的 OO 风格。

.
22. rank（全部）可以直接从数据库中导出（记住，在数据建模期间不要担心代码）。如果存储的话，就是Normalization error；重复的列；必须保持最新；这可能与派生值不同步；这称为更新异常。第五范式消除了更新异常。这是我的最低标准化水平，所以这就是你将从我这里得到的。

22.1。我根本不干涉排序顺序或受欢迎程度问题；事实上，听上去你还没有关闭该功能。我只取出冗余数据，即排名列，作为标准化过程的一部分。

22.2.这是▶快速教程◀ 关于 RANK() 运算符（众所周知）。它不是 ANSI SQL；它是 Oracle 和 MS 的扩展。然而，如果您了解子查询，则不需要它，这就是 Sybase 没有它的原因。我怀疑 MySQL 有它，所以你需要了解一下它。了解标量子查询是先决条件。 Sybase 语法，因此请输入分号等。请随意提出具体问题。
.
我从未见过这种写 Rank = (SELECT...) 的方法与 Rank 的 (SELECT ...) 相同吗？

我已经为此发布了单独的答案。

.
22.3。需要了解为什么，完全没有问题。只有小孩子才会盲目地遵循简单的规则，而你肯定不是其中之一。
.
23、确认：users.total_bulletins是多余的；可以推导出来。已删除。
.
24.你所有的PK都是Id。您还没有厌倦在代码中迷失吗？忘记在所有移动的东西上粘贴Id物联网PK，让我们看看您的用户如何识别他们的实体；哪些实体是真正独立的，哪些实体依赖于独立实体。

24.1。切勿使用 Id 或任何此类形式。如果是 PK，请使用完整形式。

24.2.调用location_id，location_id，无论在哪里，包括PK表。例外是当你需要展示角色时。这将在数​​据模型中变得清晰。
.
25. 您没有声明性引用完整性，没有定义外键。出于多种不同的原因，这是个坏消息。一旦这些问题得到澄清，请添加它们。DRI 意味着尽可能多（如果不是全部）在 SQL 中声明完整性。 ISO/IEC/ANSI SQL 标准允许这样做，但市场的免费软件并未提供该标准，并且正在慢慢迎头赶上。这意味着服务器不允许在FK表中添加行，除非父表中存在PK。 MySQL 最近为外键提供了 DRI。对于FK，请参考▶这个文章◀。

25.1。对于 CHECK 约束和规则，您必须在代码中实现它们。

我的外键就像，users-id(fk) = users.id(pk) 除了我所做的之外，我不知道如何添加它们，但一旦我知道如何添加，我肯定会这样做。

这不是将它们添加到您的数据库中；而是将它们添加到您的数据库中。这只是数据操作语言中的 WHERE 子句中的引用列，而不是数据定义语言。添加它们，以便它们在数据库/服务器级别运行，意味着按照链接的文章在 DDL 中声明它们。然后MySQL将阻止将一行插入到父PK不存在的子表（FK）中。这就是引用完整性。如果在DDL中声明，则为声明性引用完整性。

除了执行RI之外，大家都可以看到定义：用户可以使用报告工具来访问数据库并从数据库中报告，而无需找人编写报告。

是的，据我所知。确认于▶此网站◀。我为子查询提供的代码使用 DRI，因此我们可以对其进行测试并尽早将其排除在外。您必须检查您的 MySQL 的特定版本。

二十五。 注释已注明。我不是 MySQL 专家。是的，这些都是你必须自己解决的问题。总的来说，从我的观察来看，MySQL 是没有腿的；对于任何 SQL 风格的东西，你都需要 InnoDB。

但不要让它阻碍你。现在使用 Engine=MySQL，不使用声明式 SQL，并继续使用数据模型和子查询。在后台处理 InnoDB。

要明确的是，我提供的 DDL 应该适用于 MyISAM（并且在 DRI 部门“不执行任何操作”，直到获得 InnoDB）。

.
27. 鉴于：我重新考虑了公告的排序要求。用户可以按时间顺序排序——简单、有意义。用户可以按照最新回复公告的日期对公告进行排序。然后我们就可以忘记排名，并且应该很容易按照公告的最后回复时间按时间顺序对公告进行排序？你有什么想法。

是的。这是明智且相当普遍的，大多数人都理解时间顺序。您将不得不弄乱他们在搜索窗口中选择的过滤器（选择：位置或列表；选择：类别或列表；选择：我的公告或全部）。




开放问题

（无）

数据模型

好的，假设您的 ERD 没有问题，并实现了所有已解决的问题，我已经对数据进行了建模，并准备了第五个数据模型（2010 年 12 月 9 日）供您审核。我确实需要关于此的更多反馈、问题等。我很难接受这件事已经完成了。也许最好开始为您的问题领域编写真正的代码。

链接

▶IDEF1X 符号链接◀ 在阅读数据模型之前，您确实需要阅读并理解这一点。

▶第五公告数据模型的链接◀实体关系图位于第一页，后面是数据模型。

• 按键几乎都是直接的IDEF1X（除了我作为对位提供的UserId）；这意味着钱包关系密钥。未增强且未针对物理考虑进行优化。在你犹豫之前，首先注意它们、记录它们并评估它们。当然，我们可以添加 Id物联网密钥，但在此之前，让我们确保我们了解我们将丢失什么。

• 注意符号文档中的标识符（实线）。脊柱，系统的椎骨是位置...公告...响应。

• 请注意，键实际上实现了许多业务规则。

• 注意我渲染的自然层次结构。看看它对你是否有任何意义。

• 动词短语非常重要；看看它们是否意味着什么。

关于第一个数据模型和响应的评论

我的一个问题是该位置的主键将用于形成子主键？（它们由实线连接）我不太明白这个概念< /em>

是的。 Location（在线上方）的 PK 为 (StateCode, Town)。无论如何，将两列一起 PK（复合键）作为 FK（粗体）从 Location 迁移到 Bulletin。我们还使用它来形成Bulletin PK（在线上方）。

如果我们需要代理键，我们将添加它。目前，我们正在制定标识符。所以需要思考的问题是：

• 什么是好的公告标识符？，您的用户自然会使用什么来识别公告...
• “您昨天看过弗吉尼亚州 FO 的公告吗？”，
• “来自华盛顿的莎莉确实写了很好的公告”，等等。

或者为什么用户和公告之间不存在这种关系？

嗯，用户和公告之间不能存在那种关系，但是存在一种关系，虚线，表示 UserId 是 Bulletin 中的 FK（粗体），但未使用它来形成其 PK（行下方）。

或者您的意思是：用户是 Bulletin 的强标识符（因此应该用于形成 BulletinPK，因此该行应该是实线）？

好吧。出色的。这就是标识符建模的全部内容。这清除了我不喜欢的一个领域，因为我们有非唯一的索引。这也解决了我的问题。

• 根据上面进一步陈述的意图，由于我现在已将评级显示为表格以及渲染结果，一旦我将删除它

• 我认为权限应该是一个实体。

• 公告 PK 现在为（StateCode、Town、UserId、SequenceNo）。需要明确的是，SequenceNo 位于 StateCode、Town、UserId 内：对于 Sally 的有关 MO/Billngs FO 的第 5 个公告，它将为 5。

• 注意，用户设置BulletinsPerPage等与User是1::1，所以它们在User中；子表将不正确。

• 已更正印刷错误。

关于第二个数据模型和响应的评论

• Bulletin 和 Response 的 PK 已更改以反映 (7)。 BulletinNo 和 ResponseNo 已替换为 BulletinDate 和 ResponseDate（以前是 CreatedDate)，以便允许每个用户每个公告进行多次回复。

关于第三个数据模型的评论和回复

相信您度过了愉快的时光。

1. 至少在 30 年前（据我所知），行业巨头们曾进行过这样的争论。名字总是单数的。表是名词。动词短语是动词。这不仅限于数据库命名约定，它适用于文档、论文、学位论文等。您可能在文档末尾有 5 个结论，但在目录和页面顶部都有章节或章节标题是“结论”。

   在大学一路与他们抗争之后，当我开始第一份有偿编程工作，并看到规则在现实世界中的重要性，而不是我们在大学里的理论争论时，我就放弃了它浪费时间。我浪费的所有时间和精力都被释放出来去做富有成效的工作。从那时起，我不再质疑巨人；我只是接受。他们的思想比我的思想更伟大。这就像接受标准，或者在法律或上帝范围内行事。我没有真正非常充分的理由去做任何非法的事情。

   无论如何，这些规则所支持的语言（讨论、SQL、文档）的易用性无法得到充分的解释；当你编写越来越多的 SQL 代码时，它就会变得清晰。

   您始终可以自由地使用您想要的任何内容。我只提供单数。

2. 对我来说很好。

   但是您需要记住，所识别的序列（例如非 PK 唯一索引或备用键）中的这两个元素是建立人员唯一性所普遍需要的。删除它们会导致两件事。首先，您将无法再识别用户之间的唯一性（因此您可能有重复的行）。其次，AK 变得不唯一，成为反转条目。

3. 要点是（与其中一篇文章相反），任何与UserPK 为 1::1 的列都应位于User 中。所有首选项设置。由于我们清理了InterestedLocations和InterestedCategories，我只知道剩下的BulletinsPerPage；但是我敢肯定还有其他。 iSpReference2是EG。 boolean; numPreference3是一个EG。整数。等等。你可以告诉我真正的偏好是什么。

   （让我们在复数中尝试一下：... 用户 pk的任何1 :: 1的列，应驻留在用户中。只是不做对我来说，我挂在破碎的英语上，我对母语有些珍贵。）

   数据模型已更新。

4. 很棒。让我知道您何时对此感到满意，我会给您物理模型。

   动词？

评论re 06 12月10日20:38 EST（小更新）

。
28。当然，PK仅出现PK，而FK列名称与PK列名称相同。但是，当FK中有多个OCC（看看响应）时，有三个userIds），我们需要区分它们。在IDEF1X术语中，这称为角色。发出Bulletin的用户的角色是发行者，依此类推。显然，最好使用该名称，并在整个层次结构中保持一致（userId in Bulletin，然后当我们到达Response> Response> Response时，有两个，并且需要差异化，请将其更改为 。 >因此，绝对清楚的是用户ID作为FK，并且该角色是发行者; 同样，我们有许多DateTime列（如果您愿意的话，

请日期；否则DTM）。
.
29. IDEF1X符号文档是否没有意义？

• 按指定顺序，每个表的PK位于行之上。
• 请记住，无论如何我们都携带父表的PK，如果有意义，请使用这些FK形成孩子PK。

• 对于Bulletin：

  • 位置fk （statecode，town）发行的位置
  • 发行人的用户ID
  • 和DateTime是为了使其与众不同的。
  • 因此（（司法，城镇，Issuerid，子弹）`

• 删除此Bulletin的所有wenderseratings，在这四个<代码>公告列。

.
30。因为（状态，城镇）是位置的PK，随身携带。它构成了Bulletin pk的一部分，因此任何因表都带有这些列，因为它们携带Bulletin pk。

寻找彩色选项卡（仅此版本）
.
32。这些是动词短语。符号文档中详细介绍了阅读它们的方法。看来您的手柄很好。正确获取表名（和动词短语）是正确的，因为实现后很难进行更改。如果您告诉我办公室比位置更好，那对我来说很好。

阅读：办公室被公告激活

随意提供另一个动词短语。
Aafaic，Office对ORG的其余部分都死了，并且仅在其雷达上生存（被激活）Bulletin。
我在这里意识到这听起来很愚蠢，但是忽略了片刻，沿着“ Office的行为表达其功能；通过发行Bulletin”来宣传其活动。

在Mark的传感器数据模型上进行测验，用于一些不错的动词短语。

我们以前曾确定（州，城镇）是PK，我将按照将其保留为请参阅（38）以进行更改。

.
33。值得讨论。是的，如果要在（例如）显示响应时显示它，并且用户了解用户名。不，如果是30个字节，并且还有一个唯一的4个字节用户ID。当您最终确定约6列30字节键太麻烦了，无法迁移到孩子时，想法是有意识地意识到自己放弃的选择。

• 我在一开始就确实说明了userId作为典型的id pk，因为它被携带/迁移到几个子表中。
• 我们可以留下以后创建的方式。但这是一个纯粹的代理PK。

.
34。没问题。 类别已经拥有它。我将将订单更改为listorder。

.
35。当然。根据我阅读和听到的内容，我对此感到非常满意。但是，在您编写代码之前，我希望更多来回获得一些信心。或者，将其视为一种学习体验，并接受模型和代码以后可能会发生变化。您要我现在生产身体吗？如果您给我所有更正，我将发布下一个版本。我希望用户中的首选项。另外，迅速浏览功能并检查您是否拥有所需的所有列。

为了学习和兴趣，请查看其他一些答案。

.
36.加入。您只需加入四个三列而不是一列。 SQL与Joins很麻烦，而应该使其更容易的新语法实际上更加麻烦。我的编码器从不写入加入：我们节省了时间和错别字。我有一个给定两个或多个表的PROC，将与所有列和连接在一起生成代码。我不了解MySQL，无法为您转换。

数据模型更新了。
。

评论RE RE 08 DEC 10 20:49，第四个数据模型和响应

。
检查上面的上一节，有小更新。

IDEF1X：您的速度很好。

请注意，孩子总是“继承”父pk，作为FK（固体或断线），否则它们之间没有关系。无论如何，通过使用这些孩子中存在的这些列来形成孩子PK，我们携带含义（这就是固体和破碎之间的区别）。因此，我们不需要为孩子寻找独立的标识符。当您进行编码时，此方法中的关系能力将在稍后变得清晰。

我们正在处理的部分是标识符：自然与非自然;有意义的与毫无意义。稍后，您将看到如何在由父pk形成子PK时使用引擎的关系能力。 （您的姓氏与父亲的姓氏不一样吗？）

了解关系数据库及其能力也很重要。当我们从OO的角度接近数据库（例如），并将其视为使我们的课程“持久”时，那将丢失。因此，我们将尝试学习和使用关系术语。当您去法国并期望他们会说美国人并使用相同的货币时，这会变得困难。学会说10个法语单词，他们张开双臂欢迎您，您与当地人会有很大的不同经历。

无论如何，继续实施模型。只是意识到我们可能会在某个时候进行更改。保存所有DDL。将所有测试数据保存为插入语句或表备份或字符格式导出（不知道MySQL在此领域无法做什么）。
.
37.1。处理，n :: n与Office＆amp; 类别。当我们进入物理模型时，您只会“看到”。

37.2。完毕。

37.3完成。
.
38。太好了。也短。请注意，他们将永远无法在同一邮政编码中拥有两个办公室。数字（5,0）很好，但我认为美国正朝着7位数字迈进。没关系，您可以弄清楚。它是Office的绝佳PK。现在，本列是地址的一部分，可能是zipcode，已提高到更高的目的，而无需重复；由于我们将其携带在5个子表中，因此我们希望按照先前的惯例清楚pk名称，因此我们将其称为officeecode; OfficezipCode可能很愚蠢。

我们需要在name上进行唯一的索引，以确保它们不会添加两个具有相同名称的Office。注意，出于解释目的，这实际上是Office，替换（statecode，town）的逻辑键，并且仍然如此。

我仍然认为您可能需要statecode和town作为快速引用（除了坐在address> address中的某个地方，

数据模型已更新，现在可用于第五个审查。您没有说明您的喜好，... date vs ... dtm。我正在使用后者，因为它更加熟悉，也可以识别时间组成部分。易于改变。

这个答案已达到最大长度。继续在“第二部分”

Answer 2

拥有高效数据库的关键是简化。关系数据库的主要目标是不重复任何信息。据我所知，我获取了您的 SQL 转储并快速起草了一个标准化的更简单版本。我确实为简历等留下了一些字段。我删除了一些字段，当需要信息时，通过查询数据库来重新计算会更简单，例如用户的帖子总数和给定帖子的排名。我还删除了您的 bb_replies，因为您可以通过引用父帖子来实现相同的结果。我已将表格稍微重命名为对我来说有意义的名称，您可以使用您觉得舒服的命名方案。我发现使用简单的术语可以更轻松地理解数据之间的关系。

我必须承认我确实同意上面的一些评论，有很多 BB 可以很好地工作并且具有您正在寻找的所有功能。你很幸运，我今晚有读书的心情，哈哈，这是一个很长的问题。简化是一切的关键:)

SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0;
SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0;
SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='TRADITIONAL';


-- -----------------------------------------------------
-- Table `users`
-- -----------------------------------------------------
CREATE  TABLE IF NOT EXISTS `users` (
  `id` INT NOT NULL AUTO_INCREMENT ,
  `username` VARCHAR(45) NULL ,
  `password` VARCHAR(100) NULL ,
  `email` VARCHAR(255) NULL ,
  `first_name` VARCHAR(100) NULL ,
  `last_name` VARCHAR(100) NULL ,
  `permission` INT NULL ,
  `created` DATETIME NULL ,
  `modified` DATETIME NULL ,
  PRIMARY KEY (`id`) )
ENGINE = InnoDB;


-- -----------------------------------------------------
-- Table `categories`
-- -----------------------------------------------------
CREATE  TABLE IF NOT EXISTS `categories` (
  `id` INT NOT NULL AUTO_INCREMENT ,
  `name` VARCHAR(45) NULL ,
  `description` TEXT NULL ,
  `order` INT NULL ,
  `admin` INT NULL ,
  PRIMARY KEY (`id`) )
ENGINE = InnoDB;


-- -----------------------------------------------------
-- Table `locations`
-- -----------------------------------------------------
CREATE  TABLE IF NOT EXISTS `locations` (
  `id` INT NOT NULL AUTO_INCREMENT ,
  `name` VARCHAR(45) NULL ,
  `description` TEXT NULL ,
  `address` TEXT NULL ,
  `order` INT NULL ,
  PRIMARY KEY (`id`) )
ENGINE = InnoDB;


-- -----------------------------------------------------
-- Table `posts`
-- -----------------------------------------------------
CREATE  TABLE IF NOT EXISTS `posts` (
  `id` INT NOT NULL AUTO_INCREMENT ,
  `post_id` INT NOT NULL ,
  `user_id` INT NOT NULL ,
  `category_id` INT NOT NULL ,
  `location_id` INT NOT NULL ,
  `title` VARCHAR(45) NULL ,
  `content` TEXT NULL ,
  `created` DATETIME NULL ,
  `modified` DATETIME NULL ,
  PRIMARY KEY (`id`, `post_id`, `user_id`, `category_id`, `location_id`) ,
  INDEX `fk_posts_users` (`user_id` ASC) ,
  INDEX `fk_posts_posts1` (`post_id` ASC) ,
  INDEX `fk_posts_categories1` (`category_id` ASC) ,
  INDEX `fk_posts_locations1` (`location_id` ASC) ,
  CONSTRAINT `fk_posts_users`
    FOREIGN KEY (`user_id` )
    REFERENCES `users` (`id` )
    ON DELETE NO ACTION
    ON UPDATE NO ACTION,
  CONSTRAINT `fk_posts_posts1`
    FOREIGN KEY (`post_id` )
    REFERENCES `posts` (`id` )
    ON DELETE NO ACTION
    ON UPDATE NO ACTION,
  CONSTRAINT `fk_posts_categories1`
    FOREIGN KEY (`category_id` )
    REFERENCES `categories` (`id` )
    ON DELETE NO ACTION
    ON UPDATE NO ACTION,
  CONSTRAINT `fk_posts_locations1`
    FOREIGN KEY (`location_id` )
    REFERENCES `locations` (`id` )
    ON DELETE NO ACTION
    ON UPDATE NO ACTION)
ENGINE = InnoDB;


-- -----------------------------------------------------
-- Table `likes`
-- -----------------------------------------------------
CREATE  TABLE IF NOT EXISTS `likes` (
  `id` INT NOT NULL AUTO_INCREMENT ,
  `user_id` INT NOT NULL ,
  `post_id` INT NOT NULL ,
  `like` TINYINT(1)  NULL ,
  PRIMARY KEY (`id`, `user_id`, `post_id`) ,
  INDEX `fk_posts_users_users1` (`user_id` ASC) ,
  INDEX `fk_posts_users_posts1` (`post_id` ASC) ,
  CONSTRAINT `fk_posts_users_users1`
    FOREIGN KEY (`user_id` )
    REFERENCES `users` (`id` )
    ON DELETE NO ACTION
    ON UPDATE NO ACTION,
  CONSTRAINT `fk_posts_users_posts1`
    FOREIGN KEY (`post_id` )
    REFERENCES `posts` (`id` )
    ON DELETE NO ACTION
    ON UPDATE NO ACTION)
ENGINE = InnoDB;


-- -----------------------------------------------------
-- Table `sort_options`
-- -----------------------------------------------------
CREATE  TABLE IF NOT EXISTS `sort_options` (
  `id` INT NOT NULL AUTO_INCREMENT ,
  `name` VARCHAR(45) NULL ,
  `description` TEXT NULL ,
  PRIMARY KEY (`id`) )
ENGINE = InnoDB;


-- -----------------------------------------------------
-- Table `preferences`
-- -----------------------------------------------------
CREATE  TABLE IF NOT EXISTS `preferences` (
  `id` INT NOT NULL AUTO_INCREMENT ,
  `user_id` INT NOT NULL ,
  `pagination` INT NULL ,
  `sort_option_id` INT NOT NULL ,
  `categories_csv` VARCHAR(45) NULL ,
  `locations_csv` VARCHAR(45) NULL ,
  PRIMARY KEY (`id`, `user_id`, `sort_option_id`) ,
  INDEX `fk_preferences_users1` (`user_id` ASC) ,
  INDEX `fk_preferences_sort_options1` (`sort_option_id` ASC) ,
  CONSTRAINT `fk_preferences_users1`
    FOREIGN KEY (`user_id` )
    REFERENCES `users` (`id` )
    ON DELETE NO ACTION
    ON UPDATE NO ACTION,
  CONSTRAINT `fk_preferences_sort_options1`
    FOREIGN KEY (`sort_option_id` )
    REFERENCES `sort_options` (`id` )
    ON DELETE NO ACTION
    ON UPDATE NO ACTION)
ENGINE = InnoDB;



SET SQL_MODE=@OLD_SQL_MODE;
SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS;
SET UNIQUE_CHECKS=@OLD_UNIQUE_CHECKS;

Answer 3

首先是子查询，然后是 RANK() 函数

放轻松，儿子，我们会成功的！你的速度没问题。

准备

首先，您确实需要获得一套适合您的 MySQL 特定风格的手册。我找到了▶这个◀。和以前一样，您必须自己进行调试，但我现在提供尽可能接近通用 MySQL 的 SQL。我已经确认，我们要做的一切在那种风格的 MySQL 中都是完全可能的（我不知道你的风格/版本是什么，除了 ENGINE=MyISAM）。

子查询

好吧，让我们重新开始。我写了▶系列SELECTS◀ ，引导您完成整个过程。请完成每一项，并在进行下一项之前完全理解它。如果您有任何疑问，请停止并发布问题。

代码在Sybase中编写和测试；然后降级 MySQL（通过浏览网络，例如上述站点），并在该状态下进行尽可能多的测试。

第一个位创建并加载三个表以供使用。

1. 第一个 SELECT 是三个表的直接连接，没有子查询。你需要让它发挥作用；也就是说，理解它的作用，修复任何语法问题；找出我提供的 SQL 和您服务器上运行的 SQL 之间的差异。并习惯于做出这些改变。我们不能一直为此停下来。

2. 第二个 SELECT 产生完全相同的结果集。它引入了子查询的概念，用于填充单个列。

驾驶那辆公共汽车。完成后或遇到问题时进行回复。

评论的回复

1. 对您2010年12月3日17:51直连
   我以前从未见过这种连接方式，我一直使用左连接、右连接或内连接。好的，对于第一个查询，我们只是将学生和课程这两个表与位于中间的学生课程表作为关联表连接起来。结果会按预期重复，因为一名学生可能上了一门以上的课程，并且他们将获得该课程的结果。

是的。

（WHERE子句中的x=y）是识别连接的传统方式，更清晰； LEFT/RIGHT/INNER/OUTER JOIN 语法是“新”方式。 AFAIC 要麻烦得多，但学习是相关的，因为它对以后的内容至关重要。为了便于理解，请随意转换为后一种语法，然后再转换回来。

重复？这不是重复或重复的意思。 CS 中的所有行都是离散的、真实的行。您应该在每个报告中获得相同的 15 行（随着我们的进展）。

（ps，当我使用您提供的查询直接创建表时，名称将转换为全部小写，而列名称仍然可以是驼峰式大小写。）

MySQL很奇怪。 （它似乎正在为我们进行命名约定！）

。
2. 简单标量查询
查询的一些问题。在定义别名之前，您使用别名（在标量子查询中）吗？（StudentCourse sc）我想我总是错误地认为您必须在使用别名之前先定义别名。

你正在按程序思考。 SQL 是一种面向集合的语言，用于操作关系数据集。

整个查询一次性得到评估和优化。没有“之前”或“之后”。我在使用它的同一批 SQL 中定义它。

我不完全理解标量子查询中别名“in-ner”的使用，这是否是说您希望它单独检查每一行（不知道如何解释这一点）而不是在表上宽检查？即，当您进行此检查时，使其位于您所在的特定行本地？（抱歉，解释很糟糕）。

为了理解/调试的目的，首先单独评估子查询（括号中的内容）。充分理解它。请注意“sc”的使用并将其保留在您的帽子中。

• in_ner 和 sc 是别名，即 FROM 子句中紧邻的表名的句柄；为了方便起见，我们在代码中的其他地方使用
• in_ner 是内部查询中引用的表的描述性名称，子查询
• sc 是在内部查询中引用的表的描述性名称外部查询，它只是外部，因为它有一个内部查询，否则它将是一个平面查询，
• 我们可以轻松使用 fred 和 sally
• 别名，例如 当内部查询和外部查询中引用同一个表时，in_ner 和 out_er 才有意义。
• 请注意内部查询和外部查询之间的连接 WHERE in_ner.CourseId = sc.CourseId
• 我已关联in_ner查询中引用的表到 Out_er 查询中引用的表 sc
• 这样的子查询称为相关子查询

看看您是否可以将外部查询（结果集）可视化为网格、电子表格、15 行 x 4 列。

• 确保您理解外部查询，因为它确实“简单”。请注意，它与 (1. Straight Join) 相同，但填充一列的方法不同。

据我了解，标量子查询要求名称，其中 Course 和 Studentcourse 中的 courseId 相同。（非常简单），并且是在 where 中表示的另一种选择，

是的，完全正确。

请注意，我们只关注 Course.Name，它是在 CourseId 上从 StudentCourse 到 Course 的 1::1 连接。请注意，我们在 (2) 中替换了 (1) 中的 WHERE 子句； (1) 中它适用于所有行。

但是因为我们正在获取一个数据；一个细胞；特定行/列的一项；不是所有行；不是所有的列，它被称为标量。

我们使用子查询获取它，该子查询必须限制在特定行。因此，我们需要将外部查询中的行与内部查询中的行相关联。

• 因此需要内部子查询和外部（特定行）之间的关联。

• 如果我们没有特定行的标识，我们就会将垃圾加载到标量中，或者它将返回一个表（而不是标量值）并且查询将失败。

  • 尝试一下，将 WHERE CourseId = sc.CourseId 取出
  • 这样您就知道错误消息是什么，这样当将来发生这种情况时，您就会知道“啊哈，我返回的是一个表，而不是一个标量；我在我的内部WHERE”中遗漏了一些东西 子句；我没有识别特定的相关行”。
。

  


• 它并不完全是“询问名称，其中课程和学生课程中的 courseId 相同”；它正在获取特定 StudentCourse.CourseId 的 Course.Name，该 ID 是从外部识别的，无论它是什么 sc 行。

不同的是，您可以在 where 之前逐行进行此检查。

你正在按程序思考；没有“逐行”； dbms 是面向集合的；您正在构建的结果集是一个集。重申问题是集合术语。

我使用了 Course 或者 in-ner，在这种情况下使用别名有什么意义，只是为了表明可以使用别名吗？

是的。并突出问题。并区分内部查询和外部查询。在内部查询中，不需要“内部”别名或任何别名。仅需要与外部查询相关的别名。

我不明白的是，当我尝试执行此操作时，“course.Name”在字段列表中显示未知的 Course.Name。这是我一直定义的方式，我的意思是课程表中的名称，而不是其他表中的名称。如果我有两个带有名称列的表会发生什么？

正是如此。如果不明确，那么您必须提供表名或别名；如果它不含糊，则不需要它，但为了记录、清晰、目的而有它是很好的。你必须弄清楚为什么 MySQL 不接受它。混合大小写/小写疯狂？

我也从未见过这种 order by 语法，我可以看到 1 和 4 表示列号，但为什么要费心传递两列呢？

嗯？因为我希望结果集按 Course.Name 升序排列，其中按 StudentCourse.Mark 降序排列。

如果我没有说明顺序，MySql 将以从 StudentCourse 获取的任何顺序生成结果集（按时间顺序？；按索引？）。无论默认顺序是什么，找出它，您需要知道它，从而在不必要时避免使用 ORDER BY。

• 将 ORDER BY 拿出来玩玩。

• 尝试 ORDER BY 4 DESC, 1

这不是“通过”，我是在一个 SQL 命令中告诉它如何处理我的结果集。您所做的唯一传递是在您的应用程序（PHP？）和 MySQL 之间。

2.1.好的，当您完成（2）并且非常高兴您理解它时，请做这个练习。

SELECT  (SELECT Name
            FROM  Course
            WHERE CourseId = sc.CourseId
            ) AS CourseName,
        () AS FirstName,
        () AS LastName,
        Mark
    FROM StudentCourse sc
    ORDER BY 1, 4 DESC

• 生成相同的网格格式，我们想要与 (1) 和 (2) 完全相同的结果集。

• 用适当的子查询填充两对空括号； IE。编写一个子查询来填充 FirstName 列，再编写一个子查询来填充 LastName 列

对您关于第三数据模型

2.1 的评论的响应。完美，是的，我们继续前进。
.
你正在用煤气做饭，所以如果你不介意的话，我会记下你的文字，并做一些注释；注意这些差异，它们可能很微妙，也可能不那么微妙。

相关标量子查询表示，对于每个课程 ID，我们需要最高分，而不是所有课程的最高分。这就是该子查询的相关方面发挥作用的地方，因为我们将外部查询与该特定行的内部查询相关联。 [是的！]我目前可视化的方式[就是这样，使用你头脑中的视觉部分，而不是连续部分]是外部查询运行将结果 table 集放在一起的表，并且每次创建一行时，它都会运行标量子查询并挑选出[一个值来填充单元格；这里是] courseId 匹配的最高分数，因此当它位于课程 id 为 66 的行时，标量子查询仅查找 courseId 为 66 的最大分数。

我自己说得更好。

不存在“结果表”这样的东西。

添加一项更明确的项目。

• 外部查询定义结果集。

  • 子查询与此无关；它只是相关或索引的。

好的，那么 SQL 就可以工作了，对吗？

现在您已经了解了这一点，下一步是可视化结果集，并可视化填充整个列的子查询（3，未更改）。如果上面的文本是一个气球，一次填充一个单元格，那么想象数百个气球，填充连续的单元格。然后想象一个桶倒入柱中。

现在，将二维结果集单独放置一分钟，并可视化其顶部的另一层。这是并行层，您可以在其中编写子查询代码。

如果您在使子查询工作时遇到困难，请返回到您的可视化方式，一个结果集和子查询的另一层，该子查询倒入一桶标量以填充列。它消除了所有众所周知的子查询编码错误；删除了 GROUP BY、DISTINCT 的使用，以及所有那些让一条愤怒的长蛇装入果酱罐的笨方法。
.
在继续 (4) 之前，还要执行三个小步骤。

2.2 重新阅读我上面的回复（2），一直读到这里。没有略读。这是因为当你教给你的大脑一些新的、不同的东西时，你需要强化它。这是一种官方认可和标记的技术。

对 2010 年 12 月 8 日 20:49 评论的回复

2.3。在不使用子查询的情况下编写该查询 (3)，并确保检查结果。如果您在编写代码时发现自己在笑，这是一个好兆头。只要生成正确的结果集，就可以通过，但请尝试编写最有效的代码（最少的 COUNTS 和 GROUP BY 等）。仅当您想在同事周围转圈，以便能够回答数据库中的任何“我如何编码......”问题时才执行此操作。

我不确定您所说的在不使用子查询的情况下编写该查询是什么意思？我认为我们想避免使用 group by 等

是的。绝对地。你已经向前走了。现在向后走不要绊倒。当使用子查询与连接更好时，这将真正帮助您理解向前行走。使用 GROUP BY 和 COUNT 对查询进行编码。最少的。别笑。

2.4.在您的数据库上编写子查询（3），以生成公告列表，外部查询必须仅为FROM bbs；包含喜欢计数和不喜欢计数。因此，截断表并执行 10 或 12 次有意义的插入，时间很长，很重要。

我使用了在数据库上使用子查询的方法来整理公告回复列表，计算喜欢和不喜欢的回复数量并获得特定的用户评级。这很棒，因为我不必使用任何分组依据或计数，也不必像为公告所做的那样创建临时表。

嗯，这很完美。现在我们在你的菠菜中获得了一些关系力量。

现在，去看看这个问题和答案；确保您比较代码。短短几天内，您已经取得了长足的进步。

完成 (2.3) 后，再次阅读 (2.4) 查询，以刷新自己，然后继续 (4)。

如果您遇到困难，请将“Rank”一词替换为“CountOfStudsWithHigherMark”，然后再试一次。

回复2010年12月11日13:14评论

2.3 在没有标量子查询的情况下编写该查询时遇到问题。甚至在我知道如何执行标量子查询之前，标量子查询对我来说总是更具有逻辑意义。这就是为什么我在上一个问题中说“我想我在这里遇到的问题是，如何在这个特定行中引用 user-id = x，而不是在所有行中”。答案是使用别名将标量子查询与主查询相关联。

(2.3) 练习的目的是让您：

• 真正理解使用GROUP BY（在使用集合处理关系引擎的关系数据库中）与相关子查询的正确性、优雅性和速度。你已经做到了。这将使您在 SQL 编码能力方面优于同龄人。

• 能够识别何时使用胖 WHERE 子句以及何时使用相关子查询是合适的。我不确定，但看起来您已经实现了这一点。

• 在维护他人编写的代码时能够纠正和调试此类问题，并能够教他们区分。听起来你有很好的视觉、关系能力；通过练习得到了强化；现在你不能再回到劣等的方法了。也就是说，您可以理解并修复不正确的 SQL 代码，但无法将其传达给其他人。

只要您理解这些区别并接受这一点，我很乐意放弃（2.3）并继续前进。

再次阅读您的 (2.4) 查询，以刷新自己，然后继续 (4)。

如果您遇到困难，请将“Rank”一词替换为“NumStudentsWithHigherMark”，然后再试一次。

---

不要继续阅读。以下是“旧代码”

这里有一个▶快速教程◀ 在 RANK() 运算符上（众所周知）。它不是 ANSI SQL；它是 Oracle 和 MS 的扩展。然而，如果您了解子查询，则不需要它，这就是 Sybase 没有它的原因。我怀疑 MySQL 有它，所以你需要了解一下它。了解标量子查询是先决条件。 Sybase 语法，因此请输入分号等。请随意提出具体问题。

我从未见过这种写 Rank = (SELECT...) 的方法与 Rank 的 (SELECT ...) 相同吗？

是的，() AS Rank而不是Rank = ()都是合法的SQL； MySQL 可能不喜欢后一种形式。当然，括号包含子查询。请注意，Rank 是派生列的名称。

我已经说过，理解子查询是先决条件。这意味着数百万人之前就遇到过这个问题，讲师们发现，如果您按照规定的顺序学习课程，您会遭受更少的挫败感。所以暂时忘记 RANK，学习子查询。

试试这个（我提供 ANSI 标准 SQL；我没有 MySQL；你必须为 MySQL 进行语法修复；我不修复语法问题；那是你的工作）：

< code>SELECT COUNT(*)+1 AS Id_iot -- 不是你，而是每个盲目使用它们的人
        (SELECT title in_ner FROM bb_locations WHERE out_er.bb_locations_id = in_ner.id) AS 位置，
        标题 AS 公告，
        创建日期 AS 日期
    来自bbs out_er

• in_ner 和 out_er 是别名，即 FROM 子句中紧邻的表名的句柄；为了方便起见，我们在代码中的其他地方使用
• in_ner 是内部查询中引用的表的描述性名称，子查询
• out_er 是在内部查询中引用的表的描述性名称外部查询，它只是外部，因为它有一个内部查询，否则它将是一个平面查询，
• 我们可以轻松使用 fred 和 sally
• 连接
• 注意我的 < strong>将in_ner查询中引用的表与out_er查询中引用的表相关
• 这样的子查询称为相关子查询
• 这只是一个例子，简单，这样你就可以学习子查询；特意选择提供与您熟悉的结果集相同的结果集，使用直接联接（FROM 子句中的 bbs 和 bb_locations，联接通过 WHERE 子句或 JOIN 语法）。
• 因为它产生单个值，所以被称为标量子查询（产生行的那些是表子查询；并且不能像这样使用，将单个值加载到每行中）
• 没有建议任何人应该“使用子查询而不是加盟”。荒诞。子查询有其用武之地，连接也有其用武之地。米苏是另一回事。

现在，驾驶那辆公共汽车。并且，在您能够驾驶这辆公共汽车绕过数据库附近的每个角落而不杀死任何孩子之前，请不要跟我谈论 RANK。

我不明白内部和外部，当我用谷歌搜索它们时，我得到 INNER JOIN 他们叫什么，这样我就可以进一步研究

别名。请参阅上文。

当我运行该 select 语句时，我收到此错误 您的 SQL 语法中有错误； 检查与您的 MySQL 服务器版本相对应的手册，以了解在第 5 行的 'WHERE inner.Mark >=outer.Mark ) FROM Studentmark external ORDER B' 附近使用的正确语法

• 首先，根据上面详述的原因， ，我不会写 MySQL 语法，调试是你的
• 第二个工作，我意识到你无法调试你无法理解的东西，所以现在放弃它（它与 RANK 有关），当你学习 MySQL 风格时对于 SQL，所有这些问题都将得到解决，
• 第三，让我向您保证它可以在任何标准 SQL 服务器上运行。它每年在大约 10 个课程中使用，因此每年有数百名参与者。我刚刚在 Sybase 上再次运行它，只是为了检查一下。
• 我要建议的第一件事是，因为 MySQL 优化器很糟糕；它不理解上下文，inner 和 outer 可能被视为保留字。所以按照上面的代码更改它。

Answer 4

第二部分

是第一部分的延续，因为该答案已达到最大长度。

2011 年 1 月 14 日 - 05:40 PST 评论修订

于 2010 年 12 月 11 日 13:14，第五数据模型和

响应IDEF1X 设计/绘图工具。
我不知道有任何免费软件选项。据报道，MySQL 设计工具经常崩溃。如果您对我的图表感到满意，我很乐意在这段时间内与您合作，直到最终模型得到解决； IE。我提供了数据模型，您可以跳过该任务。对于正在进行的工作，是的，您需要一个图表工具，也许不是数据库设计工具。请参阅 Notation 文档中 p2 末尾的我的评论。
.
29. 根据第五数据模型中的彩色选项卡，您清楚每个表中的 PK 和 FK 吗？我现在可以删除标签吗？
.
38. 关闭。
.
39. 所有Dtm 列都将是MySQL DATETIME 数据类型。您用于这些列的变量应该相同。 TimeStamp 有不同的含义。使用正确的数据类型是确保数据正确并且不允许非法值进入数据库的第一步（重要）。即，仅允许有效的日期和时间。此外，您可以从中查询任何日期或时间部分（例如月份或日期名称）。检查此文档。< br>
.
40.没问题。我们不只是硬编码一个类别（例如处理权限），而是实现一个 Category.IsRestricted ，然后 Permission 5 变为 Post Restricted公告。
.
41. 完成。

您应该考虑对 Category 和 User 执行相同的操作。您希望能够通过设置指示器来删除它们，而不从数据库中删除条目（以及所有公告、响应、回复等）。它必须保留用于历史目的，但您需要禁止用户登录并执行任何操作。我已将其包含在 DM 中。

对于此类列名和布尔值，我个人更喜欢识别少数或异常情况，如 IsObsolete 中所示。

20.2.完毕。表和列命名现已发展为 InnoDB 格式。
.
子查询答案中的子查询响应。

评论 2010 年 12 月 13 日 13:14 美国东部时间和回应

。
41. 参见上文 (41) 和下一段。
.
42. 我的意思是： Title 或 Description 就足够了；我们两者都不需要。
.
43.1。数据模型的实现。前进。这就是我昨天给你体检的原因。

.
43.2.设计/绘图。前进。我已经在上面（a）中评论过。

数据模型

第六种数据模型，包含上述所有更改。

物理意味着实现/编码所需的更多细节：数据类型； n::n 关系作为关联表实现；等等。您已经准备好实现数据模型，这意味着您需要物理模型。您已经弄清楚了关联表。因此，尽管您说您不着急，但我还是冒昧地向您提供了物理 DM。

• 请注意，域（用户定义的数据类型）应始终在数据库中使用，两者都用于 DDL；您使用的 $variables。每个主键都有一个私有域。但这在 MySQL 中是不可能的，因此遗憾的是，数据类型是原始的。

• 固定长度列比可变长度列快得多；我不提供（建议）Var 长度。您可以自由地实现您喜欢的内容。

• 您确定需要 Category.Title 和 Description 吗？我想不会，但我已将其保留在您确认之前。

• 享受蓝色玻璃小按钮以及折叠实体中的导航。

请再次阅读IDEF1X Notation文档，我上周对其进行了扩展。

根据未决问题的关闭方式以及您可能遇到的任何问题，我们可以在第二天/晚上进行另一个版本。

评论 28 Dec 10 10:34 和回复

我已经开始实施数据模型。我假设第六个数据模型是物理模型，因为它包含关联表。

是的，我提供了它和数据类型，因为您说您已准备好实现。

仍有一些较小的未完成项目。也许是解决你的问题的好时机；我的所有三个答案，然后检查。例如，Category.Title 和Description。

一旦完成，我将建立一个数据库转储。

这是没有必要的，因为模型已经定义了数据类型；但如果你确实发布了，我当然会帮你检查。电子邮件可能会更好。

然后我将列出我需要在数据库上运行的所有查询的列表并开始编写它们。

非常好的主意，采用结构化和有计划的方法来完成这项工作。

物理模型的实现

(39) 使用 mysql，我无法分配多个主键，因此我将按照您在文档中建议的那样使它们唯一且不为空。您认为对它们也建立索引是个好主意吗？

不确定您的意思，什么是“它们”？：

• 一张表上永远不能有多个主键；备用键是唯一的，其中之一是“主”；在子表中作为 FK 携带。
• 使用InnoDB（你所说的你会得到的），你可以使用MyISAM（你现在拥有的）定义主键约束（相当于UNIQUE，NOT NULL）
• ，你需要一个索引，UNIQUE，NOT NULL作为主键（ 对于 InnoDB 或 MyISAM，每个备用键（模型
• 中的 AKx[.y]）必须定义为附加索引，UNIQUE，NOT NULL。

评论 07 Jan 11 14:08 和回复

(40) 您能解释一下为什么category.CategoryCode 是一个 4 个字符的字符吗？为什么不像我们为用户那样使用数字？

40.1。这个想法是使用良好的自然标识符。数字对于用户来说毫无意义。如果我们没有大量的用户和用户流失，我也不会在那里使用数字。 CHAR(2) 或 (3) 或 (4) 允许他们为长 Category.Description 选择有意义的短代码，并且它足够小，可以作为 user_category 和 <代码>公告。

对于开发人员来说，在测试和调试时，公告列表中的短代码将非常方便。

(40) 我不太了解类别和位置的权限。假设我希望所有用户都能够向“旅行”类别发帖。我要把这个类别的权限设置为4吗？为什么我们在授予类别和位置权限时需要bool IsRestricted？

40.2.我没有改变Permission的概念或本质；这是你的想法，而且和你向我解释的一模一样。

（我所做的只是将permission实现为一个表。）

40.3。参见(13)和(40)原始交换。 category.IsRestricted 定义受限类别；有两类categories：受限制的和不受限制的。用户需要 权限 为 5 才能发布有关受限制类别的公告，并且需要拥有 4 权限才能发布有关不受限制类别的公告。

40.4。但是哇，儿子，你是在引入改变或扩展吗？例如。将user的permission与category的permission相匹配，从而允许多于两个类别的<代码>类别？请不要。这意味着权限对于类别意味着一件事，而对于系统的其余部分则意味着另一件事。或者，如果您这样做，那么我们必须首先解决确切的需求，然后将其作为更改实施。

40.5。该位 (40.2) 和 (40.3) 的位置（现在的办公室）完全相同。如果你指的是底部的文字，那是我的小错误，我会纠正它。

40.6。根据 (14)，office 另外还有一个 AdministratorId (UserId)。在模型上显示为（允许的）用户。

40.7。但这带来了一个问题：谁可以管理类别？现在任何人都拥有 5 或更高的权限，这是另一回事。我认为我们需要一些明确的东西，权限 6 = 管理类别。

其他

• 已处理您的 DDL 并返回。

• 数据模型已更新。修正了一些小的澄清和两个小错误。

评论 08 Jan 11 14:08 和回复

（我认为那是 1 月 9 日，而不是 1 月 8 日...我确实检查了更新。）

(40) 我不太明白类别和位置的权限。我没有改变任何东西。请忽略上一个问题的内容，因为请解释将设置什么权限以允许用户向“旅行”类别发帖。在我的实现中，我只有一个权限列。如果给定用户拥有所需的权限或更高权限，那么他们就可以向某个类别发帖，这就是新系统的工作原理吗？

是的。不变。 category.permission 与此无关。他们需要 user.permission 4 来实现不受限制的类别。

如果category.IsRestricted，他们需要user.permission 5.

完全不同的是，用户需要任何类别的user.Permission。权限是为了管理类别。请勿使用小于 4 的值。

(41) 查询删除公告及其所有相关回复和评级。

我没想到，您确定他们不需要保留所有过去的公告作为历史记录吗？或审计目的？

无论如何，让我们在允许删除公告的基础上处理这个问题......

我什至不知道从哪里开始处理这个问题。过去，我加入的是将公告表与响应表、响应表与响应评级表以及公告 id = x 的公告评级表连接起来，然后将其删除。但现在任何一个特定的公告都由三列标识：OfficeCode、IssuerId 和 BulletinDtm。它们作为外键传递到子表。首先，我如何在我的 php 中存储要删除哪个公告？通常我会有一个像这样的链接 index.php?action=delete&bulletin-id=5。现在我必须有一个链接 index.php?action=delete&OfficeCode=20001&IssuerId=34&BulletinDtm=14:02... 我真的不知道如何做到这一点？

我无法帮助你，我是数据库和 SQL 专家，而不是 php 或 MyISAM 专家。您需要将其作为新问题发布在 SO 或 MySQL 板上。

b.就我对该主题的阅读而言，我不知道语法，但是是的，它可以完成，这是正常的。我在向您推荐复合键之前检查过。更正的 DDL 成功，并且索引已确认，对吗？

c.问题只是复合键或复合键所需的语法；并使用index.php。类似：

index.php？操作=删除& OfficeCode=x 和 IssuerId=y 和 BulletinDtm=z

d.为什么不能使用 mysql_query 而不是 index.php 并因此使用完整的 SQL ？据我了解，它与 MyISAM 一起使用。然后你可以使用：

`$sql = "DELETE $table WHERE OfficeCode=$OfficeCode AND IssuerId=$IssuerId AND BulletinDtm=$BulletinDtm";`

e.先删除response_ rating；然后响应；然后bulletin_ rating；然后是公告。当他们切换到 InnoDB 时，他们要做的更改就会减少。

f.最重要的是，您必须让他们确定删除公告的依据。任何及所有公告均不应删除。类似“一年没有活动”或“关闭”（这意味着添加了一个列）等。

评论 10 Jan 11 14:08 EST 和响应

(41.10-Jan-11) 没问题，方法很好，我有需要在上面 (41.*) 下解决的详细相关问题。 (41.f)还需要答案……除了权限之外，删除公告还有什么依据吗？

评论 10 Jan 11 13:48 pst 和回复

SO 编辑。别担心，那不是你。该网站的技术质量很差。编辑是无望的（相信我，我已经尝试使用它并围绕它进行工作，以使我的答案看起来有点就像我希望它们出现一样）。它无法正确处理缩进或多级编号。

删除基础。好吧，你有一个有效的基础。并且撰写回复的用户不会介意他们在未经询问的情况下被删除吗？

(41) 您正在寻找的是标准 SQL 中的“级联删除”，它是在外键子句中定义的（MyISAM 中没有该子句）。每个 INSERT/UPDATE/DELETE 动词仅适用于一个表，可能通过 REFERENCE 影响其他表。

对于非标准 SQL，您可以使用 DELETE multiple_table 方法（非标准语法）。

首先，理解这一点非常重要。 DELETE 命令中的 FROM 和 WHERE（或 JOIN）子句与 DELETE 本身是分开的；它们实际上是一个 SELECT。想法是：DELETE table_one (SELECT FROM table_one, table_two WHERE join_conditions)。

因此：

• 在 DELETE（目标）中命名四个表
• 在 FROM 中命名四个表（如何通过 SELECT 找到它们）
• 确保您对这四个表具有正确（完整）的 JOIN 子句；您可以通过 SELECT 进行测试
  • 这意味着，JOIN ON OfficeCode、IssuerId、BulletinDtm（影响三个子表的 bulletin PK）
  • 使用 NATURAL 或 INNER 连接，不使用左连接（作为一般规则，要明确，不要混淆它们）
• 确保 WHERE 标识要删除的特定公告复合主键。

这是DELETE 语法 和 JOIN 语法。

2011 年 1 月 12 日 21:48 评论和

回复不要偷懒。自下而上编写四个删除语句。这就是我们必须在城市的尽头做的事情，在那里我们没有“级联删除”。为 rating_response 编写删除；然后复制粘贴，每次删除一行代码。我不明白这种焦虑或回避。

b.我再说一遍，不要使用左、右或任何类型的外连接（这仅是单个全包删除所需的）。仅使用直接内连接（这对于 4 个删除语句来说不是问题）。您遇到的任何烦恼都是由于您需要使用一次删除而导致的。放弃它，烦恼和并发症就会消失。

• 我刚刚写了这段代码 另一个问题。这是一个SELECT 命令。三列PK乘以四个子查询。我不明白需要避免长命令（再次要求，因为 SQL 很麻烦）。我什至没有使用 JOIN 语法。我花了十分钟来写，再加上五分钟来测试。究竟是什么，有什么大不了的？

c.您没有忘记关系键的力量，几周前您就认识到了，不是吗。例如。能够从 rating_response 获取公告，而不必加入评级。如果你屈服于单列键的欲望，你将失去这一切。 SQL 很麻烦。但这就是我们所拥有的一切。处理它。非 SQL 试图“让生活变得轻松”，但事实上，引入了各种不必要的和可以避免的复杂性。举个例子。

2011 年 1 月 13 日 21:18 PST 的评论和回复

删除。三种口味。伟大的。希望您的数据值位于 $variables 中，这样就不会出现这种形式的重复。对于测试来说，这很好。

1. 删除 x 四个表。 （不是“单独删除记录”，这是完全不同的事情；除了最后一个之外的每次删除都可能会删除数百行）。我相信剪切和粘贴只需要几秒钟。您需要小心，不要忘记更改表名称。

2. 单个删除命令。第一个三元组的 $variables。您可以在除第一个三元组之外的所有列中使用列名称。

3. 好的，测试后您将把 SELECT 转换为 DELETE。左连接。对于单个删除是必需的，但其他情况下则不需要。这与 (2) 相同，只是将 WHERE 替换为 JOIN>

我已经推荐了（1），但你更有可能选择（3）。

Answer 5

不要害怕加入。如果我是你，我会减少你需要编写的所有数据库逻辑，并使用像 Doctrine 或 Propel 这样的 ORM，这将使设计和维护变得更加容易——包括你试图避免的所有连接。