很简单，现有一张商品表（goods），里面有3个字段（id自增主键，name商品名字，price价格）；
现在准备设计一张订单表（order），要求一张订单可能包含一个或多个商品，而且商品数量不定，那么应该如何设计这个订单表（order）呢？
我自己想到两种方案：
1、再额外设计一张中间表（order-goods）把它们关联起来，此表包括字段（order-id、goods-id、goods-num），每个订单的每有一个独立商品就添加一条记录到此表；
2、在订单表（order）里设计一个关联商品字段（goods-info），里面记录有商品id和商品数量拼出来的字符串，譬如某订单里有52号商品3件，166号商品4件，那么此订单的关联商品字段（goods-info）就记录着“52:3,166:4”这么一个字符串。
我个人是偏向于第二种方案，因为不用额外设计一张表，添加修改查询的时候都方便很多，只要取出关联商品字段（goods-info）后处理一下数据就可以了。
大神们能点评一下这两种方案吗？或者有更好更科学的设计方案吗？望指教~
这个是需要一个中间表的。你可以想想，订单肯定需要和用户关联。
用户表要有用户的基本信息，然后一个用户的id号，在订单表中建立外键。订单表u_id 是用户的ID号，可以存在多个同类型的u_id,再有一个外键关联
商品表的id。这样就能实现了。
建议楼主采用第一种方案。中间表的处理可以给增删查改带来更大的优势，他不需要再取出数据后还单独处理一个字段。
建议第一种方案。
只是概念上不要用中间表去理解，而是作为订单明细表，与订单表是多对1关系。后续有业务变化时，跟订单的业务逻辑变化。
第二种方案是脱离实际业务中的“订单”概念的，“1个订单含多个商品”这样的基本逻辑都体现不了的。
必须是需要中间表的....
第一种吧，，如果是hibernate的话，稍微一配置 多对多关联，，不麻烦，
订单表， 商品表，订单明细表， 及符合逻辑，可扩展，查询，处理都方便。
你的第二中方案应该是体现在比如要加一个功能这个订单有哪些管理员查看过。就可以在订单表中加一个字段u_ids, 里面就存储8,9,10 这样的字符串数据
第一种，第二种是不科学的，没有人会那没做。