数据库表的设计

首先建立sell.sql文件,在里面输入:

create table ‘product_info‘ (
    ‘product_id‘ varchar(32) not null,            #因为是企业级项目,防止不够用,所以用varchar字符类型。
    ‘product_name‘ varchar(64) not null comment ‘商品名称‘,
    ‘product_price‘ decimal(8,2) not null comment ‘单价‘,
    ‘product_stock‘ int not null comment ‘库存‘,
    ‘product_description‘ varchar(64) comment ‘描述‘,
    ‘product_icon‘ varchar(512) comment ‘小图‘,
    ‘category_type‘ int not null comment ‘类目编号‘,
    ‘create_time‘ timestamp not null default current_timestamp comment ‘创建时间‘,             #创建的时候使用系统时间
    ‘update_time‘ timestamp not null default current_timestamp on update current_timestamp     #自动更新时间
        comment ‘更新时间‘,
    primary key(‘product_id‘)   #主键
) comment ‘商品表‘;

create table ‘product_category‘ (
    ‘category_id‘ int not null auto_increment,    #int够用  自增
    ‘category_name‘ varchar(64) not null comment ‘类目名字‘,
    ‘category_type‘ int not null comment ‘类目编号‘,
    ‘create_time‘ timestamp not null default current_timestamp comment ‘创建时间‘,
    ‘update_time‘ timestamp not null default current_timestamp on update current_timestamp
        comment ‘更新时间‘,
    primary key (‘category_id‘),
    unique key ‘uqe_category_type‘ (‘category_type‘)   #数据库中和商品表中的类目编号唯一,所以加约束索引。
) comment ‘类目表‘;

create table ‘order_master‘ (
    ‘order_id‘ varchar(32) not null,
    ‘buyer_name‘ varchar(32) not null comment ‘买家名字‘,
    ‘buyer_phone‘ varchar(32) not null comment ‘买家电话‘,
    ‘buyer_address‘ varchar(128) not null comment ‘买家地址‘,
    ‘buyer_openid‘ varchar(64) not null comment ‘买家微信openid‘,
    ‘order_amount‘ decimal(8,2) not null comment ‘订单总金额‘,
    ‘order_status‘ tinyint(3) not null default ‘0‘ comment ‘订单状态,默认0新下单‘,
    ‘pay_status‘ tinyint(3) not null default ‘0‘ comment ‘订单状态,默认0未支付‘,
    ‘create_time‘ timestamp not null default current_timestamp comment ‘创建时间‘,
    ‘update_time‘ timestamp not null default current_timestamp on update current_timestamp
        comment ‘更新时间‘,
    primary key (‘order_id‘),
    key ‘idx_buyer_openid‘ (‘buyer_openid‘)     #还可以用openid查询某人下了什么订单,所以加了索引。
) comment ‘订单表‘; 

create table ‘order_detail‘ (
    ‘detail_id‘ varchar(32) not null,
    ‘order_id‘ varchar(32) not null,
    ‘product_id‘ varchar(32) not null,
    ‘product_name‘ varchar (64) not null comment ‘商品名称‘,
    ‘product_price‘ decimal(8,2) not null comment ‘商品价格‘,
    ‘product_quantity‘ int not null comment ‘商品数量‘,
    ‘product_icon‘ varchar(512) comment ‘商品小图‘,
    ‘create_time‘ timestamp not null default current_timestamp comment ‘创建时间‘,
    ‘update_time‘ timestamp not null default current_timestamp on update current_timestamp
        comment ‘更新时间‘,
    primary key (‘detail_id‘),
    key ‘idx_order_id‘ (‘order_id‘)
) comment ‘订单详情表‘;
     

原文地址:https://www.cnblogs.com/Evangenia/p/9927558.html

时间: 2024-10-08 08:52:05

数据库表的设计的相关文章

树形结构的数据库表Schema设计-基于左右值编码

树形结构的数据库表Schema设计 程序设计过程中,我们常常用树形结构来表征某些数据的关联关系,如企业上下级部门.栏目结构.商品分类等等,通常而言,这些树状结构需要借助于数据库完 成持久化.然而目前的各种基于关系的数据库,都是以二维表的形式记录存储数据信息,因此是不能直接将Tree存入DBMS,设计合适的Schema及其对 应的CRUD算法是实现关系型数据库中存储树形结构的关键. 理想中树形结构应该具备如下特征:数据存储冗余度小.直观性强:检索遍历过程简单高效:节点增删改查CRUD操作高效.无意

树形结构的数据库表Schema设计

今天又有幸遇到一个不知道的东西,那就是树型结构在数据库表中设计的问题.由于只是阅读了人家的东西,就直接给连接吧. 第一个:http://blog.csdn.net/monkey_d_meng/article/details/6647488 第二个:http://my.oschina.net/XYleung/blog/99604 两个讲的都是一个道理,不同的人合适不同的版本吧.都给大家吧.

数据库 表关系设计参考

表关系设计 出版社表关系 # 出版社表 class Publisher(models.Model): name = models.CharField(max_length=32) addr = models.CharField(max_length=128) phone = models.IntegerField() def __str__(self): return self.name # 作者表 class Author(models.Model): name = models.CharFi

MySQL数据库优化技术之数据库表的设计

三范式介绍表的范式:只有符合的第一范式,才能满足第二范式,进一步才能满足第三范式. 1. 第一范式:表的列具有原子性,不可再分解.只要是关系型数据库都自动满足第一范式.数据库的分类:关系型数据库:MySQL/ORACLE/Sql Server/DB2等非关系型数据库:特点是面向对象或者集合nosql数据库:MongoDB(特点是面向文档) 2. 第二范式:表中的记录是唯一的,就满足第二范式.通常我们设计一个主键来实现.主键一般不含业务逻辑,一般是自增的: 3. 第三范式:表中不要有冗余数据,即如

数据库表的设计 注意点

注意点: 如果是代码表基本不会变化的我们可以只设计  dm字段而不加pkid字段  代码表还会不断变化的话我们再加一个pkid自增长,如果涉及到外键我们要引用的是dm而不是pkid,因为这样我在导入数据的时候可以避免数据对不上.  业务表的话我们还是也加一个dm(可以guid)字段好了,Pkid自增长或者我们只要一个Id(guid)这样都是防止自增长的特性导致导入数据混乱,那么我们guid还是在前台生成好再插进去,不然同样会导致和自增长一样的导入数据混乱.

支付业务的数据库表的设计

一.数据表 数据库中的数据表是整个核心逻辑的载体说在,所有的记账逻辑.以及与支付前台交互的数据都是在这里 进行记录.现就主要的表进行简要说明.不同的第三方支付其数据表名称肯定也不同,这里的表名称仅作参考 gTransLog表: 支付网关交易流水表,所有通过网关的交易全部都会在此表中写入数据. tAccounts表: 用户的账户数据记录表,在第三方系统中其记录着用户的账上资金. tAccountLog表: 用于记录账户的自己流水情况,所有对tAccounts表的资金变动都会在流水表中进行记录 tB

粉丝关注数据库表的设计

CREATE TABLE relation ( id PRIMARY KEY AUTO_INCREMENT, //主键,自增 from_user_id big integer, // 用户 A 的 id to_user_id big integer,// 用户 B 的 Id rel_type enum(1,2) //关注数据 ); 拉黑/粉丝/关注,在数据库里,存的都是一个映射关系的数字.比如,拉黑是 1,粉丝/关注是一个东西,是 2.那么,一条记录里的关键数据是: from_user_id /

数据库表的设计(怎么设计)

1,字段的类型 除了id(主键)为int外,能够用varchar2类型的都用(方便) 2,设计字段要预留两个字段(如果一开始怕自己设计不周到,最好多预留字段) 3,字段长度适当设计长一些 原文地址:https://www.cnblogs.com/wskb/p/12085078.html

数据库表设计的随笔(分库分表)

笔者目前就职的是一家创业型的互联网公司,既然算是互联网公司,那么就会设计到无论是应用系统还是数据库的分布式.下面简单介绍下有关数据库方面的一些设计. 数据库表的设计,根据自己的业务所需可以拆分成多库.有订单库.产品库.账户库.底层支付库等等,这也就是传说中的垂直分库.那么数据库架构和数据库优化有哪些解决思路: 1.垂直分表.垂直分表也就是“一张表拆分成多张表”,比如订单表里面,有不同类型的订单,拿普通订单和一元夺宝订单来说,一元夺宝订单会有抽奖码中奖吗等等,这些是一元夺宝订单独有的,就可以单独拿