数据库小白求教

[xhuuanniqege]

我正在练习做一个 APP,现在需要在服务器保存用户信息。我新建了一个 USERINFO 的表，表中有一个名为 ORDER 的列，表示该用户的历史订单号。可是一个用户有很多个订单，这样的话，对于每个用户该 ORDER 属性下面就应该保存很多个订单号。这个好像没法实现。如果为每一个用户在创建一个 ORDER 的表，那么这个表只有两列，用户 ID 和订单号，似乎很浪费啊。请问在这种情况下我该怎么组织数据库？

[chenzhuo]

应该创建一个订单表 Order,订单表里有一个字段是记录用户 id 的。这样根据用户 id 就能查到每个用户的所有订单了。

[xhuuanniqege]

@chenzhuo 这样的话，每次要获得某个 ID 用户所有订单，就要用 select * from Order where user_id = xxx ，会不会效率不高？

[oott123]

@xhuuanniqege 不会。给 user_id 加个索引。

[heaton_nobu]

关系型数据库就是要建子表

[guoer]

1 楼正解

最好不要用 order 因为是关键字

[xhuuanniqege]

@oott123
@heaton_nobu
@guoer
多谢建议，我准备看看有关索引和关系型数据库的内容

[yjxjn]

主 userid 为 primary key ，然后子表写订单号为 pri key ， userid 为 f key ，这样的话最后做表关联不就行了么，这种肯定得做两个表，一个主表，一个附表，这样的话，效率很高，单独检索订单号的时候，查某人的订单的时候，等等，不信你可以想想。

[xhuuanniqege]

@yjxjn 嗯，我现在正打算这么做。另外在请教下，现在一个订单是由多个商品组成的，我是不是应该在建个 order_item 表
table order_item (
order_id int(10),
product_id int(10),
quantity
)

[ETiV]

LZ 听说过 Facebook Parse, 或者国内的 LeanCloud 没

BaaS 服务, 专注解决后端问题, 直接调用他们的客户端 SDK 就行了. 简单需求几乎不需要写服务端逻辑.

[shiny]

一般 生产环境的情况是：哪有那么多订单啊。你想多了。

[yjxjn]

@xhuuanniqege 对，每个商品有一个单独的 ID ，很多商品 ID 属于同一个订单 ID ，还得来个表， productList 定义好商品名称，编号（算是二维码那种的），入库时间，库存等等，然后相互关联就可以了。

[yjxjn]

这种东西别想着几张表就可以完事，我们的系统，总共 100 多张表。索引建立好，相互关联的写就行了

[GKLuke]

搞数据库之前先了解一下 3NF （ BCNF ）

[xhuuanniqege]

@yjxjn 原来是这样，感谢！

[xhuuanniqege]

@GKLuke 谢谢，目前正在边学边看