产品表与分类表数据库设计

合集下载

网上购物数据库设计

网上购物数据库设计

一、概述1.1需求背景伴着电子时代的迅猛发展和人民物质生活的水平的提高,越来越多的电子购物浪潮也汹涌而来。

我们容身在这个信息化的大时代,网购也就成了许多人生活中必不可少的一部分,足不出户的便捷式购物与传统的购物方式大相径庭,人们在享受到方便、实惠的同时也不必担忧安全的问题,既方便了自身也推动着国家经济的发展。

电子商务网络购物平台,无疑是这个时代的进步。

1.2编写目的数据库设计说明书是数据库设计的必要部分,对设计中的数据库的所有标识、逻辑结构和物理结构作出具体的设计规定。

本数据库的设计说明书编写的目的是对网上购物系统设计的说明,明确系统中的各项功能与非功能的需求,从而做出系统的数据流图以及实体联系图。

作为系统的基准文档,为以后的开发和维护提供依据。

1.3软件定义Myeclipse 10.0:一个非常优秀的用于开发Java、J2EE的Eclipse插件集合,Myeclipse功能非常强大,支持也十分广泛,尤其对各种开源产品的支持也不错。

Apache Tomcat 6.0:是一个开放源代码、运行servlet和JSP Web应用软件容器。

Microsoft SQL Server 2005:Structured Query Language1.4开发环境本电子商务网络购物平台的开发环境是Windows 7、Myeclipse10.0、Apache Tomcat6.0,数据库环境是Microsoft SQL Server 2005。

二、需求分析2.1问题陈述设计网络购物系统的数据库。

2.1需完成的功能客户功能:(1) 游客可以查看商品信息,浏览网站信息,经过注册可以成为注册客户。

(2) 注册客户:注册、客户信息查看和修改。

客户登录、确认客户信息,显示客户信息。

商品信息浏览、购物车管理、商品查找、订单查询以及商品评论。

结账、确认订单、订单状态查询、历史订单查询。

商家功能:商品的增删改。

订单处理、订单配送。

客户注册后,登录到电子商务网站,进入购物流程。

数据库设计说明书

数据库设计说明书

数据库设计说明书一、背景随着信息化时代的到来,数据库管理系统在各个领域得到广泛应用,数据库设计成为信息系统中至关重要的一环。

本文描述了一个虚拟企业的数据库设计,旨在解决该企业业务数据管理方面的需求。

二、需求分析1. 数据库目标建立一个可靠、高效、安全的数据库系统,满足企业对业务数据的存储、管理和查询需求。

2. 数据库功能•实现数据的高效存储和检索•确保数据的完整性和一致性•支持不同数据表之间的关联和查询•提供权限管理和数据安全保障三、数据库设计1. 实体关系模型(ERM)以下是本数据库的实体-关系模型设计:•公司(Company)–公司ID (CompanyID)–公司名称 (CompanyName)–公司地址 (CompanyAddress)•员工(Employee)–员工ID (EmployeeID)–姓名 (EmployeeName)–部门 (Department)–职位 (Position)•产品(Product)–产品ID (ProductID)–产品名称 (ProductName)–价格 (Price)•订单(Order)–订单ID (OrderID)–员工ID (EmployeeID)–产品ID (ProductID)–订单日期 (OrderDate)2. 数据表设计公司表(Company) | 公司ID | 公司名称 | 公司地址 | |——–|——–|———| | 1 | XX公司 | xx地址 | | 2 | YY公司 | yy地址 |员工表(Employee) | 员工ID | 姓名 | 部门 | 职位 | |——–|—–|—-|—-| | 1 | 张三 | 开发部 | 工程师 | | 2 | 李四 | 销售部 | 主管 |产品表(Product) | 产品ID | 产品名称 | 价格 | |——–|——–|—–| | 1 | 产品A | 100 | | 2 | 产品B | 200 |订单表(Order) | 订单ID | 员工ID | 产品ID | 订单日期 | |——–|——–|——–|———| | 1 | 1 | 1 | 2022-01-01 | | 2 | 2 | 2 | 2022-01-02 |四、安全性和性能考虑1. 安全性•数据备份和恢复策略•访问权限控制•数据加密传输2. 性能•索引优化•查询语句调优•适当的硬件资源配置五、总结本文介绍了一个虚拟企业的数据库设计说明书,包括需求分析、数据库设计、安全性和性能考虑等内容。

产品关系表结构设计

产品关系表结构设计

产品关系表结构设计产品关系表结构设计一、引言在数据库管理中,表结构设计是至关重要的。

一个良好的表结构设计可以提高数据存储效率、保证数据完整性、提升查询性能,以及便于后期维护和扩展。

本文将重点探讨产品关系表的结构设计,以帮助企业或组织更好地管理产品信息。

二、产品关系表设计目标产品关系表的设计目标主要包括以下几点:高效存储产品信息:通过合理的数据类型和字段设计,确保产品信息的准确、完整存储。

保证数据完整性:通过设置主键、外键等约束,确保数据的准确性和一致性。

提高查询性能:通过合理的数据分区、索引设计等手段,提高查询速度。

便于维护和扩展:设计时应考虑未来的数据增长和业务变化,使表结构易于调整和维护。

三、产品关系表结构设计以下是一个典型的产品关系表结构示例,包括字段名称、字段类型和字段含义:字段名称字段类型字段含义product_id INT产品唯一标识符product_nam e VARCHAR(255)产品名称category_id INT产品所属类别ID,外键关联分类表description TEXT产品描述price DECIMAL(10,2)产品价格stock_quantit y INT产品库存数量created_at DATETIME产品创建时间updated_at DATETIME产品更新时间在此结构中,我们使用了以下设计策略:使用整型product_id作为主键,确保每个产品都有唯一的标识符。

通过category_id字段与分类表建立关联,实现分类管理。

这有助于组织和管理不同类型的产品。

使用description字段存储产品描述,为产品提供详细的说明。

使用price字段存储产品价格,便于计算和统计。

使用整型stock_quantity字段记录库存数量,保证库存管理的准确性。

使用created_at和updated_at字段记录产品的创建时间和更新时间,便于追踪和管理。

四、约束设计为了确保数据完整性,我们需要在产品关系表中设置相应的约束条件:主键约束:确保每个产品都有唯一的product_id。

如何设计动态(不定)字段的产品数据库表?

如何设计动态(不定)字段的产品数据库表?

如何设计动态(不定)字段的产品数据库表?项⽬组会议上讨论的关于不定字段数⽬的数据库表问题并没有结果,今天继续分析之后发现问题可能还更⼤。

当时讨论的结果是可能采⽤四种技术:动态增加数据库表字段预留⾜够的空⽩字段,运⾏时作动态影射⽤xml格式保存在单字段⾥改列为⾏,⽤另外⼀个表存放定制字段【⼀】现在我们来分析⼀下四种技术的优劣,不过⾸先可以排除的是第⼀点动态增加字段的⽅法,因为在实际操作时候⼏乎是不可能的(sqlserver 太慢,oracle索性不⽀持),基本可以不讨论就排除。

剩下后三点。

【⼆】先来讨论预留空⽩字段的⽅法,基本原理就是在数据库表设计的时候加⼊⼀些多余的字段,看下⾯的代码:CREATE TABLE Sample(name varchar(12),field0 varchar(1),field1 varchar(1),fieldN varchar(1)}然后看实际运⾏时候的需要,动态分配字段给系统使⽤,也许需要⼀个这样的结构来描述分配情况:public class Available{public int CurrentUnusedFieldNumber;public Hashtable FieldToRealName;}也许某⼀时刻的数据状况是这样的: CurrentUnusedFieldNumber=3, 哈西表FieldToRealName包含内容是("field0"="SomeId","field1"="AnyName", "field2=IsOk")现在的问题是如果要配合Hibernate,如何来处理?以上段的数据使⽤状况为例⼦,如果我们的类定义是这样:public class Entity01{public string Name;public string SomeId;public string AnyName;public bool IsOk;}也许只需要修改⼀下xxx.hbm.xml,把 SomeId 和 field0 做成对应就ok了。

数据库系统设计案例

数据库系统设计案例

数据库系统设计案例数据库系统设计案例:电子商务平台随着互联网的飞速发展,电子商务平台成为了购物的主要方式之一。

为了满足用户的多样化需求和提供更好的购物体验,设计一个高效且可靠的电子商务平台数据库系统显得尤为重要。

在设计之前,我们首先需要明确数据库系统的目标和需求。

该电子商务平台需要支持用户信息管理、商品管理、订单管理、支付信息管理等功能,并且需要面向大量用户提供高并发访问。

在用户信息管理方面,我们可以设计一个用户表,包含用户ID、用户名、密码、手机号码等字段,用于管理用户的基本信息。

为了方便用户的浏览和搜索,可以额外设计一个收货地址表,保存用户的不同收货地址。

商品管理是电子商务平台的核心功能之一,所以我们需要设计一个商品表,包含商品ID、名称、价格、库存等字段。

此外,还可以设计一个商品分类表,用于分类不同的商品。

为了满足用户对商品的搜索需求,我们可以设计一个关键词表用于存储商品的关键词,在用户搜索时可以根据关键词进行匹配。

订单管理是电子商务平台的另一个重要功能,我们可以设计一个订单表,包含订单ID、用户ID、商品ID、数量、金额等字段。

此外,为了方便统计和报表生成,可以设计一个订单状态表,用于记录订单的不同状态。

支付信息管理是电子商务平台必不可少的一环,我们可以设计一个支付信息表,包含支付订单ID、支付渠道、支付状态等字段,用于记录用户的支付信息。

为了提高数据库系统的性能,我们可以针对不同的表设计适当的索引。

比如,在用户表中创建用户ID的唯一索引以加速用户信息的查找,对商品表中的商品名称创建索引以提高商品搜索效率等。

此外,为了确保数据的完整性和安全性,可以在设计中采用约束和权限控制。

比如,在用户表中设置用户名的唯一约束以防止重复注册,对订单表设置外键约束以保证订单与用户和商品的关联完整性。

综上所述,设计一个高效且可靠的电子商务平台数据库系统不仅需要考虑功能的全面性和性能的高效性,还需要重视数据的完整性和安全性。

产品分类数据库设计

产品分类数据库设计

产品分类数据库表设计文档北京联动北方科技有限公司2012年3月7日系统数据库设计(所作修改已用红色部分标出)一.系统ER图1-1分析实体集:公司、产品、组件、产品类别联系:生产:描述公司和产品之间的关系,是一种多对多的关系.一个公司可以生产多种产品,一个产品也可能有多个公司生产.组成:描述产品与组件之间的关系,是一种多对多的关系,一个产品由多个组件组成,一个组件也可能出现在多个产品中.兼容:描述各个公司产品之间的兼容性,是一种多对多的关系,一个产品可以与多个产品兼容.拥有:描述公司和产品类别之间的关系,是一种多对多的关系.一个公司可以拥有很多类别的产品,一个产品类别里面也可以包含很多公司的产品.包含:描述产品类别和产品之间的关系,是一对多的关系.一个产品类别里面可以包含多个产品,但一个产品只能属于一个产品类别.1-2处理1. 公司这个实体可以独立作为一个关系,建立一张表:公司(公司编号,名称,描述)2. 产品这个实体可以独立作为一个关系,建立一张表:(产品编号,名称,类别,版本,描述)3. 组件这个实体可以作为一个独立的关系,建立一张组件表:(组件编号,名称,描述)4. 生产联系转变成一个关系:生产表,记录不同公司生产的不同产品.生产表:生产(公司编号,产品编号)5. 组成联系转变成一个关系:组成表,记录产品和组件之间的关系.产品组成表:组成(组件编号,产品编号)6. 兼容联系转变成一个关系,是产品到产品的一个自身映射问题,记录产品与产品之间的兼容性信息.兼容表:兼容(产品1编号,产品2编号)7.产品类别这个实体可以独立作为一个关系,建立一张表:产品列表(编号,名称,描述)8.拥有联系转变成一个关系:拥有表,记录公司和产品类别之间的关系.拥有表:(公司编号,产品类别编号)9.包含联系转变成一个关系,是产品类别和产品之间的关系.建立一张表:包含表(产品类别编号,产品编号)二、数据表:1.公司表(company)2.产品表(product)PRIMARY KEY(prod_id))3.组件表(component)主要用来存放组件信息.4.生产表(production)prod_id varchar(10)not null,PRIMARY KEY(compa_id,prod_id),FOREIGN KEY(compa_id) REFERENCES company (compa_id),FOREIGN KEY(prod_id) REFERENCES product (prod_id)) 5.组成表(makeup)主要用来存放组件和产品之间的组成信息.compo_id varchar(10)not null,PRIMARY KEY(prod_id,compo_id),FOREIGN KEY(prod_id) REFERENCES product (prod_id), FOREIGN KEY(compo_id) REFERENCES component (compo_id))6.版本兼容表(compatibility)主要用来存储各种产品之间的兼容性信息.prod2_id varchar(10)not null,PRIMARY KEY(prod1_id,prod2_id),FOREIGN KEY(prod1_id) REFERENCES product (prod_id),FOREIGN KEY(prod2_id) REFERENCES product (prod_id))7.产品类别表(category)主要用来存储产品类别信息.Categ_name varchar(50) not null,Categ_desc varchar(2000),PRIMARY KEY(cate_id))8.拥有表(have)categ_id varchar(10),FOREIGN KEY(compa_id) REFERENCES company (compa_id),FOREIGN KEY(categ_id) REFERENCES company (categ_id),)9.包含表(contain)prod_id varchar(10),FOREIGN KEY(categ_id) REFERENCES category (categ_id),FOREIGN KEY (prod_id) REFERENCES product(prod_id))在对版本兼容表进行插入操作时,要防止两个产品的兼容信息重复存储,使用触发器来防止信息重复.CREATE OR REPLACE TRIGGER compatibility_check_trigbefore insert on compatibilityREFERENCING OLD as old_compare_id NEW as new_compare_idFOR EACH ROWBEGINIF :old_compare_id.prod1_id==:new_compare_id.prod2_id THEN IF :old_compare_id.prod2_id==:new_compare_id.prod1_id THEN UPDATE compatibilitySET prod1_id=:new_compare_id.prod1_id,prod2_id=:new_compare_id.prod2_idWHERE prod1_id=:old_compare_id.prod1_idAND prod2_id=:old_compare_id.prod2_id。

BOM的分类

BOM的分类

BOM的分类BOM的英文全称为BillofMaterial,中文翻译为BOM。

也称为"物料清单"或产品结构表、产品结构树,在某些工业领域,可能称为"配方"、"要素表"或其它名称。

BOM是计算机可以识别的产品结构数据文件,是联系与沟通企业各项业务的纽带,是PDM/ERP等信息化系统中最重要的基础数据,其组织格式设计和合理与否直接影响到系统的处理性能,因此,根据实际的使用环境,灵活地设计合理且有效的BOM是十分重要的。

一般产品要经过销售、工程设计、工艺制造设计、生产制造、成本核算、维护等多个阶段,相应的在这个过程中分别产生了名称十分相似但却内容差异很大的物料清单,如EBOM、PBOM、MBOM、CBOM等。

●EBOM(设计BOM)EBOM是产品在工程设计阶段的产品结构的BOM形式。

它主要反映产品的设计结构和物料项的设计属性。

设计结构区别于装配结构和制造结构,是工程设计人员按照客户定单合同中的产品功能要求,来确定产品需要哪些零部件,以及这些零部件之间的结构关系。

物料项的设计属性是产品功能要求的具体体现,如重量要求、寿命要求、外观要求等。

EBOM是设计部门向工艺、生产、采购等部门传递产品数据的主要形式和手段。

工艺部门依据EBOM进行工艺分工,编排零件的加工路线,进行零件的工艺设计。

因而EBOM虽然属于纯技术文件,不能用于生产计划,但它是工艺设计的直接数据源。

它包含物料项的图纸信息,即物料项的原始几何信息和结构关系。

以上文中的产品为例,该产品在某典型PDM系统中的信息如下:●PBOM(生产BOM)PBOM是产品工艺计划阶段的BOM,对于大型复杂机械产品尤其重要。

大型复杂机械产品零部件数据庞大,构型复杂,种类繁多,生产形式各种各样。

因此,建立产品的工艺计划对组织产品的生产极其重要。

同时,工艺计划的作用还在于确立产品的零部件装配顺序和装配结构。

PBOM就是反映产品装配结构和装配顺序的BOM形式。

数据库设计案例

数据库设计案例

数据库设计案例
数据库设计案例:
某电商网站要求设计一个数据库,用于存储商品信息和用户信息。

该网站有上百万种商品,每个商品包括商品ID、商品名称、商品描述、商品价格等信息。

每个用户可以注册并登录,每个用户包括用户名、密码、电话号码等信息。

为了提高查询性能,我们将商品信息和用户信息分别存储在两张表中。

商品信息表包括字段:商品ID、商品名称、商品描述、商品价格,其中商品ID为主键。

用户信息表包括字段:
用户名、密码、电话号码,其中用户名为主键。

此外,为了方便商品分类管理,我们可以增加一个商品分类表,包括字段:分类ID、分类名称。

商品信息表可以引入一个外
键字段,用于关联商品分类表的分类ID,实现分类与商品的
关联。

在设计数据库时,我们还要考虑到数据的一致性和完整性。

例如,为了防止用户注册时填写相同用户名,我们可以在用户信息表的用户名字段上添加唯一索引,保证用户名的唯一性。

最后,为了提高查询效率,我们可以为商品信息表的商品ID
字段和用户信息表的用户名字段创建索引,加快查询速度。

同时,我们还可以将该数据库部署在高性能的服务器上,采用分布式数据库架构,提高系统的可扩展性和容错性。

总之,通过合理的数据库设计,我们可以实现商品和用户信息的高效管理和查询操作,提供优质的电商服务。

产品表与分类表数据库设计

产品表与分类表数据库设计
archives/95/
问题的提出:网上商城对产品进行了很多分类,不同的分类产品又有不同的属性,比如,电脑的属性有:CUP,内存,主板,硬盘等等,服装的属性有:布料,尺寸,颜色等等,那么产品表以及产品分类表应该如何设计才能满足不同类型产品的区别呢?
解决方案:
1、产品分类表的设计
第一种设计思路:使用树形结构,递归的形式,可以对产品进行N级分类,只要你喜欢,树形结构在数据库的设计中经常用到,比如功能菜单表等。以下是一个简单的产品分类表。
说明:上级类别ID为该表的外键,并关联到本级类别ID,这样就可以对产进行N级分类了,这种设计思想十分灵活,是无限分类中最常用到的。 第二种设计思路:定义N个类别表,并对他们进行关联,如图:

电商数据库商品表的设计

电商数据库商品表的设计

电商数据库商品表的设计表模型商品有品牌⼂分类⼂属性⼂图⽚⼂规格等属性。

品牌⼂分类⼂属性可以重复使⽤,独⽴建⽴表进⾏存储。

商品可能有⼀张或多张图⽚,跟商品之间是⼀对多的关系。

商品有⼀⾄多个规格,商品和规格是⼀对多的关系。

SQL1)、商品表CREATE TABLE `cy_goods` (`id` int(10) unsigned NOT NULL AUTO_INCREMENT,`goods_name` varchar(100) COLLATE utf8mb4_unicode_ci NOT NULL COMMENT '商品名称',`brand_id` int(10) unsigned NOT NULL COMMENT '品牌ID',`cate_id` int(10) unsigned NOT NULL COMMENT '分类ID',`price` bigint(20) unsigned NOT NULL,`original` bigint(20) unsigned NOT NULL COMMENT '商品原价',`tags` varchar(255) COLLATE utf8mb4_unicode_ci NOT NULL COMMENT '商品标签',`content` text COLLATE utf8mb4_unicode_ci NOT NULL COMMENT '商品内容',`summary` text COLLATE utf8mb4_unicode_ci NOT NULL COMMENT '商品描述',`is_sale` tinyint(4) NOT NULL COMMENT '上架状态: 1是0是',`created_at` timestamp NULL DEFAULT NULL,`updated_at` timestamp NULL DEFAULT NULL,PRIMARY KEY (`id`),KEY `goods_brand_id_foreign` (`brand_id`),KEY `goods_cate_id_foreign` (`cate_id`),CONSTRAINT `goods_brand_id_foreign` FOREIGN KEY (`brand_id`) REFERENCES `cy_brand` (`id`) ON DELETE CASCADE ON UPDATE CASCADE, CONSTRAINT `goods_cate_id_foreign` FOREIGN KEY (`cate_id`) REFERENCES `cy_categories` (`id`) ON DELETE CASCADE ON UPDATE CASCADE) ENGINE=InnoDB AUTO_INCREMENT=18DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci2)、分类表CREATE TABLE `cy_categories` (`id` int(10) unsigned NOT NULL AUTO_INCREMENT,`pid` int(10) unsigned NOT NULL DEFAULT'0' COMMENT '⽗级分类ID,0为顶级分类',`cate_name` varchar(50) COLLATE utf8mb4_unicode_ci NOT NULL COMMENT '分类名称',`sort` smallint(5) unsigned NOT NULL DEFAULT'99' COMMENT '排序字段',`created_at` timestamp NULL DEFAULT NULL,`updated_at` timestamp NULL DEFAULT NULL,PRIMARY KEY (`id`),UNIQUE KEY `categories_cate_name_unique` (`cate_name`)) ENGINE=InnoDB AUTO_INCREMENT=33DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci3)、品牌表CREATE TABLE `cy_brand` (`id` int(10) unsigned NOT NULL AUTO_INCREMENT,`brand_name` varchar(50) COLLATE utf8mb4_unicode_ci NOT NULL,`desc` varchar(100) COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT'' COMMENT '品牌描述',`sort` int(10) unsigned NOT NULL DEFAULT'99' COMMENT '排序字段',`created_at` timestamp NULL DEFAULT NULL,`updated_at` timestamp NULL DEFAULT NULL,PRIMARY KEY (`id`)) ENGINE=InnoDB AUTO_INCREMENT=2DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci4)、商品图⽚表CREATE TABLE `cy_goods_images` (`id` int(10) unsigned NOT NULL AUTO_INCREMENT,`goods_id` int(10) unsigned NOT NULL COMMENT '商品ID',`link` varchar(250) COLLATE utf8mb4_unicode_ci NOT NULL COMMENT '图⽚URL地址',`position` smallint(5) unsigned NOT NULL COMMENT '图⽚位置',`is_master` tinyint(4) NOT NULL DEFAULT'0' COMMENT '是否主图: 1是,0否',`created_at` timestamp NULL DEFAULT NULL,`updated_at` timestamp NULL DEFAULT NULL,PRIMARY KEY (`id`),KEY `goods_images_goods_id_foreign` (`goods_id`),CONSTRAINT `goods_images_goods_id_foreign` FOREIGN KEY (`goods_id`) REFERENCES `cy_goods` (`id`) ON DELETE CASCADE ON UPDATE CASCADE ) ENGINE=InnoDB AUTO_INCREMENT=13DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci5)、商品SKU表CREATE TABLE `cy_goods_sku` (`id` int(10) unsigned NOT NULL AUTO_INCREMENT,`goods_id` int(10) unsigned NOT NULL COMMENT '商品ID',`title` varchar(100) COLLATE utf8mb4_unicode_ci NOT NULL COMMENT '规格名称',`num` int(10) unsigned NOT NULL COMMENT 'SKU库存',`price` bigint(20) unsigned NOT NULL COMMENT '商品售价',`properties` varchar(255) COLLATE utf8mb4_unicode_ci DEFAULT NULL COMMENT '商品属性表ID,以逗号分隔',`bar_code` varchar(50) COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT'' COMMENT '条码',`goods_code` varchar(100) COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT'' COMMENT '商品码',`status` tinyint(4) NOT NULL DEFAULT'1' COMMENT '状态:1启⽤,0禁⽤',`created_at` timestamp NULL DEFAULT NULL,`updated_at` timestamp NULL DEFAULT NULL,PRIMARY KEY (`id`),KEY `goods_sku_goods_id_foreign` (`goods_id`),CONSTRAINT `goods_sku_goods_id_foreign` FOREIGN KEY (`goods_id`) REFERENCES `cy_goods` (`id`) ON DELETE CASCADE ON UPDATE CASCADE) ENGINE=InnoDB AUTO_INCREMENT=6DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci6)、属性名表CREATE TABLE `cy_property_name` (`id` int(10) unsigned NOT NULL AUTO_INCREMENT,`title` varchar(100) COLLATE utf8mb4_unicode_ci NOT NULL COMMENT '属性名',`cate_id` int(10) unsigned NOT NULL COMMENT '分类ID',`is_allow_alias` tinyint(4) NOT NULL DEFAULT'0' COMMENT '是否允许别名: 1是0否',`is_color` tinyint(4) NOT NULL DEFAULT'0' COMMENT '是否颜⾊属性: 1是0否',`is_enum` tinyint(4) NOT NULL DEFAULT'0' COMMENT '是否枚举: 1是0否',`is_input` tinyint(4) NOT NULL DEFAULT'0' COMMENT '是否输⼊属性: 1是0否',`is_key` tinyint(4) NOT NULL DEFAULT'0' COMMENT '是否关键属性: 1是0否',`is_sale` tinyint(4) NOT NULL DEFAULT'0' COMMENT '是否销售属性:1是0否',`is_search` tinyint(4) NOT NULL DEFAULT'0' COMMENT '是否搜索字段: 1是0否',`is_must` tinyint(4) NOT NULL DEFAULT'0' COMMENT '是否必须属性: 1是0否',`is_multi` tinyint(4) NOT NULL DEFAULT'0' COMMENT '是否多选: 1是0否',`status` tinyint(4) NOT NULL DEFAULT'1' COMMENT '状态: 1启⽤,0禁⽤',`sort` int(10) unsigned NOT NULL DEFAULT'99' COMMENT '排序字段',`created_at` timestamp NULL DEFAULT NULL,`updated_at` timestamp NULL DEFAULT NULL,PRIMARY KEY (`id`),KEY `property_name_cate_id_foreign` (`cate_id`),CONSTRAINT `property_name_cate_id_foreign` FOREIGN KEY (`cate_id`) REFERENCES `cy_categories` (`id`) ON DELETE CASCADE ON UPDATE CASCADE) ENGINE=InnoDB AUTO_INCREMENT=2DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci7)、属性值表CREATE TABLE `cy_property_name` (`id` int(10) unsigned NOT NULL AUTO_INCREMENT,`title` varchar(100) COLLATE utf8mb4_unicode_ci NOT NULL COMMENT '属性名',`cate_id` int(10) unsigned NOT NULL COMMENT '分类ID',`is_allow_alias` tinyint(4) NOT NULL DEFAULT'0' COMMENT '是否允许别名: 1是0否',`is_color` tinyint(4) NOT NULL DEFAULT'0' COMMENT '是否颜⾊属性: 1是0否',`is_enum` tinyint(4) NOT NULL DEFAULT'0' COMMENT '是否枚举: 1是0否',`is_input` tinyint(4) NOT NULL DEFAULT'0' COMMENT '是否输⼊属性: 1是0否',`is_key` tinyint(4) NOT NULL DEFAULT'0' COMMENT '是否关键属性: 1是0否',`is_sale` tinyint(4) NOT NULL DEFAULT'0' COMMENT '是否销售属性:1是0否',`is_search` tinyint(4) NOT NULL DEFAULT'0' COMMENT '是否搜索字段: 1是0否',`is_must` tinyint(4) NOT NULL DEFAULT'0' COMMENT '是否必须属性: 1是0否',`is_multi` tinyint(4) NOT NULL DEFAULT'0' COMMENT '是否多选: 1是0否',`status` tinyint(4) NOT NULL DEFAULT'1' COMMENT '状态: 1启⽤,0禁⽤',`sort` int(10) unsigned NOT NULL DEFAULT'99' COMMENT '排序字段',`created_at` timestamp NULL DEFAULT NULL,`updated_at` timestamp NULL DEFAULT NULL,PRIMARY KEY (`id`),KEY `property_name_cate_id_foreign` (`cate_id`),CONSTRAINT `property_name_cate_id_foreign` FOREIGN KEY (`cate_id`) REFERENCES `cy_categories` (`id`) ON DELETE CASCADE ON UPDATE CASCADE) ENGINE=InnoDB AUTO_INCREMENT=2DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci8)、商品属性表CREATE TABLE `cy_goods_property` (`id` int(10) unsigned NOT NULL AUTO_INCREMENT,`goods_id` int(10) unsigned NOT NULL COMMENT '商品ID',`prop_name_id` int(10) unsigned NOT NULL COMMENT '属性名ID',`prop_value_id` int(10) unsigned NOT NULL COMMENT '属性值ID',`created_at` timestamp NULL DEFAULT NULL,`updated_at` timestamp NULL DEFAULT NULL,PRIMARY KEY (`id`),KEY `goods_property_prop_name_id_foreign` (`prop_name_id`),KEY `goods_property_prop_value_id_foreign` (`prop_value_id`),KEY `goods_property_goods_id_foreign` (`goods_id`),CONSTRAINT `goods_property_goods_id_foreign` FOREIGN KEY (`goods_id`) REFERENCES `cy_goods` (`id`) ON DELETE CASCADE ON UPDATE CASCADE, CONSTRAINT `goods_property_prop_name_id_foreign` FOREIGN KEY (`prop_name_id`) REFERENCES `cy_property_name` (`id`) ON DELETE CASCADE ON UPDATE CASCADE, CONSTRAINT `goods_property_prop_value_id_foreign` FOREIGN KEY (`prop_value_id`) REFERENCES `cy_property_value` (`id`) ON DELETE CASCADE ON UPDATE CASCADE ) ENGINE=InnoDB AUTO_INCREMENT=3DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci。

京东数据库设计

京东数据库设计
全部商品分类表
分类编号
分类名称
子分类编号
商品子分类表 子分类名称
分类名称
筛选分类编号
商品筛选分类表 筛选分类编号
子分类名称
品牌编号
品牌分类表 品牌名称
子分类名称
商品编号
商品表 商品名称
商品品牌
商品详细信息表 商品详细信息编号 商品名称
商品价格编号
商品价格表 商品价格
商品名称
商品状态编号
商品状态表 商品状态情况
商品名称
配送地号
商品配送地表 配送地名称
商品名称
参数编号
商品参数表 参数信息
商品名称
清单编号
包装清单表 清单信息
商品名称
评价编号
商品评价表 评价信息
商品名称
售后编号
商品售后表 售后服务信息
商品名称
用户编号
用户表
用户信息编号
个人信息表
级别编号
用户级别表
余额编号
用户余额表
全部订单表 订单编号
商品关注表 关注编号
收货时间表 收货时间
物流表 物流名称
物流价格表 物流价格
支付类别表 类别名称
用户账号
管理员编号 编号
管理员表 账号
管理员级别表 级别名称
理员表 员级别表
密码 管理员账号
客户服务表
编号
客户服务名称
编号
客户服务类别表 类别名称
客户服务名称
收货地址表 编号
收货时间表 编号
物流表 物流编号
物流价格表 价格编号
支付类别表 编号
推荐商品表
推荐商品编号
商品名称
购物车编号
购物车表 商品名称

商城管理系统中商品管理模块的设计与实现

商城管理系统中商品管理模块的设计与实现

商城管理系统中商品管理模块的设计与实现商城管理系统中的商品管理模块是整个系统的核心功能之一,它涉及到商品的添加、编辑、删除、上下架等各种操作。

本文将从数据库设计、后台逻辑设计和前端界面设计三个方面来详细介绍商品管理模块的设计与实现。

一、数据库设计1. 商品表:包含商品的基本信息,如商品ID、名称、价格、库存、描述等字段。

2. 分类表:用于分类商品,包含分类ID和分类名称字段。

3. 品牌表:用于管理商品品牌,包含品牌ID和品牌名称字段。

4. 图片表:用于保存商品的图片,包含图片ID、商品ID和图片URL字段。

二、后台逻辑设计1. 商品的添加:后台管理员可以通过添加商品功能来向系统中添加新的商品。

在添加商品时,管理员需要填写商品的基本信息和选择所属的分类、品牌,还可以上传商品图片。

后台逻辑应该对添加的商品信息进行校验,确保数据的合法性。

2. 商品的编辑和删除:后台管理员可以对已存在的商品进行编辑和删除操作。

编辑商品时,管理员可以修改商品的基本信息、分类、品牌信息和商品图片,同样需要进行数据校验。

删除商品时,系统应该提示管理员确认删除操作,同时关联的图片也需要删除。

3. 商品的上下架:商城管理系统需要提供商品的上下架功能,管理员可以手动将商品上架或下架。

上架的商品将在前端页面显示,供用户浏览和购买,下架的商品则不再展示。

4. 商品的搜索和筛选:商城管理系统应该提供商品的搜索和筛选功能,方便用户找到所需的商品。

搜索功能可以根据商品的名称、分类、品牌等信息来进行模糊搜索,筛选功能可以根据价格、销量、库存等条件来进行商品筛选。

三、前端界面设计1. 商品列表页面:展示所有商品的列表页面,包含商品的基本信息和图片预览,用户可以点击商品列表中的商品进入商品详情页面。

2. 商品详情页面:展示商品的详细信息,包括名称、价格、库存、描述等,并显示商品图片。

在商品详情页面,用户可以选择商品数量、加入购物车或直接购买商品。

数据库系统设计实验报告-自己做的超完整

数据库系统设计实验报告-自己做的超完整

《数据库管理与开发》实验报告课程号:B0900990-0实验项目:数据库设计、创建,表及各种对象的创建、管理与应用(2)、全部选中之后然后点击“执行”,就会执行相应的语句,并在命令窗口显示“命令已经成功完成”。

如下图所示:(3)、然后刷新左边的数据库,就会出现我们所建立的OnlineShopping数据库。

(4)、然后找到E盘的OnlineShopping文件夹,点击进入之后就会看到包含我们所建立的数据文件和事务日志文件。

说明创建数据库成功。

2.在数据库中建表。

(1)、创建“客户表”。

(2)、创建“商品表”。

(3)、创建“生产厂商表”。

(4)、创建“商品类别表”。

(5)、创建“订单总表”。

(6)、创建“订单明细表”。

(7)、创建“供应表”。

注意这个表有点特殊的是:由两个属性共同的作为主键,要用CONSTRAIT 主键名PRIMARY KEY(属性A,属性B)(8)、创建“评论表”。

(9)、表全部创建完成之后,刷新数据库,可以看到这些表。

3、在数据库中创建索引。

说明:索引包含“唯一性索引”,“主键索引”,“聚集索引”。

因为生成的表的时候系统自动的为每一个表设置了“主键索引”如图所示,“聚集索引”是指表中的各记录的物理顺序与键值的逻辑顺序一致。

一张表中只能有一个“聚集索引”。

而系统中的这个主键索引也是聚集索引,所以不能再对表格创建聚集索引。

所以我下面创建的是唯一性索引,全部都是非聚集索引。

(1)、在“客户表”中创建了一个按“身份证号”列建立的唯一索引“Customer”。

说明:这里创建的是唯一索引,唯一索引的含义是对于表中的任何两行记录来说,索引键的值都各不相同。

并且要注意,如果表中一个字段或者多个字段的组合在多行记录中具有NULL值,则不能将这个字段或者字段组合作为唯一索引键。

因为对于每一个表的主键系统都自动的设置了相应的索引,在“客户表”中,身份证号是绝对不能相同的,所以可以设置为唯一索引键。

(2)、在“商品表”中创建了一个按“单价”列建立的非聚集索引“Goods”。

数据库设计教案

数据库设计教案

数据库课程设计教案一、课程设计目的数据库系统课程设计是计算机科学与技术专业集中实践性环节之一,是学习完《数据库系统概论》课程后进行的一次全面的综合练习。

其目的在于加深对数据库基础理论和基本知识的理解,掌握使用数据库进行软件设计的基本方法,提高运用数据库解决实际问题的能力,最终实现对于给定的应用环境,构造最优的数据库模式,建立数据库及其应用系统,使之能够有效地存储数据,满足各种用户的应用需求。

1)熟悉数据库系统的开发流程;2)培养学生实际规划开发项目的能力;3)培养学生的团队协作精神。

二、课程设计要求运用某个数据库管理系统及开发工具制作一个小型管理信息系统。

所设计的管理系统应包含输入输出、查询统计、插入、删除、报表及数据备份等基本功能。

题目的选择可以是实际问题,也可以是虚构的问题。

根据所学的软件软件工程和数据库设计理论、方法,写出详细的设计说明书。

三、课程设计的组织形式数据库系统课程设计分小组进行,每组学生人数一般3-5人。

分组按成绩好差、能力强弱搭配的原则,每个小组由1名组长负责安排和协调组员的任务。

四、课程设计开发环境数据库设计环境及程序设计语言可以自选。

五、课程设计参考教材《数据库系统概论》萨师煊王珊编著,高等教育版社,2000.2《软件工程—理论、方法与实践》刘强编著,高等教育版社,2005.7六、课程设计时间课程设计时间为18周,每周2节课,学分1分,第18周提交设计文档及源代码。

七、课程设计考核方式学生所完成的数据库管理系统的设计文档和程序设计结果,以此作为考核依据。

八、附录1、附录1 设计文档参考格式2、附录2 设计参考题目1、附录1 设计文档参考格式1) 封面数据库系统课程设计人事薪资管理系统的设计班级____________________________________________学号____________________________________________姓名____________________________________________成绩____________________________________________完成日期:年月日2) 文档格式(1)、概述包括项目背景、编写目的、软件定义、开发环境等内容。

数据库命名设计规范

数据库命名设计规范

一、数据库表及字段1.数据库表的命名规范:表的前缀应该用系统或者模块的英文名的缩写(全部大写)。

如果系统功能简单,没有划分为模块,则可以以系统英文名称的缩写作为前缀,否则以各模块的英文名称缩写作为前缀。

例如:如果有一个模块叫做 BBS(缩写为 BBS),那末你的数据库中的所有对象的名称都要加之这个前缀: BBS_ + 数据库对象名称, BBS_CustomerInfo 标示论坛模块中的客户信息表。

表的名称必须是易于理解,能表达表的功能的英文单词或者缩写英文单词,无论是完整英文单词还是缩写英文单词,单词首字母必须大写。

如果当前表可用一个英文单词表示的,请用完整的英文单词来表示;例如:系统资料中的客户表的表名可命名为:SYS_Customer。

如果当前表需用两个或者两个以上的单词来表示时,尽量以完整形式书写,如太长可采用两个英文单词的缩写形式;例如:系统资料中的客户物料表可命名为:SYS_CustItem。

表名称不应该取得太长(普通不超过三个英文单词)。

表名长度不能超过 30 个字符,表名中含有单词全部采用单数形式,单词首字母必须大写。

在命名表时,用单数形式表示名称。

例如,使用 Employee,而不是 Employees。

对于有主明细的表来说。

明细表的名称为:主表的名称 + 字符 Dts。

例如:采购定单的名称为: PO_Order,则采购定单的明细表为:PO_OrderDts;对于有主明细的表来说,明细表必须包含两个字段:主表关键字、 SN,SN 字段的类型为 int 型,目的为与主表关键字联合组成明细表的关键字,以及标示明细记录的先后顺序,如1,2,3……。

表必须填写描述信息,后台表名尽量与前台表名相同,后台独有的表应以_b 作为后缀。

如 r_gggd_b。

数据库表的命名采用如下规则:1)表名用模块名_开头,表名长度不能超过 30 个字符,表名中含有单词全部采用单数形式,单词首字母必须大写。

2)多个单词间用下划线(_)进行连接。

供应商数据库的基本构成

供应商数据库的基本构成

供应商数据库的基本构成1. 引言供应商数据库是一个重要的资源,用于管理和维护与供应商相关的信息。

本文档旨在介绍供应商数据库的基本构成,以帮助用户更好地理解和利用该数据库。

2. 信息分类供应商数据库可以根据不同的信息类型进行分类,以方便用户对供应商信息进行管理和检索。

常见的信息分类包括但不限于以下几个方面:2.1 供应商基本信息这部分信息包括供应商的名称、地址、联系人、联系方式等基本信息。

通过这些信息,用户可以快速了解供应商的基本情况,方便与供应商进行沟通和合作。

2.2 供应商产品信息供应商产品信息是指供应商提供的产品或服务的详细信息。

这些信息可以包括产品型号、规格、价格、质量认证等内容。

用户可以通过这些信息,对供应商的产品进行评估和选择。

2.3 供应商合作历史供应商合作历史记录了与供应商之间的合作情况,包括合同签订日期、合同期限、交付情况等。

这些记录有助于用户了解与供应商合作的时间和质量,以便进行相应的改进和决策。

3. 数据库设计供应商数据库的设计需要考虑数据的结构和存储方式。

以下是供应商数据库设计的几个重要方面:3.1 数据表结构通过设计合适的数据表结构,可以对供应商信息进行规范化和层次化管理。

常见的数据表包括供应商表、产品表、合作历史表等。

每个数据表应包含必要的字段,以便对信息进行有效的存储和检索。

3.2 数据库关系不同的数据表之间可能存在关联关系,如供应商与产品的关系、供应商与合作历史的关系等。

通过定义适当的关系,可以实现数据的一致性和完整性。

3.3 数据安全供应商信息是企业重要的资产之一,因此数据库设计应考虑数据的安全性。

合理的访问控制和加密技术可以保护供应商信息不被未经授权的访问和使用。

4. 数据维护与更新供应商数据库需要进行定期的数据维护和更新,以确保信息的准确性和及时性。

用户应制定相关的数据维护计划,包括数据清洗、数据备份等措施。

5. 结论供应商数据库的基本构成包括信息分类、数据库设计和数据维护与更新。

掌握SKU和SPU关系及表设计(三)

掌握SKU和SPU关系及表设计(三)

掌握SKU和SPU关系及表设计(三)⼀、掌握SKU和SPU关系电商系统中涉及到商品时必然会遇到的⼏个概念,SPU、SKU、单品等。

彻底搞懂和明⽩了这⼏个概念对设计商品表是⼗分必要的前提条件。

1.1、SPU:标准化产品单元SPU = Standard Product Unit (标准化产品单元),SPU是商品信息聚合的最⼩单位,是⼀组可复⽤、易检索的标准化信息的集合,该集合描述了⼀个产品的特性。

1.2、SKU:库存量单位SKU=stock keeping unit(库存量单位) SKU即库存进出计量的单位(买家购买、商家进货、供应商备货、⼯⼚⽣产都是依据SKU进⾏的)。

SKU是物理上不可分割的最⼩存货单元。

也就是说⼀款商品,可以根据SKU来确定具体的货物存量。

如⼀件M码(四个尺码:S码、M码、L码、X码)的粉⾊(三种颜⾊:粉⾊、黄⾊、⿊⾊)Zara⼥⼠风⾐,其中M码、粉⾊就是⼀组SKU的组合。

SKU在⽣成时, 会根据属性⽣成相应的笛卡尔积,根据⼀组SKU可以确定商品的库存情况,那么上⾯的Zara⼥⼠风⾐⼀共有4 * 3 = 12个SKU组合。

M码+粉⾊这两个属性组合被称为⼀组SKU、因为SKU是物理上不可分割的最⼩存货单元,单凭尺⼨或者颜⾊是没有办法确认这款商品的库存情况。

同理商家进货补货也是通过SKU来完成的,试问淘宝店家跟供货商说我要100件红⾊⼥⼠风⾐?供应商知道该怎么给他备货吗?显然是不知道的。

因为还⽋缺了另外的⼀个销售属性【尺码】。

1.3、spu和sku都是属性值的集合SPU 属性(不会影响到库存和价格的属性, ⼜叫关键属性)Oppo R17这是商品的SPU,但Oppo R17只是⼀个名词,单纯的理解这个名词是没有意义的。

Oppo R17是这个商品的SPU,这⾥的SPU是⼀组商品的属性组合。

如下所⽰【硬件参数】:CPU 型号:⾼通骁龙™ 670CPU 频率:2.0GHz核⼼数:⼋核处理器位数:64 位GPU 型号:Adreno™ 615电池容量:3500mAh(典型值)*【尺⼨】:长:约 157.5mm宽:约 74.9mm厚:约 7.5mm重:约 182g以及包括【摄像头】、【显⽰屏】、【操作系统】等等这些属性构成了⼀个SPU、这个SPU属性组合的名称叫做Oppo R17。

数据库建设技术方案

数据库建设技术方案

数据库建设技术方案随着信息时代的到来,数据库已经成为企业、政府、教育机构等各类组织不可或缺的信息管理工具。

本文将探讨数据库建设的技术方案,包括数据库设计、数据模型设计、数据库系统选择、数据存储与备份、安全性与隐私保护等方面。

一、数据库设计数据库设计是数据库建设技术方案的核心,它决定了数据库的存储结构、查询效率、数据完整性等方面。

良好的数据库设计应该能够满足组织的业务需求,提高数据查询效率,同时保证数据的一致性和完整性。

1、确定数据需求:在设计数据库之前,需要明确组织的业务需求和数据需求,包括数据的种类、格式、来源、用途等。

2、设计数据模型:根据组织的业务需求和数据需求,设计合适的数据模型。

数据模型应该能够清晰地表达组织的数据结构,同时能够支持高效的数据查询和更新操作。

3、确定表关系:在设计数据模型时,需要确定表之间的关系,包括父子关系、关联关系等。

表关系应该能够保证数据的完整性和一致性。

4、确定字段类型:在设计数据模型时,需要确定每个字段的类型,包括文本、数字、日期等。

字段类型应该能够满足数据的存储和查询需求。

二、数据模型设计数据模型是数据库设计的核心,它描述了组织的数据结构及其之间的关系。

在设计数据模型时,需要考虑以下几个方面:1、数据的一致性:保证数据在不同表之间的一致性,避免数据不一致的情况。

2、数据的完整性:保证数据的完整性,避免数据丢失或损坏。

3、查询效率:优化数据模型,提高查询效率。

4、扩展性:考虑未来的业务扩展需求,使数据模型具有一定的扩展性。

三、数据库系统选择数据库系统是数据库建设技术方案的另一个重要方面。

选择合适的数据库系统需要考虑以下几个方面:1、性能:根据组织的业务需求和数据量,选择性能合适的数据库系统。

2、可靠性:选择可靠性高的数据库系统,保证数据的稳定性和安全性。

3、易用性:选择易用的数据库系统,方便管理员和开发人员进行管理和开发。

4、兼容性:选择与组织现有系统兼容的数据库系统,方便集成和升级。

u8数据库常见表及分类说明

u8数据库常见表及分类说明

u8数据库常见表及分类说明一、引言在现代信息化的时代,数据库是企业信息系统中不可或缺的重要组成部分。

数据库的设计和使用对于企业的运营和管理具有重要的影响。

u8数据库作为一种常见的数据库系统,具有广泛的应用范围。

本文将介绍u8数据库中常见的表及其分类。

二、常见的表及分类说明1. 用户表用户表是u8数据库中非常重要的一类表,用于存储企业系统中的用户信息。

用户表通常包括用户ID、用户名、密码、权限等字段。

根据权限的不同,可以将用户表分为管理员表和普通用户表。

2. 组织机构表组织机构表用于存储企业中的组织结构信息。

它包括部门名称、上级部门、部门负责人等字段。

通过组织机构表,可以方便地管理企业内部的组织结构,并进行相关的权限控制。

3. 客户表客户表用于存储企业的客户信息。

它包括客户ID、客户名称、联系人、联系方式等字段。

通过客户表,可以管理和维护企业的客户信息,方便进行销售和客户关系管理。

4. 供应商表供应商表用于存储企业的供应商信息。

它包括供应商ID、供应商名称、联系人、联系方式等字段。

通过供应商表,可以管理和维护企业的供应商信息,方便进行采购和供应商关系管理。

5. 产品表产品表用于存储企业的产品信息。

它包括产品ID、产品名称、产品描述、产品价格等字段。

通过产品表,可以管理和维护企业的产品信息,方便进行销售和库存管理。

6. 订单表订单表用于存储企业的订单信息。

它包括订单ID、客户ID、产品ID、订单数量、订单金额等字段。

通过订单表,可以管理和维护企业的订单信息,方便进行销售和订单处理。

7. 仓库表仓库表用于存储企业的仓库信息。

它包括仓库ID、仓库名称、仓库地址等字段。

通过仓库表,可以管理和维护企业的仓库信息,方便进行库存管理和物流配送。

8. 日志表日志表用于记录系统的操作日志。

它包括日志ID、操作人、操作时间、操作内容等字段。

通过日志表,可以记录系统的操作历史,方便进行系统的审计和故障排查。

9. 系统配置表系统配置表用于存储系统的配置信息。

数据库设计项目案例

数据库设计项目案例

数据库设计项目案例假设我们要设计一个在线书店的数据库。

首先需要考虑的是需要存储什么数据。

书店的主要业务是售卖图书,因此需要存储书籍的相关信息,比如书名、作者、出版社、出版日期、ISBN号、价格等。

同时,为了能够方便地分类浏览书籍,还需要存储书籍的分类信息,比如小说、历史、科技、儿童等。

此外,为了方便用户浏览和购买,还需要存储每本书的详细描述以及封面图片。

接下来考虑用户信息的存储。

用户需要注册账号才能购买图书,因此需要存储用户的账号信息,包括用户名、密码、邮箱等。

为了方便用户管理和记录购买历史,还需要存储用户的个人信息,比如姓名、地址、电话号码等。

为了支持在线支付,还需要存储支付信息,比如支付状态、支付金额、支付时间等。

数据库表设计如下:书籍表(book)字段名称数据类型说明book_id INT 唯一标识书籍的IDtitle VARCHAR(50) 书名author VARCHAR(50) 作者publisher VARCHAR(50) 出版社pubdate DATE 出版日期isbn VARCHAR(13) ISBN号price DECIMAL(10,2) 价格description TEXT 详细描述category_id INT 书籍分类IDimage_url VARCHAR(255) 封面图片URL书籍分类表(category)字段名称数据类型说明category_id INT 唯一标识书籍分类的ID category_name VARCHAR(20) 书籍分类名称用户表(user)字段名称数据类型说明user_id INT 唯一标识用户的IDusername VARCHAR(50) 用户名password VARCHAR(50) 密码email VARCHAR(50) 邮箱fullname VARCHAR(50) 姓名address VARCHAR(100) 地址phone VARCHAR(20) 电话号码订单表(order)字段名称数据类型说明order_id INT 唯一标识订单的IDuser_id INT 下订单的用户的IDorder_date D ATETIME 订单日期amount DECIMAL(10,2) 订单总金额status VARCHAR(20) 订单状态,如已支付、未支付等订单详情表(order_detail)字段名称数据类型说明order_id INT 关联订单表的订单IDbook_id INT 关联书籍表的书籍IDquantity INT 购买数量price DECIMAL(10,2) 单价amount DECIMAL(10,2) 小计金额支付表(payment)字段名称数据类型说明payment_id INT 唯一标识支付的IDorder_id INT 关联订单表的订单IDuser_id INT 支付用户的IDstatus VARCHAR(20) 支付状态,如已支付、未支付等amount DECIMAL(10,2) 支付金额payment_date DATETIME 支付时间。

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

原文地址:/index.php/archives/95/
问题的提出:网上商城对产品进行了很多分类,不同的分类产品又有不同的属性,比如,电脑的属性有:CUP,内存,主板,硬盘等等,服装的属性有:布料,尺寸,颜色等等,那么产品表以及产品分类表应该如何设计才能满足不同类型产品的区别呢?
解决方案:
1、产品分类表的设计
第一种设计思路:使用树形结构,递归的形式,可以对产品进行N级分类,只要你喜欢,树形结构在数据库的设计中经常用到,比如功能菜单表等。

以下是一个简单的产品分类表。

说明:上级类别ID为该表的外键,并关联到本级类别ID,这样就可以对产进行N级分类了,这种设计思想十分灵活,是无限分类中最常用到的。

第二种设计思路:定义N个类别表,并对他们进行关联,如图:
说明:这种设计在项目中没有人会使用它,因为产品的分类是不固定的,很难在数据库设计的时候确定类别表的个数,很不灵活。

不过省分城市分类有用这样子的设计
2、产品表的设计
第一种设计思路:直接在产品表预留N个字段,用到的时候直接插入数据,如图
可行性:会产生很多字段的冗余,并且不知道到底需要多少个字段,数据类型也不能确定,可行性比较低,但是这种设计也有它的优点,就是表的数量少,其他的优点我实在找不出来了,所以,在项目中这种设计思想也不会用到。

第二种设计思路:在提及这种设计思路前,首先得了解数据表可以分为两种结构,一种是横表,也就是我们经常用到的表结构,另外一种是纵表,这种结构平时我们用到的表少,所以我也是今天通过请教别人才知有这种表结构的。

什么是纵表,它有哪些优点和缺点呢?通过两张图片对比来了解或许会更清楚
横表的结构:
纵表的结构:
可以看出横表的优点是很直观,它是根据现行业务逻辑定制,设计简单,易操作,缺点是当业务逻辑发生拓展时,大多情况下要更改表的结构。

纵表的数据让人看着感觉很乱,而且字段的数据出现很大的冗余,但是纵表的还是有很多好处的,它比较灵活,当业务系统发生拓展时可以很好的适应,知道了这些,那么我们可以进行产品表的设计了,在这种设计思想中,需要三个表,一个为产品表,用来存产品的公共属性,另外一个是产品分类表,最后一个表很关键,用来存不同类别产品的不同属性,采用的是纵表的结构,如图:
说明:通过产品拓展属性表,用户在页面就可以动态的某一类产品添加属性,添加好以后,就采用动态SQL提取该类商品的属性生成相应的产品类别属性横表,用来保存产品的属性值,比如:用户在界面为电脑类ID为COMP这一类产品中添加了CUP、内存EMS这两个属性,那么将会动态的提取这两个属性,生成横表
T_COMP,如图:
具体怎么实现,有了设计思路,剩下的就是很死的东西了,或许这种设计不是最好的,但是这个资料是很不错了啊。

相关文档
最新文档