一篇文章同时有多个推荐位 数据库该怎么设计？ - ThinkPHP框架
比如现在程序有自定义了多个推荐位：首页推荐、栏目推荐、内页推荐....
一篇文章同时选择多个推荐位，这样数据库该怎么设计好呢？
我目前想到2个方法：
1、只用一个pos字段，如果选择多个推荐位，那字段内容就是 “1,2,3”（分别是推荐位ID），到时候通过like来查询，但是效率低
2、设置3个pos字段，pos1、pos2、pos3分别是不同推荐位的字段，查询效率高，但是如果推荐位很多，会有很多字段，不够人性化。
各位前辈，指教下~~~非常感谢
积分：2119
ThinkPHP 是一个免费开源的，快速、简单的面向对象的 轻量级PHP开发框架 ，创立于2006年初，遵循Apache2开源协议发布，是为了敏捷WEB应用开发和简化企业应用开发而诞生的。ThinkPHP从诞生以来一直秉承简洁实用的设计原则，在保持出色的性能和至简的代码的同时，也注重易用性。并且拥有众多的原创功能和特性，在社区团队的积极参与下，在易用性、扩展性和性能方面不断优化和改进，已经成长为国内最领先和最具影响力的WEB应用开发框架，众多的典型案例确保可以稳定用于商业以及门户级的开发。电影网站中的分类数据库设计问题，是不是该用一对许多的设计？ - CNode技术社区
这家伙很懒，什么个性签名都没有留下。
Mongodb的数据库
当前的分类是一对多：
分类名称：string，
分类的电影：[{objectId} , {objectId} , {objectId} , {objectId} , {objectId} , …]
//电影达到几万部部时是不是还可行？
电影名称：string，
导演：string，
演员：string，
当电影数量达到了10w部，单个分类下有1w部电影，这样的数据库还够吗？是否需要设计成一对许多？这样的写法对吗？
分类名称： string，
详细分类：{objectId}
电影详情：{objectId}
电影名称：string，
导演：string，
演员：string，
求回答！求告诉我正确的方法
mongodb单文档大小限制为16M，所以就看你单个分类的电影信息最大能有多大！
16M能保存多少个objectId?有点不懂
objectid大小是12个字节，自己算下1M最多能存多少个objectid, 再加上你其他数据。。。估算一下能存个百八十万
具体如何设计还要根据应用场景！ 在电影详情里面加一个分类ID不更好？
为什么不把分类ID 或者直接把分类名称存在电影详情里面呢
有一个比较粗糙的准则是: 几个到十几个用 subdocument, 几十个到几百个用 ObjectId array, 再多的话把 [一] 的 ObjectId 存到 [多] 的文档里
当然了, 凡事无绝对, 要视具体情况而定
CNode 社区为国内最专业的 Node.js 开源技术社区，致力于 Node.js 的技术研究。
服务器赞助商为
，存储赞助商为
，由提供应用性能服务。
新手搭建 Node.js 服务器，推荐使用无需备案的一个类似京东的数据库设计问题这是京东的产品页京东的产品属性分为第一种
一种是主分类 例如: 首页 & 家居、厨具、家装 & 家纺 & 床品件套& 第二种
是下面的 商品筛选
有类别 品牌 规格 价格 这些可以交叉查询 我分类设计成2张表 一张是主表 保存主分类 另外一张表是辅助表 保存 辅助分类的(就是类别 品牌 规格等东西)在输入产品的时候 主表的数据可以保存到属性表
采用线性设计& ID 产品ID 分类ID
前台搜索该分类下面的产品的时候 是没问题的& 而辅助分类表的属性保存就麻烦了采用分字段设计 肯定是行不通的,只有采用线性设计 不如有该页面的品牌 富安娜 类别的 三件套& 数据库设计ID 产品ID 辅助分类ID再前台查询的时候 根据主分类毕竟容易 可以直接在主属性表里面查询分类ID就可以得到要找的产品当涉及到辅助分类交叉查询的时候就犯难了,不知道怎么查询了& 先根据主表查询主分类ID 得到所有产品列表 再根据这些列表查询辅助分类属性表 交叉 如果同时满足 富安娜 三件套& 那么就必需满足 产品=床品套件 品牌=富安娜 类别=三件套 &难道这样查询 产品主分类ID=床品套件 然后 辅助分类ID in(富安娜,三件套)
& 或者辅助分类表和主分类表合并成一张表直接 分类ID in(床品套件,富安娜,三件套) & 这时就糊涂了 想不通了 模糊的感觉 这样查询都是错误的
回答1：表：1：类表表 A2：品牌表 B3：规格表 C......10:工艺表11：产品表(类别ID,品牌ID，规格ID）F查询select a.name,b.name,c.name from F inner join A on F.类别ID=A.类别ID inner join b on .....我觉得应该是这样设计的。ID作为主键关联，多表查询效率也不会很差。
回答2：类别 品牌 规格这是3个表，表里面有多少记录，就没关系了吧。类别多，表还是一个，只是多一条记录而已。
回答3：楼主说的两张表想把数据全部管理起来肯定不行.我估计也是会按产品种类,品牌,型号,价格等多个表的设计.我的体会是设计越简单,查询条件会越复杂;设计越复杂,查询起来逻辑反而简单.至于效率,在逻辑清楚的情况下再做考虑,因为首先保证你对查询需求的正确理解------即查出正确的结果是最重要的.
回答4：探讨类别 品牌 规格这是3个表，表里面有多少记录，就没关系了吧。类别多，表还是一个，只是多一条记录而已。
回答5：lz好像把商品的分类与商品的属性混淆了。举个例子：商品的分类如下：&xml&
&one id=&01 000 000& attr=&图书、音像&&
&two id=&01 001 000& attr=&音像&&
&three id=&01 001 001& attr=&音乐&$>$/three&
&three id=&01 001 002& attr=&影视&$>$/three&
&three id=&01 001 003& attr=&教育音像&$>$/three&
&two id=&01 002 000& attr=&文艺&&
&one id=&02 000 000& attr=&手机数码&&
&one id=&03 000 000& attr=&家用电器、汽车用品&&
...&/xml&假设id长度为8，前两位表示第一级菜单，中间3位表示第二级菜单，后面3位最后级菜单就拿床上4件套来举例，商品本身的属性有：品牌，价格，风格，工艺,...等.这些属性也可以用xml来表示，比如价格：&xml&
&element&1-99&/element&
&element&100-199&/element&
&element&200-299&/element&
&element&300-399&/element&
....&xml&如果床上4件套分类菜单时的id是 09 021 039将所有分类和此分类包含的商品属性做关联，那我通过039这个尾号就可以找到所有此类商品的所有属性了。1.原始单据与实体之间的关系可以是一对一、一对多、多对多的关系。在一般情况下，它们是一对一的关系：即一张原始单据对应且只对应一个实体。在特殊情况下，它们可能是一对多或多对一的关系，即一张原始单证对应多个实体，或多张原始单证对应一个实体。这里的实体可以理解为基本表。明确这种对应关系后，对我们设计录入界面大有好处。
〖例1〗：一份员工履历资料，在人力资源信息系统中，就对应三个基本表：员工基本情况表、社会关系表、工作简历表。这就是“一张原始单证对应多个实体”的典型例子。
2.主键与外键一般而言，一个实体不能既无主键又无外键。在E—R图中,处于叶子部位的实体,可以定义主键，也可以不定义主键(因为它无子孙),但必须要有外键(因为它有父亲)。主键与外键的设计，在全局数据库的设计中，占有重要地位。当全局数据库的设计完成以后，有个美国数据库设计专家说：“键，到处都是键，除了键之外，什么也没有”，这就是他的数据库设计经验之谈，也反映了他对信息系统核心(数据模型)的高度抽象思想。因为：主键是实体的高度抽象，主键与外键的配对，表示实体之间的连接。
3.基本表的性质基本表与中间表、临时表不同，因为它具有如下四个特性：(1)原子性。基本表中的字段是不可再分解的。(2)原始性。基本表中的记录是原始数据（基础数据）的记录。(3)演绎性。由基本表与代码表中的数据，可以派生出所有的输出数据。(4)稳定性。基本表的结构是相对稳定的，表中的记录是要长期保存的。理解基本表的性质后，在设计数据库时，就能将基本表与中间表、临时表区分开来。
4.范式标准基本表及其字段之间的关系,应尽量满足第三范式。但是，满足第三范式的数据库设计，往往不是最好的设计。为了提高数据库的运行效率，常常需要降低范式标准：适当增加冗余，达到以空间换时间的目的。
〖例2〗：有一张存放商品的基本表，如表1所示。“金额”这个字段的存在，表明该表的设计不满足第三范式，因为“金额”可以由“单价”乘以“数量”得到，说明“金额”是冗余字段。但是，增加“金额”这个冗余字段，可以提高查询统计的速度，这就是以空间换时间的作法。在Rose2002中，规定列有两种类型：数据列和计算列。“金额”这样的列被称为“计算列”，而“单价”和“数量”这样的列被称为“数据列”。表1商品表的表结构商品名称商品型号单价数量金额电视机29吋2,
5.通俗地理解三个范式通俗地理解三个范式，对于数据库设计大有好处。在数据库设计中，为了更好地应用三个范式，就必须通俗地理解三个范式(通俗地理解是够用的理解，并不是最科学最准确的理解)：第一范式：1NF是对属性的原子性约束，要求属性具有原子性，不可再分解；第二范式：2NF是对记录的惟一性约束，要求记录有惟一标识，即实体的惟一性；第三范式：3NF是对字段冗余性的约束，即任何字段不能由其他字段派生出来，它要求字段没有冗余.没有冗余的数据库设计可以做到。但是，没有冗余的数据库未必是最好的数据库，有时为了提高运行效率，就必须降低范式标准，适当保留冗余数据。具体做法是：在概念数据模型设计时遵守第三范式，降低范式标准的工作放到物理数据模型设计时考虑。降低范式就是增加字段，允许冗余。
6.要善于识别与正确处理多对多的关系若两个实体之间存在多对多的关系，则应消除这种关系。消除的办法是，在两者之间增加第三个实体。这样，原来一个多对多的关系，现在变为两个一对多的关系。要将原来两个实体的属性合理地分配到三个实体中去。这里的第三个实体，实质上是一个较复杂的关系，它对应一张基本表。一般来讲，数据库设计工具不能识别多对多的关系，但能处理多对多的关系。
〖例3〗：在“图书馆信息系统”中，“图书”是一个实体，“读者”也是一个实体。这两个实体之间的关系，是一个典型的多对多关系：一本图书在不同时间可以被多个读者借阅，一个读者又可以借多本图书。为此，要在二者之间增加第三个实体，该实体取名为“借还书”，它的属性为：借还时间、借还标志(0表示借书，1表示还书)，另外，它还应该有两个外键(“图书”的主键，“读者”的主键)，使它能与“图书”和“读者”连接。
7.主键PK的取值方法PK是供程序员使用的表间连接工具，可以是一无物理意义的数字串,由程序自动加1来实现。也可以是有物理意义的字段名或字段名的组合。不过前者比后者好。当PK是字段名的组合时，建议字段的个数不要太多，多了不但索引占用空间大，而且速度也慢。
8.正确认识数据冗余主键与外键在多表中的重复出现,不属于数据冗余，这个概念必须清楚，事实上有许多人还不清楚。非键字段的重复出现,才是数据冗余！而且是一种低级冗余，即重复性的冗余。高级冗余不是字段的重复出现，而是字段的派生出现。
〖例4〗：商品中的“单价、数量、金额”三个字段，“金额”就是由“单价”乘以“数量”派生出来的，它就是冗余，而且是一种高级冗余。冗余的目的是为了提高处理速度。只有低级冗余才会增加数据的不一致性，因为同一数据，可能从不同时间、地点、角色上多次录入。因此，我们提倡高级冗余(派生性冗余)，反对低级冗余(重复性冗余)。
9.E--R图没有标准答案信息系统的E--R图没有标准答案，因为它的设计与画法不是惟一的，只要它覆盖了系统需求的业务范围和功能内容，就是可行的。反之要修改E--R图。尽管它没有惟一的标准答案，并不意味着可以随意设计。好的E—R图的标准是：结构清晰、关联简洁、实体个数适中、属性分配合理、没有低级冗余。
10.视图技术在数据库设计中很有用与基本表、代码表、中间表不同，视图是一种虚表，它依赖数据源的实表而存在。视图是供程序员使用数据库的一个窗口，是基表数据综合的一种形式,是数据处理的一种方法，是用户数据保密的一种手段。为了进行复杂处理、提高运算速度和节省存储空间,视图的定义深度一般不得超过三层。若三层视图仍不够用,则应在视图上定义临时表,在临时表上再定义视图。这样反复交迭定义,视图的深度就不受限制了。
对于某些与国家政治、经济、技术、军事和安全利益有关的信息系统，视图的作用更加重要。这些系统的基本表完成物理设计之后，立即在基本表上建立第一层视图，这层视图的列数和结构，与基本表的列数和结构是完全相同。并且规定，所有的程序员，一律只准在视图上操作。只有数据库管理员，带着多个人员共同掌握的“安全钥匙”，才能直接在基本表上操作。请读者想想：这是为什么？
11.中间表、报表和临时表中间表是存放统计数据的表，它是为数据仓库、输出报表或查询结果而设计的，有时它没有主键与外键(数据仓库除外)。临时表是程序员个人设计的，存放临时记录，为个人所用。基表和中间表由DBA维护，临时表由程序员自己用程序自动维护。
12.完整性约束表现在三个方面域的完整性：用Check来实现约束，在数据库设计工具中，对字段的取值范围进行定义时，有一个Check按钮，通过它定义字段的值城。参照完整性：用PK、FK、表级触发器来实现。用户定义完整性：它是一些业务规则，用存储过程和触发器来实现。
13.防止数据库设计打补丁的方法是“三少原则”(1)一个数据库中表的个数越少越好。只有表的个数少了，才能说明系统的E--R图少而精，去掉了重复的多余的实体，形成了对客观世界的高度抽象，进行了系统的数据集成，防止了打补丁式的设计；(2)一个表中组合主键的字段个数越少越好。因为主键的作用，一是建主键索引，二是做为子表的外键，所以组合主键的字段个数少了，不仅节省了运行时间，而且节省了索引存储空间；(3)一个表中的字段个数越少越好。只有字段的个数少了，才能说明在系统中不存在数据重复，且很少有数据冗余，更重要的是督促读者学会“列变行”，这样就防止了将子表中的字段拉入到主表中去，在主表中留下许多空余的字段。所谓“列变行”，就是将主表中的一部分内容拉出去，另外单独建一个子表。这个方法很简单，有的人就是不习惯、不采纳、不执行。数据库设计的实用原则是：在数据冗余和处理速度之间找到合适的平衡点。“三少”是一个整体概念，综合观点，不能孤立某一个原则。该原则是相对的，不是绝对的。“三多”原则肯定是错误的。试想：若覆盖系统同样的功能，一百个实体(共一千个属性)的E--R图，肯定比二百个实体(共二千个属性)的E--R图，要好得多。提倡“三少”原则，是叫读者学会利用数据库设计技术进行系统的数据集
阅读(...) 评论()}