我有几个结构:用户、项目、收藏项。
用户有很多项目,并且可以有很多 faourite 项目(仅链接到项目)。
我已经决定要么创建一个模型:“FavouriteItem”并为用户提供这些列表,或者将最喜欢的项目 ID 存储在用户表的列中。即 favourite_items:“1,2,5,9”。
如果用户群增长,后者似乎会快很多,但是我不得不拆分字符串、创建数组等,这有点痛苦。
在这里推荐的选择是什么?我已经完成了较早的选项,并且喜欢它的灵活性/易用性,但有点担心它的可扩展性。
我有几个结构:用户、项目、收藏项。
用户有很多项目,并且可以有很多 faourite 项目(仅链接到项目)。
我已经决定要么创建一个模型:“FavouriteItem”并为用户提供这些列表,或者将最喜欢的项目 ID 存储在用户表的列中。即 favourite_items:“1,2,5,9”。
如果用户群增长,后者似乎会快很多,但是我不得不拆分字符串、创建数组等,这有点痛苦。
在这里推荐的选择是什么?我已经完成了较早的选项,并且喜欢它的灵活性/易用性,但有点担心它的可扩展性。
User、Item、UserItem 怎么样(链接表有一个 IsFavouriteItem 位字段。所以 UserId、ItemId、IsFavouriteItem 作为列)?
最佳选择在某种程度上取决于您将在应用程序中体验到的查询模式。我将假设项目特定于用户,而不是在用户之间共享。根据您所说的,我会采用如下结构:
public class User
{
public IList<Item> Items { get; set; }
public IEnumerable<Item> FavoriteItems
{
get
{
return from i in Items where i.IsFavorite select i;
}
}
}
public class Item
{
public bool IsFavorite { get; set; }
}
如果每个用户的项目列表不是很大,即使您有很多用户和很多项目,这也会很好地工作。
就速度而言,如果您希望表存储大量数据,则将其存储FavouriteItems
在表中可能会更有效。User
但是,如果您想要一个干净、结构化的数据库,那么我会引入一个UserItems
带有Favourite
列的外键表,例如
UserItems
---------
UserId
ItemId
Favourite
如果您开始遇到瓶颈,您始终可以优化您的查询。