关于查找的PHP mySQL最佳实践

我的问题: 我有一个mysql数据库，它由事实表（虽然不是每个字段都是查找）和各种其他表组成。当我想显示“事实”表中的数据时，是否有必要对每个单独的查找运行查询，或者是否有方法创建一个已经完成“查找”的临时表

例如： 表格结构-

• 唯一_id（自动增量int）
• 模型（int，查找表#2）
• 类型（int，从表2到表3的查找）
• 员工（整数，查找表4）
• 附注（文本）
• 成本（浮动）
• 小时数（浮动）
-

因此，例如，当我想制作一个php页面来输入这些数据时，它似乎比需要做的“工作”多得多：

• 唯一\u id（不显示为数据输入字段，自动递增 （提交时）

• 模型（下拉框。填充要求查询表#2，其中状态=X）

• 类型（只读文本框显示模型类型。需要根据表#2中的列查询表#3）

• employee（下拉框。人口需要查询表#4，其中employee_status=“Active”）

• 注释（文本框，用户输入与提交相关的注释）

• 成本（文本框，用户输入与提交相关的成本）

• 小时数（文本框，用户输入与提交相关的小时数）

只是为了得到一个简单的表单并填充有效的数据，在我看来需要大量的查询/查找

这是最好的方式吗？有更好的办法吗

---

旁白：我可以控制数据结构，因此，如果问题是数据库设计，那么这些建议也会很有帮助。

我不太清楚您所说的“对每个单独查找的查询”是什么意思。您的意思是在php脚本中保存整个表的方法吗？或者，您的意思是在mysql服务器上缓存以消除数据库节点上的进程资源吗

MySQL包含一个内置的缓存系统，它消除了类似查询的大量服务器周期。您可以在此处找到更多->

---

就数据库结构而言，如果您需要一些建议，您必须提供关于模式的更多细节（数据库的作用）。如果不知道它应该做什么，就很难知道什么样的结构有效。（每个员工是否有多个注释，成本是多少？是否每个员工都有？等等）

维度表通常不会经常更改，至少相对于事实表的插入次数而言是如此。维度表也比事实表小得多。这使得维度表成为缓存的良好候选对象

有些人做的很好的效果是呈现表单的部分HTML输出，所有数据填充为下拉列表、单选按钮、，然后将部分HTML存储在memcached键下，这样您就不必对大多数PHP请求执行任何数据库查询或HTML呈现——您只需从memcached中提取预填充的HTML片段，并逐字回显即可。我认为这就像“宜家”的数据库驱动输出

当然，如果您确实更改了维度表中的数据，您可能希望使缓存的HTML无效，或者更好地重新生成它并在memcached中存储新版本的HTML

---

关于执行所有查找，我要指出，不需要在事实表中使用伪密钥。您可以使用自然值，并使它们引用维度表的主键，主键也可以是自然键而不是伪键。在某些情况下，它可能需要更多的空间，但它消除了查找。当然，对于长varchar的维度，继续使用伪键可能是有意义的。

似乎下拉框正被自动完成输入数据的文本字段所取代，就像你在FB和google上看到的那样。这是一个很好的观点。我可以将这些下拉框更改为自动完成txt框。我以前也用过这些东西。然而，这仍然不能解决查找问题。即使在自动完成时，我仍然需要查找下一个关联的值来填充“只读”字段。除非我在这里遗漏了什么？另外，使用文本框approack，您将进行ajax调用以分离php脚本。考虑到这一点，即使使用下拉列表，您也可以这样做。不，我不是说缓存。我说的是建立一个已经完成查找的表。当您查看事实表时，它主要是每列中的数字。其中大多数数字表示另一个表的主键。因此，为了向用户呈现数据，在数据有意义的地方，我必须在另一个表中查找该键，并获取表示人类可读数据的列。然后对每个查找继续这样做，这就是为什么我说“每个查找都有一个查询”。比尔-我以前从未听说过，但我是个新手。听起来很有趣，和我要找的正好一致。你说得对，我的维度表不会经常改变，如果有的话。它们充满了静态值，然后被拉入事实表。另外，你对宜家的类比让我觉得你的回答很有道理。你有这个例子的链接吗？这要求太高了吗？这里有一篇文章展示了我所说的Python应用程序，但PHP和Ruby开发人员广泛使用相同的技术：