我有一种困境，似乎无法安息。
在页面上，我有一个对象列表。每个对象都是一个滑块 - 就像aribnb - https://www.airbnb.com/s/London--United-Kingdom?source=ds
在我的数据库中，我存储有关该对象的信息（除幻灯片外还有其他信息），我想，最简单的方法是将所有幻灯片的URL存储为文本块。
URL | other_field
-----------------------
url1,url2 | other stuff
然后通过将它们转换为数组等来从前端或后端处理它。
第二种方法是创建一个单独的表，我将每个url和url所属的对象的id存储在一个单独的行上
URL | obj_ID
-------------
url1 | id1
url2 | id1
url3 | id2
.............
。我会做group_concat( distinct X)并将它作为一个文本块返回给我。然后我会把它们分开来做同样的事情。
长话短说，我把它们作为一个字段存储在初始表或单独的表中，每个都是它自己的行。 这两种方法的优点和缺点是什么？对我来说，将它们作为文本放在同一个表中似乎更容易，但我对此缺乏经验，所以我需要一些建议。
编辑：最终可用的格式是JSON，幻灯片可以是数组，也可以是在适当的时候分割成数组的文本。
答案 0 :(得分：0)
答案是......这取决于。如果您认为您的URL仅仅是一个文本块中的注释，那么将它们存储在一个字段中可能是有意义的。确保将字段长度设置得足够大。
但是，如果您认为您可能需要将URL视为关系实体...那么您需要转到第二条路线。那是什么意思？那么，如果将来你需要添加一个要求，不仅要存储URL，还要存储它的简短说明，该怎么办？也许你需要添加一个活动日期来判断最后一次检查URL是否有效。也许您希望能够找到共享公共URL的对象。我不是说这些应该是你的要求;我说你不知道未来会有什么要求。如果你非常肯定这只是一个文本块而且它总是只是一个文本块，那么确定......把它放在VARCHAR（MAX）字段中。虽然随着需求的增加，你会在路上试图将更多的东西分解成一大堆文本，这会让事情变得更加艰难。
有时为了速度或简单而打破正常形式是合适的，但是你想要尽可能少地做到这一点，尽可能多地考虑未来。