该应用程序大量使用数据。这是一个房地产线索管理系统，每条线索都可以使我们的用户成千上万美元，而意外归还他人的线索将是失去客户信任的必经之路。我们在客户端上大量使用实体模式。这要求我们获取数据集合并将其作为集合存储在客户端上。在设计数据库时，我的想法是，如果我在每个表上都有帐户ID，这将使获得所有数据变得更加容易，而无需从其他帐户返回数据，从而减少了性能查询的次数。我意识到还有其他方法可以解决此问题，但我们的截止日期很短，因此必须在3个月内发布约50张游戏表，以构建一个完整的应用。话虽这么说，我们也有许多查询，这些查询大量使用联接和分组方法来防止（n + 1）次访问数据库。仅仅分析大量数据就是需要更大的数据库吗？最大的问题是我们目前只有45个活跃客户。该应用程序运行速度很快，感觉很棒，我们只是在推动数据库内存的极限。当前数据库具有8Gb的Ram。
这是我所做的模式。我知道它没有针对键进行标准化，但是我阅读的所有内容似乎都不会导致此问题。但是我不是数据库专家，因此不胜感激。
Account Table:
id
first_name
...etc
Record Table:
id
account_id
address
...etc
Analysis Table:
id
account_id
record_id
expected_return_on_investment
...etc
Comps Table:
id
account_id
record_id
analysis_id
cost
...etc
首先，为了更好地理解，建议您使用实体关系图发布数据库。因为很难理解，几乎没有信息，所以不可能知道您到底要什么。尽管如此，我会尝试回答（也许我没有回答您的期望）。
Account表ID应该是所有其他表上的account_id。排序数据以从客户端获取（例如）所有记录时，将使用account_id搜索所有记录。然后，要区分它们，可以使用id。另外，您不需要在分析和合成中添加account_id；同样，您不应将record_id添加到Analysis。最后但并非最不重要的是，Comps中不需要record_id。为什么？因为既然有了父元素的ID，就可以获取存储在其中的其他ID。
顺便说一句，如果您想使其更安全，我将对帐户ID进行哈希处理并将它们存储在另一个变量中，该变量称为hashID。然后，我将该哈希传递给其他表。万一有人未经授权获得该哈希，他们将无法获取该ID。如果您有权访问数据库，则通过比较哈希可以知道您所指的用户。但是，如果不这样做，就无法从该哈希中获取更多信息（如果他具有ID，则是）。