考虑这个ER设计的例子。我有三个实体：
每位歌手至少有一张专辑（按照定义），每张专辑至少有一首歌。每首歌只属于一张专辑。所以我也有两种关系：
如果我想听谁唱这首歌，我可以加入专辑实体的表格。
现在我的问题是：我是否应该添加歌手和歌曲之间的直接关系？我不明白它是否仅取决于用例或是否有严格的规则/最佳实践。如果我添加它，我会使用更多的磁盘空间，但我需要更少的内存来查询歌曲作者（我不需要加入）。
哪个是解决方案？
答案 0 :(得分：2)
（我假设那张专辑：歌手和歌曲：专辑实际上都是1或更多：完全是-1，因为你的＆＃34;一对多＆＃34; s与你的其他描述相矛盾。）
重新确定2个表：您不应该使用全部三个表。 SingerSong总是等于（SingerAlbum JOIN SongAlbum）在SINGER＆amp;歌曲。当双表设计只涉及一个并且需要多表约束来强制SingerSong和其他表之间的一致性时，使用all 3是多余的，需要更新多个表。
重新设计表：每个表都有一个含义/ 谓词以及每个当前行和＆amp;每个缺席的行（适合它）都会生成一个声明/ 命题。我们选择足够的含义/谓词来描述可能出现的所有情况。 （使用＆＃34;谓词＆＃34;来查看this基础和this重新查询和我的其他答案。＆＃34;冗余＆＃34;当两行同时产生重叠的陈述/命题时。然后我们必须在另一个设计中改变多行，我们可以改变一个。 （或更多与更少。）我们只需要知道我们选择的含义/谓词所说的。可悲的是，大多数信息建模方法和产品不是解决关系/关系的含义/谓词，即使它们是建模和基础的基础。实体 - 关系和关系模型中术语的来源。 规范化通过将其分解为AND来解决可以从含义/谓词中消除的某些冗余。 （因此，通过其他人的JOIN替换其关联的表/ 关系）。
需要3张桌子：在这里你有谓词＆＃34;歌手SINGER制作专辑ALBUM＆＃34;，＆＃34;歌曲SONG在专辑ALBUM＆＃34;和歌手歌唱歌手SONG＆＃34;。我们不能直接表达前两个方面的第三个。但是，由于第三个谓词隐含在第一个加上你的特定应用程序中的第二个 ，因此你不需要它。即＃歌手歌手歌唱SONG＆＃34;在你的应用程序中，对于某些ALBUM，歌手SINGER制作专辑ALBUM，歌曲SONG在专辑ALBUM＆＃34;。 （即谓词（SingerAlbum JOIN songAlbum）在SINGER＆SONG上的行中表示满意。）但是，如果说多个歌手可能在一张专辑中，不是既可以唱所有歌曲，也可以说有歌曲而不是专辑那么前两个并不意味着第三个，所以你既不能表达也不能推断出第三个中的行和其他行中的行。 （注意你的添加＆＃34;至少有一个＆＃34; /＆＃34;只有一个＆＃34;使谓词和约束复杂化并导致冗余设计，即使你认为你已经将建模简化为焦点关于主题的问题＆＃34;。
重新优化：始终首先制作最简单的设计。在您拥有更多设计经验和查询以了解相关因素之前，您不必担心存储和时间权衡。然后你应该使用估算和测量来证明变化的合理性。
答案 1 :(得分：1)
编辑：我刚刚意识到，你每张专辑只有一位歌手。在这种情况下，您有三种关系：
您的理解是正确的 - 您可以选择使用全部三种，以获得更多磁盘使用但更快的查询。或者，您可以只选择两个，以减少磁盘使用量和减慢查询速度。
总是根据具体情况而定 - 如果您知道可以表示与两个表的关系而不会丢失数据，那么您可以在速度和大小之间进行选择。但是，需要考虑的一个重要因素是未来的证明。比如说，将来你可能希望每张专辑有不止一个歌手。然后，不再暗示哪个歌手唱哪首歌。考虑到所有事情，它是一个数据库，所以你通常期望它大而快。