Database 多用户webapp数据库方案

我正在尝试构建一个家庭图书馆管理客户端/服务器应用程序，具有以下功能：

• 一台服务器（后端+DB）可以为多个用户服务
• 几个不同的前端可以通过一个API连接到后端，并获取他们拥有正确访问权限的JSON信息
• 每个用户都有
  • 普通ID信息（电子邮件、密码等）
  • 他可以借书/借书的许多“联系人”
  • 一份他拥有的书的清单和一份他想要的书的清单

我关心的是数据库组织的设计，因为这是我做的第一个需要两到三个以上表的“大”项目。我读过，但很难用谷歌搜索到这样一个开放性的问题，我也不确定我在可能的文档源中寻找什么功能

我的问题如下：以下哪种（或其他）数据库方案是最好的，根据：安全性、速度和易维护性，按顺序排列

每个用户信息：每个应用程序用户都有一个等效的db用户和包含书籍、作者、流派、联系人和贷款的表格。尽管在小范围内很容易实现和保护，但这似乎是一种效率很低的方法，主要是因为扩展的原因：首先，这意味着如果两个用户拥有同一本书，我将存储书的副本，这是一种浪费，而且如果我的用户数量超过了我预期的管理地狱（见问题）

一个用户来管理所有人：后端可以使用一个“myapp”用户与DB对话。这意味着所有书籍、用户、作者等只有一个表。。。但我看到了以下问题：如果全世界都使用该应用程序，这将非常有效——但我的用户主要会将书籍借给外部用户（目的是拥有一个允许选择联系人作为借书人的移动应用程序）。我想知道如何存储通常需要一个完整表的每个用户的信息，例如拥有的图书和元数据（分数、阅读次数、日期等），或者当前借阅图书的联系人列表

• 一个简单的解决方案就是将联系人添加为“未注册”用户，这样他们就有一个主用户密钥，我们就可以有一个巨大的“贷款”表。然而，这会引起安全问题：我不知道如何禁止用户与他人取得联系
• 另一种解决方案可能是使用包含注册用户信息的“系统”表和包含图书（元数据）数据的“图书”表，然后使用包含用户特定信息的myapp(用户主键)表

还有别的吗

我从来没有真正做过任何严肃的Web服务开发，因为我这样做是为了好玩，所以我不知道“通常”是如何做的。 欢迎提出任何建议、想法、建议和澄清要求

编辑：是我要存储的数据的ER图。此外，在阅读了评论中的MSDN文章（整个系列实际上都很有趣）后，我想我现在要在以下两者之间进行选择：

• 为每个人提供大表，并使用视图限制访问
• 创建每用户方案

我还认为对我的目标公众更加精确可能是一个好主意：我想创建一个小型开源服务器，可以支持少数（<100）人。客户端将能够配置他们想要连接的服务器，这样任何人都可以拥有自己的主机；如果可能的话，进行水平扩展的能力是一个目标，但我不希望有足够的用户阻塞单个DB实例

---

旁白：附带问题：从道德的角度来看，如果联系人没有任何书籍，我是否应该从联系人表中删除联系人，以尽可能少地保留除我的用户以外的其他人的信息？或者我应该优先使用并保留他们？（毕竟，一些社交网络公司根本不在乎……）

你选择了不使用SQL/RDBMS吗？如果您使用RDBMS（即MySQL），您应该仔细了解数据库规范化（即根据Codd）@Rogier从我所读到的内容来看，由于我的数据是内在关联的，所以我需要RDBMS：这就是为什么我想在初始设计方面寻求一些帮助，因为它不灵活。我已经阅读了维基的文章，虽然我理解这些指导方针和原则，但我不确定它在我的案例中的正确实现。我要说的是删除任何形式的冗余，因为你需要代码来同步它。因此，一个用户表作为开始。不过，如果你先做一个ER digram会更好，这样我们就可以看到你到底想要做什么（以及这些实体在这个时间点上是如何关联的）。读一下这篇文章，然后回来@Rogier：告诉我，如果我把ER保持得太简单，我不想让它被太多的信息扼杀，但我只是在学习。。。谢谢你的帮助！