为具有多种数据类型的模型设计数据库模式
这个问题是关于数据库设计以及如何最好地分割你的数据库 当实体服务于多个目的时。
我的数据库模式模拟了世界各地的体育赛事。什么类型的 赛事和运动、比赛时间和地点、参与者内容 是和获胜者等等。架构中的实体之一是 记录这项运动在世界哪个国家进行的国家 事件发生在。
这效果很好，但是我还需要将辅助数据添加到 国家模式，与体育赛事模式本身无关， 但需要在网页上很好地呈现数据。
该数据的示例是国家国旗精灵在 精灵图像、对该国家/地区的详细描述、该国的形容词 国家（中国 - 中文等），国家页面上的访问者数量 以及国家的主观重要性（从 1 到 5） （排名为 5 的国家/地区的活动显示在首页上）。
我可以轻松地将所有这些属性放在 Country 对象本身上， 但这似乎是错误的，并且污染了我干净的体育赛事模式。我不 认为数据的结构应该与细节混合在一起，比如如何 很好地渲染它......所以问题是我应该如何组织它 反而？
This question is about database design and how to best split your
entities when they serve more than one purpose.
My database schema models sports events around the world. What type of
event and sport, when and where it is played, what the participants
are and the winner and so on. One of the entities in the schema is
Country which keeps track of in which country in the world the sport
event took place in.
This works well, but then I also need to add auxilliary data to the
Country model, which is not related to the sport events model per se,
but is required for rendering the data nicely on a web page.
Examples of that data is the countrys flags sprite offset in the
sprite image, a long description of the country, the adjective for the
country (China - chinese etc), number of visitors on the country page
and the subjective importance of the country on a scale from 1-5
(events in countries rated five are shown on the front page).
I could easily put all those attributes on the Country object itself,
but it seems wrong, and pollutes my clean sports event schema. I don't
think the structure of the data should be mixed with details like how
to render it nicely... So the question is how I should organise it
instead?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我会将这些数据保存在“国家/地区”表中，并为您的体育数据创建一个 FK。这将使您能够轻松维护每个国家/地区的属性，因为您只需在一处更新它们，并且更改将在引用的所有地方生效。我认为这不会污染您的数据，因为这些信息与您的应用程序相关。此外，如果您确实尝试分离这些数据，只会使您的模式更加复杂并且维护更加困难。
I would keep this data on a 'Countries' table and create a FK to your sports data. This will allow you to easily maintain each Country's attributes as you will only have to update them in one place and the changes will take effect everywhere it is referenced. I don't think this pollutes your data as the information is relevant to your application. Furthermore, if you do try to separate this data it will only make your schema more complex and maintenance more difficult.