T-SQL标记数据库体系结构设计？
设想
我正在建立一个包含一系列不同表的数据库。这些由COMMENTS表，BLOGS表和ARTICLES表组成。我希望能够向每个表中添加新项目，并使用0到5个标签对其进行标记，以帮助用户更轻松地搜索相关的特定信息。
有关建筑的初步想法
我最初的想法是拥有一个集中的TAGS表。该表将使用TagID字段和TagName字段列出所有可用标签。由于每个项目可以有很多标签，并且每个标签可以有很多项目，因此我需要在每个项目表和TAGS表之间建立多对多关系。
例如：
许多注释可以具有许多标签。许多标签可以有许多评论。
许多文章可以具有许多标签。许多标签可以包含许多文章。
等等.....
当前的理解
从以前的经验中，我了解到在T-
SQL中实现此结构的一种方法是在COMMENTS表和TAG表之间有一个关联表。该连接表将包含CommentID和TagID，以及其自己的唯一CommentTagID。此结构也将适用于所有其他项目。
问题
首先，这是实现这种数据库体系结构的正确方法吗？如果没有，还有什么其他方法可行？由于数据库最终将包含大量信息，因此我需要确保其可伸缩性。这是可扩展的实现吗？如果我有很多这样的表，那么此体系结构会使CRUD操作非常慢吗？我应该对ID字段使用GUID还是递增INT？
帮助和建议将不胜感激。
谢谢你。
问题答案：
-
我经常听说，在微服务架构中，对于每一个微服务，我们都必须创建单独的数据库。 但是，如果我必须在不同的数据库中维护外键约束，这是不可能的。就像我在身份验证微服务中有一个用户表，我想在我的目录服务中使用它（用户表中的用户 ID 列） 那么如何解决呢。 感谢提前
-
问题内容： 我听说过几种实现标记的方法；使用TagID和ItemID之间的映射表（对我来说有意义，但是可以缩放吗？），向ItemID添加固定数量的可能的TagID列（似乎是个坏主意），将标签保持在逗号分隔的文本列中（声音疯狂但可以工作）。我什至听说有人建议使用稀疏矩阵，但是标记名称又如何优雅地增长呢？ 我是否错过了标签的最佳做法？ 问题答案： 三个表（一个用于存储所有项目，一个用于所有标签，一个用
-
与家装行业的初创公司合作。这是一个SaaS模式——多租户系统。每个账户都是唯一识别的，所有客户、项目和其他数据都是使用唯一的账号识别的。我们使用的是MVC框架，用户登录时查询使用账户会话。随着我们的不断发展，我不断重新思考我所做的事情——担心交叉污染和其他多租户问题。 有没有什么好的“最佳实践”链接，或者我到目前为止做过什么？我认为我关心的是一件好事，因为我知道的数据，结构和诸如此类。我觉得这比不
-
我们有一个单片应用程序，我们现在正在使用容器将其转换为微服务架构。 每种方法的利弊是什么？根据微服务最佳实践，什么是最佳方法？*
-
另一种方式，我认为是水平分割当前结构。所以我的领域是基于一些教育大学。因此，一半的大学低于一分贝，剩下的将低于另一分贝。并根据两个地区部署服务（两个针对两套大学）。 目前，我决定继续采用最后提到的方法。我对这些类型的任务是新的，因为它涉及一些体系结构任务。我也是微服务和分布式数据库领域的初学者。有人能证实我的方法能解决我的问题吗？我可以继续我的第二种方法--根据域对象对数据库进行水平分区吗？
-
我正在将nTier架构迁移到六边形架构中。我的域现在定义得很好，我有所有基础设施依赖项的接口。查看数据库存储库，我有几个数据库，在下面的一侧有一个类实现每个repo。我的问题是关于数据库依赖项的正确方法是什么： 1-在域端有一个接口来处理数据访问，然后依赖于基础设施实现，并有一个类作为所有数据库存储库的入口点，就像一个facade，从那里调用所有存储库实现。这种方法与我在nTier应用程序中已经使