数据库设计：更大的表与查询数据表中每一行的实体
我有一个 NewsFeed 表。新闻源
+ ID
+ 来自用户 ID
+ 目标 ID
+ 输入
，新闻如下：Tom Wakefield 对 Peter Smith 的个人资料发表了评论。
因此，我要么在 NewsFeed 调用 fromUserName 和 targetUserName 中添加两个字段
OR
对于我在数据表中显示的每一行，我都会从实体进行查询。
<p:dataTable value="#{myBean.news}" var="item">
<p:column>
<h:outputText value="#{myBean.getName(item.fromUserId)} " />
<h:outputText value="commented on " />
<h:outputText value="#{myBean.getName(item.targetId)}" />
</p:column>
</p:dataTable>
然后在myBean.java
myBean.java
public String getName(Long userId){
User u = mySessionBean.findUserById(userId);
return u.getFName() + " " + u.getLName();
}
里面哪种方式更好？在每一行上进行查询是否真的会对性能造成很大的影响
注意：数据库预计会有很多用户。 新闻经常显示。
I have a table of NewsFeed.NewsFeed
+ id
+ fromUserId
+ targetId
+ type
so the news is like this: Tom Wakefield commented on Peter Smith's profile.
So either I add two more fields into my NewsFeed call fromUserName and targetUserName
OR
For every row I display in my dataTable I would query from the Entity.
<p:dataTable value="#{myBean.news}" var="item">
<p:column>
<h:outputText value="#{myBean.getName(item.fromUserId)} " />
<h:outputText value="commented on " />
<h:outputText value="#{myBean.getName(item.targetId)}" />
</p:column>
</p:dataTable>
then inside myBean.java
myBean.java
public String getName(Long userId){
User u = mySessionBean.findUserById(userId);
return u.getFName() + " " + u.getLName();
}
Which way is better? Does making query at every row really hurting me a lot in term of performance
Note: the database expect to have lot of users. News are display very often.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
IOW：仅记录 ID 并使用 JOIN 获取整个数据。
IOW: record only the IDs and use JOINs to get the whole data.
不。
复制数据会导致比它解决的问题更多的问题。
重复的关系使得更新几乎不可能正确处理。
对象关系管理器可以（并且经常这样做）生成适当的 SQL 连接来优化获取。 ORM 也有缓存。并且数据库有缓存。
第二和第三范式相当于以下规则：不要重复关系。
在极少数情况下，您可以“非规范化”并提高性能，而无需创建复杂的更新逻辑。在大多数其他情况下，重复的数据会导致更新和插入变得复杂或缓慢或两者兼而有之。
No.
Duplicating data causes more problems than it solves.
Duplicated relationships make updates nearly impossible to process correctly.
Object-Relational Managers can -- and often do -- generate proper SQL joins to optimize the fetches. Also ORM's have cache. And the database has cache.
The 2nd and 3rd normal forms amount to the following rule: Do Not Duplicate Relationships.
In rare cases you can "denormalize" and improve performance without creating complex update logic. In most other cases, the duplicated data leads to updates and inserts that are either either complex or slow or both.