单租户、多应用数据库设计？
有关租户的大多数问题都集中在多租户数据库设计问题上。我想了解单一租赁但多个应用程序。我正在开发的软件允许单个用户从单个代码库创建多个应用程序（我称之为“部分”）：
- 用户可以在domain.com/application-blog1内创建一个博客，这是域上的另一个博客。 com/application-blog2.
我已经决定为所有内容使用一个数据库，但我尚未决定是否应该为不同的应用程序实例或同一个表使用多个表，也许使用“sectionId”字段来区分它们。
我正在使用 mysql 和 myisam 表。在运行许多应用程序实例的情况下，将所有内容存储在同一个表中是否会导致锁定问题？
您在这个问题上有什么经验？
Most questions about tenancy are centered around multi-tenancy database design issues. I want to know about single tenancy but multiple applications. The software I'm developing allows for a single user to create, from a single code base, multiple applications(I call them "sections"):
- user could create a blog inside domain.com/application-blog1, another blog on domain.com/application-blog2.
I've already decided for a single database for everything But I am undecided whether or not I should use multiple tables for different application instances or the same table, maybe with a "sectionId" field to distinguish between them.
I'm using mysql and myisam tables. Could storing everything inside the same table lead to locking issues in the case of having many application instances running?
What's your experience on the subject?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我认为人们通常不会在同一个数据库中使用多个表。如果您有同一应用程序的多个实例，则通常会有单独的数据库 - 通常仅当新实例是通过管理方式创建，而不是通过最终用户操作创建时。在这种情况下，您可以将数据库的名称放入配置文件中，然后让软件连接到正确的数据库。
在你的例子中，我会选择使用sectionIds的单模式单数据库方法。这实际上与多租户相同，也许不需要进行访问控制。
当然，您将在并发事务之间进行锁定。但是，这永远不会导致问题，因为不同部分的事务不会以冲突的方式对记录进行操作（除非创建新部分 - 您可能会有另一个表告诉您有哪些部分）。
I don't think people will typically use multiple tables in the same database. If you have multiple instances of the same application, you often have separate databases - typically only if new instances are created administratively, rather than through end-user actions. In this case, you'ld put the name of the database into a configuration file, and have the software connect to the right database.
In your case, I would go for the single-schema single-database approach, using sectionIds. This really is the same as multi-tenancy, perhaps minus the need to do access control.
You will of course have locking across concurrent transactions. However, this should never cause problems, since transactions for different sections won't operate on records in a conflicting manner (except when new sections are created - you'll probably have another table telling you what sections you have).