我们公司有许多不同的实体,但这些数据库实体中有很大一部分是人.因此,我们有客户,员工,潜在客户,承包商和提供商,所有这些都有一些共同的属性,即姓名和联系电话号码.
我可能已经过度使用面向对象的思维,但现在我正在寻找一个包含所有人的"人员"表,标志/子表"扩展"该模型,并根据需要将基于角色的属性添加到联结表.如果我们说有250,000人(在MySQL和ISAM上)会对性能产生如此大的影响,以至于未来的DBA会永远诅咒我吗？我们最常见的搜索是姓名/姓氏组合.
例如,像Salesforce这样的公司,客户/潜在客户/员工都在具有子视图的集中表中(因为缺少更好的术语),或者它们被分成不同的表？
警告:这个问题与"我们发现在现实世界中做得更好"有关,而不是理论设计.我喜欢上述解决方案,并且相信通过视图,正确的大小和准确的索引,性能不会受到影响.我也觉得上面不算是一个MUCK,只是一张相当大的桌子.
我的代码类似于下面的代码（它是示例代码）。使用 Guzzle，我多次调用同一站点以查看文档是否存在。如果该文档存在，我会保存它。当我进行每次调用时，内存使用量都会增加。最终，如果请求数量足够多，我就会耗尽内存。我曾经memory_get_peak_usage跟踪内存使用发生的位置，那就是 Guzzle 客户端。
该代码按预期工作，但我找不到一种方法来告诉 Guzzle 客户端“重置并转储所有先前的请求”。我很确定它会将结果缓存在内存中，但是当我将它们写入文件时，我知道我不需要上述结果。我该如何转储它们？
FWIW，我当前的解决方案是让一个新客户端复制原始客户端的参数，并定期取消设置。它有效，但很丑。
$client = new \Guzzle\Http\Client('some_url');
for ($i=0; $i<10000; $i++)
{
try {
$pdf = $client->get( $pdf_name )->send();
$this->filesystem->put(
$pdf_name,
$pdf->getBody( true )
);
} catch ( ClientErrorResponseException $ex ) {
}
}