精华内容
下载资源
问答
  • 中小型商城系统中的分类/产品属性/扩展属性的数据库设计  正文:  之前发表过一篇"商城系统中【商品扩展属性】的表单生成及客户端验证",部分童鞋对于后台数据库的设计比较感兴趣,于是今天把这部分也补上...

    中小型商城系统中的分类/产品属性/扩展属性的数据库设计

          正文:

          之前发表过一篇"商城系统中【商品扩展属性】的表单生成及客户端验证",部分童鞋对于后台数据库的设计比较感兴趣,于是今天把这部分也补上。

          一、产品分类设计
          越来越多的商城系统都热衷于选择“无限级分类”的设计,我也不例外,因为它方便扩展。这部分就不详细展开了,详见

          无限级分类(非递归算法/存储过程版/GUID主键)完整数据库示例_(1)表结构 
          无限级分类(非递归算法/存储过程版/GUID主键)完整数据库示例_(2)插入记录

          无限级分类(非递归算法/存储过程版/GUID主键)完整数据库示例_(3)删除记录

          无限级分类(非递归算法/存储过程版/GUID主键)完整数据库示例_(4)显示记录

          稍微啰唆几句:
          1.1 我习惯于把所有表加上前缀T_(即Table的第一个字母),把所有字段加上前缀F_(即Field的第一个字母),把视图加上前缀V_(即View的第一个字母)...,这样最大的好处是在写linq to Sql时,智能提示(感应)会很爽,所有相关的东西全部列在一起,省去记忆脑细胞无数

          1.2 这是我06年时从动网论坛剥下来的表结构(当然我又做了一些改造),它的最大特点在于:通过添加一些辅助字段完全避开了无限分类中的递归问题。
          1.3 之所以用guid做为主键,主要是考虑到数据库迁移时的方便,当然guid主键会带来一些性能上的损失(二害相权,取其轻也),为了改进可将guid改为comb主键(详见 “Integer GUID和Comb做主键的效率测试”)
          1.4 考虑到很多人为了各种原因喜欢把分类页生成静态页,而为了url地址的简短/友好,guid主键有些长,所以我又添加了一个辅助字段F_AutoId,这样生成的静态页可以从类似"43A6162C-308A-4112-86F8-6E6B6B76FC6E.html"变成"1234.html"

          二、产品分类--产品关联设计

          如果“产品:分类”是1:1关系(即:一个产品只能归到一个分类下),则直接在产品表(T_Product)中增加一个字段(F_ClsId)即可。
          如果“产品:分类”是1:N关系(即:一个产品能同时归到多个分类下),则必须新建一个表(T_ProductInClass),建二个字段(F_ClsId,F_ProductId),并把这二个字段设置为联合主键即可。

          注:1:1还是1:N取决于需求,没有谁好谁坏之说。

          三、扩展属性
          终于到了正题了,对于产品的扩展属性,因为(在产品分类未选择之前)无法事先确定产品的扩展属性有哪些,所以这部分属性显然不适合通过在T_Product中预留一大堆字段来解决(而且这样性能也不好)

          考虑到扩展属性总是基于分类的(比如:电脑类的产品应该具有"CPU频率、内存容量、显示器尺寸、硬盘大小"等扩展属性,而服装类产品应该具有“颜色、尺码、品牌、面料”等扩展属性),所以可以新建一个"分类扩展表"用于存储分类的扩展属性基础定义。

          1

          2

          3

          4

          5

          6

          7

          8

          9

          10

          11

          12

          13

          14

          15

          16

          17

          18

          CREATE TABLE [dbo].[T_ClassAppend](

          [F_Id] [uniqueidentifier] NOT NULL,--主键

          [F_ClsId] [uniqueidentifier] NOT NULL,--关联外键(分类ID)

          [F_DisplayName] [nvarchar](50) NOT NULL,--(扩展属性)显示名称(比如:品牌,内存大小,颜色之类)

          [F_FieldName] [nvarchar](50) NOT NULL,--(扩展属性)字段名称(比如:Brand,Memoery,Color之类)

          [F_ValueType] [nvarchar](50) NOT NULL,--字段类型(比如:字符串,整数,日期之类)

          [F_ValueLength] [int] NOT NULL,--属性值长度(比如:50)

          [F_InputType] [nvarchar](50) NOT NULL,--输入类型(比如:文本框,文本域,下拉框,复选框之类)

          [F_DefaultValue] [nvarchar](500) NOT NULL,--默认值

          [F_IsRequired] [tinyint] NOT NULL,--是否必须填写

          [F_isShow] [tinyint] NOT NULL,--显否显示

          [F_Orders] [int] NOT NULL,--排序号

          [F_AutoId] [int] IDENTITY(1,1) NOT NULL,--辅助自动ID(预留)

          CONSTRAINT [PK_T_ClassAppend] PRIMARY KEY CLUSTERED

          (

          [F_Id] ASC

          )WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]

          ) ON [PRIMARY]

          保存数据后的大概样子如下:

          解决了扩展属性的定义问题,接下来再来考虑产品的这些属性到底应该保存在哪里?

          先回顾一下产品上传的基本逻辑,在不考虑扩展属性的传统场景下:用户进入产品发布页面,选择产品分类,然后填写其它产品属性,最终保存到数据库。

          分析一下:只要用户选择了分类,我们就能得到分类ID,进而得到该类的“扩展属性定义”,也就知道了该产品应该具有哪些扩展属性,如果这时有一张特定的产品扩展属性表(来对应这些扩展属性的定义),那么直接把这些扩展属性insert进这张表即可。

          技术处理:保存产品时,先得到用户选择的分类ID,然后根据上面定义的T_ClassAppend分类扩展属性定义表,去检查是否已经生成了该类的"产品扩展属性表",如果没有则动态生成一个类似T_Product_XXXX的表(注:XXXX即为分类的F_AutoId值),然后该干嘛干嘛,常规公共属性保存进T_Product,扩展属性保存进T_Product_XXXX。

          注:T_Product 与 T_Product_XXXX 之间应该有(产品ID的)主外键关联

          如下图:

          注:图中的F_ID其实可去掉,没啥实际意义(最初我是打算用来保存记录流水号的,后来发现完全没啥必要,这一点精减工作就留给大家去做吧)

          可能存在的问题:
          1、产品修改时,如果从分类A改成了分类B(即发布时,产品分类选错了,在编辑时,重新指定产品分类),那么扩展属性对应的保存表名,可能会从T_Product_123 变成 T_Product_456,这时要注意先把原来的T_Product_123中的记录删除,不然时间长了,会留下一堆冗余记录。

          2、分类扩展属性有变动时,比如电脑类,又新增了一项属性:"是否支持双显卡(F_IsDoubleVGA)",那么这里原来的产品扩展属性表T_Product_123,也要相应的增加一个类似F_IsDoubleVGA的字段类型

          四、搜索问题的解决

          这部分其实是最难解决的,不过也不是没有办法,分二种情况:

          1、第一种情况

          通常情况下,用户其实很少一上来就搜索扩展属性,很多场合下,用户会先浏览某感兴趣分类列表,然后再挑选商品。

          这种情况就好办多了,因为用户一旦确定了分类,也就意味着能得到分类ID,进而得到最终的产品扩展属性表名(比如T_Product_123),这时搜索就简化为搜索 T_Product 与 某一个特定的T_Product_XXX

          2、第二种情况

          如果系统要求用户直接在搜索栏里输入 "ThinkPad 双显卡 4G内存 T系列"这类关键词,然后自动匹配出所有属性/扩展属性的商品。

          那么,其实这已经演化成网站搜索引擎的需求,传统的 select... like ...在这种需求下基本上已经没啥用处了,可以考虑用lucene或园子里"盘古分词"作者eaglet (注:该兄是搜索引擎方面的资深人士,值得信赖!)的解决方案来实现站内搜索引擎。

          后记:早上写得匆忙,有些细节没写详细,现在补上。

          看到回复中有些朋友觉得这种设计表太多,太复杂,这个嘛...其实我觉得还好啦,只是在原来的分类表T_Class的基础上,增加了一个T_ClassAppend表而已,至于那一堆的T_Product_XXX 表,我写了一个分类管理器来自动生成,不用手动来做,另外再封装一些逻辑(比如根据分类ID自动返回扩展属性表名之类),对于普通开发人员来讲,开发难度只是轻微增加而已.

          上图为分类管理器的界面。

          继续更新:

          看到越来越多的人回复来讨论这个问题,很是高兴(相互交流才能进步),特地又加了一张图,建议大家先在完全明白我的意图之后,再讨论如何改进,不然大家你用你的说法,我用我的说法,但其实完全有可能只是同一个问题的不同说法,这样沟通起来比较费劲。

          其实我的想法很简单:

          将商品的共用属性(比如:价格,商品名称,商品编码这些肯定要有的东西)与扩展属性(即:根据分类不同而不同的非共用属性,比如电脑类的"CPU/硬盘容量...",充值卡类的"面值/适用地区...",服装类的"尺码/颜色...")分开保存而已,相当于原本应该保存一张表T_Product中的东西,拆分成二部分。(但由于每个分类的特性不同,每个类对应的产品都有不同的扩展属性值,所以不适合把所有产品的扩展属性保存在同一张表中,如果这样可以的话,干嘛还要费心把共用属性与扩展属性分开,搞拆分这么麻烦?)

          共用属性保存到 T_Product表,而扩展属性保存到 T_Product_N 表(其中N 与 某一个分类记录的ID对应)

          在逻辑上可以认为,每条产品记录的全部属性,都是 "T_Product中的一条记录" + "T_Product_N(N为该产品所属分类的对应Id)中的一条记录" 共同描述的

          至于表的个数,其实只增加了“ 1 + N ” 张表(1即多出来的分类扩展属性定义表,而N即为T_Class中产品分类的记录条数),所以只要分类数不变,产品扩展表的数量也是一定的。

          至于大家提到的品牌问题,品牌其实最适合与分类当作平行处理,毕竟很多时候搞活动做专题,都是以品牌作为主要选择依据的(如果当成扩展属性处理,并非行不通,只是不适合)

          另外之所以会引出搜索问题,其实反过来考虑很容易理解,如果不做拆分,按传统方式,用Sql语句直接搜索T_Product表即可。但现在把属性分成了二部分,所以很难确定用户搜索时,是想搜索共用属性,还是扩展属性?所以有上面提到搜索的二种情况。

          最后谈一下数据库查询的问题,看到'小菁菁'同学的观点:数据库就是为了查询方便。基本上,这个没错!但是如果您遇到过单表千万级数量的情况,而且基于某些要求又无法利用索引。(比如最纠结的like该不该用的老问题:如果不用like,强制用=来处理,当然速度会快很多,但是查询就不准确,比如用户就记得产品描述中的几个字,别的都不记得,这时候站在用户的立场,无疑模糊查询是最好的,但是在海量数据情况下,这样做又几乎是灾难)。在这些特定情况下,关系型数据库(不管是sqlserver还是oracle)的查询能力都是无能为力的,如果您去百度一下关于搜索引擎的数据库设计,几乎看不到采用关系型数据库做为查询核心的。推荐几篇我以前收集的搜索引擎架构文章给您参考下http://www.cnblogs.com/yjmyzz/archive/2009/06/18/1506083.html

          当然"学无先后,达者为先"。如果大家有更好的解决方案,欢迎回贴指导。

          最后YY一句,就这种拍脑袋的设计,07年时曾经受住了日均IP10万的访问量,当时日均IP从中国站长站监测的结果,已经达到了同期中国新蛋日均IP的1.5倍(当然还有其它优化措施,这个就不一一展开了)

    展开全文
  •  针对超市的特点,为了帮助超市解决现在面临的问题,提高小型超市的竞争力,我们将开发以下系统:前台POS销售系统、后台管理系统,其中这两个子系统又包含其它一些子功能。  1.4应用范围  本系统适应于各种小型的...
  • 本系统为中小型超市销售管理系统,因此系统需求分析阶段主要采取实地采访、调查学校周边超市,网上查找相关资料,请教老师等多种方式,尤其是仔细思考、分析超市购物发票。这一阶段大概了解了目前超市销售管理的现状...
  • 员工管理可实现对员工信息的查询,当有新的员工进入超市时能够在该系统添加新的员工信息,当有员工离开超市时能够及时的将该员工的信息删除,以节省空间。库存管理可实现对库存货物的查询,包括货物的种类、数量、...
  • 数据库小型超市管理系统》

    热门讨论 2011-01-21 13:17:36
    整个系统基本包括了小型超市所要用到的模块。包括收款操作,库存查询,填写资金支出表,采购管理,库存管理,销售管理,资金管理,员工管理等。 1. 库存管理: 综合查询库存明细记录。 仓库信息搜索。仓库调度以及...
  • 1数据库设计-------小型超市管理系统摘要小型超市管理系统在现代社会的应用十分广泛,是一个典型的信息管理系统(MIS)。本课程设计采用了结构化和面向对象两种程序设计方法,从页面展示到后台数据库设计都具有一定...

    1

    数据库设计

    -------

    小型超市管理系统

    小型超市管理系统在现代社会中的应用十分广泛,是一个典型的信息管理系统

    (MIS)

    。本课程设计采用了结构化和面向对象两种程序设计方法,从页面展示到后台数

    据库设计都具有一定的可扩展性。本系统在

    Windows XP

    环境中采用

    Visual C++

    为开发

    平台,使用

    Microsoft

    Access 2000

    创建数据库,用于对超市资料的增加,删除,修改,

    刷新记录。经过分析、设计、编码、调试等一系列步骤。程序通过调试运行,初步实现

    了设计目标,并且经过适当完善后,将可以应用在小型超市中解决实际超市资料的管理

    问题,具备了一定的可用性。

    关键词:

    数据表;

    VC++

    数据库;控件绑定

    ODBC

    数据源

    1

    本课程设计主要解决在一个小型超市中,进行员工档案的管理、库存商品的管理、

    销售管理的程序设计。小型超市管理是管理的一个重要内容,随着时代的进步,小型超

    市也逐渐变得重要起来。如何管理好超市中员工、商品、销售的信息,成为超市管理中

    的一个大的问题。在这种情况下,一个可以规范化、自动化的小型超市管理系统就显得

    非常必要。

    之所以选择

    Visual C++

    作为开发工具,不仅仅因为曾经有过使用它的经验,看中的

    更是它的功能强大和使用方便。它本身不仅具有极其强大的编程能力,它允许选择和管

    展开全文
  • 数据库设计-------小型超市管理系统 班 级:06网络技术3班 姓 名:XX 指导老师:XXX 摘 要 小型超市管理系统在现代社会的应用十分广泛,是一个典型的信息管理系统(MIS)。本课程设计采用了结构化和面向对象两种...
  • 3、导入数据看:将supermarketdb.sql文件导入数据库中后 4、修改项目根目录下的c3p0-config.xml的配置文件: <property name="driverClass">com.mysql.jdbc.Driver</property> <property name="jdbcUrl">jdbc:...
  • 这是一套如此完整的代码,它包括了一个软件开发过程,从设计到实现的所有文档,资源以及完整源代码。
  • 一款适合中小型超市的管理系统,其中附带使用说明和数据库
  • 采用C#,VS2005工具设计中小型超市管理系统,主要包括登录、进货管理、销售管理、仓库管理、系统人事管理等模块。包括源代码及数据库,系统完整可运行。
  • 采用JSP技术构建的一个管理系统。整个开发过程首先对软件系统进行需求分析,得出...这种个性化的网上系统管理特别注重交互协调与管理的相互配合,激发了管理人员的创造性与主动性,对网上中小型超市商品而言非常有利。
  • 采用JSP技术构建的一个管理系统。整个开发过程首先对软件系统进行需求分析,得出...这种个性化的网上系统管理特别注重交互协调与管理的相互配合,激发了管理人员的创造性与主动性,对网上中小型超市商品而言非常有利。
  • 本人学习C#时间不长,所以程序很简单,但是自我感觉界面层次还不错,内容主要是应用程序与数据库的连接问题,所以想和初学C#的朋友一起分享
  • 小型超市管理系统

    2017-06-23 19:32:32
    本系统是小型超市管理系统,包含基本的购物,结算,管理员对商品的管理,对营业员和会员的管理等功能,采用VS2012开发,数据库采用mysql开发,shop文件夹有MySql.Data.dll,运行时要在项目导入。数据库创建sql...
  • 详细设计主要包括系统数据库访问的实现,主要功能模块的具体实现,模块实现关键代码等。最后对系统进行功能测试,并对测试结果进行分析总结。 包括程序毕设程序源代码一份,数据库一份,完美运行。配置环境里面有...
  • 该系统完成日常超市的综合信息管理和维护,它主要包括以下几个模块:人事信息管理模块,主要包含员工部门信息管理,员工的信息管理,员工考勤管理;商品采购信息管理模块,供应商的信息管理,供应商联系人的信息管理...
  • 包括程序源代码、数据库文件和所有的文档(外文翻译、论文、ppt等),适合用作毕业设计。
  • 周 次 1—4周 调研, 需求分析, 查阅资料,构思初步方案 5—8周 总体设计及基本系统框架...9—12周 详细设计,程序设计,数据库的设计 13—16周 数据库和编码的实现, 程序运行调试测试 17—18周 撰写论文, 准备答辩
  • 整个超市综合管理信息系统是一个很大的系统,它包括,人事管理模块,公司财务管理模块,商品采购管理模块,商品销售管理模块,企业用户查询模块等,各个模块有很大的相似性,因此,在这里主要以一个模块作为样板详细...
  • 数据库课程设计报告--小型超市管理系统,通过此次数据库的课程设计,真正达到了学与用的结合,增强了对数据库方面应用的理解,对自己今后参与开发数据库系统积累了不少经验,在实验过程,从建立数据开始,对数据库...
  • 东之源超市管理系统是用delphi开发的基于windows的小型数据库管理软件。使用该软件对中小型超市进行简单的进销存管理和数据查询,将给您的工作带来方便。该软件有界面漂亮、操作方便、简单管理等特点。
  • 针对超市的特点,为了帮助超市解决现在面临的问题,提高小型超市的竞争力,我们将开发一个小型的超市管理系统。此系统可以帮助超市管理者在短的时间内查询到商品的供货.库存.销售情况及了解顾客和商品的信息。它可以...
  • 对用户的需要在需求分析从上至下进行分析;在概念设计中用从底至上的分析方法对用户需求进行概念设计;...结合系统调试与测试共六个部分来对小型超市进销存管理系统数据库进行设计并证明数据库设计的优良性。
  • 该篇论文主要针对小型超市管理系统,通过系统功能架构设计、数据库设计两个方面就行了详细分析。 2.系统功能架构设计: 在系统架构设计包含了基本信息管理模块、货物管理模块、销售管理模块。...

    一、基本信息

    标题:学校小型超市管理系统设计

    时间:2016

    来源:信息与电脑(理论版)

    关键词:学校小型超市; 管理系统; 数据库;

    二、研究内容

    1.主要内容:

            该篇论文主要针对小型超市管理系统,通过系统功能架构设计、数据库设计两个方面就行了详细分析。

    2.系统功能架构设计:

            在系统架构设计中包含了基本信息管理模块、货物管理模块、销售管理模块。其中再进行细分:

      (1)基本信息管理模块:员工信息管理、商品信息管理、会员信息管理

      (2)货物管理模块:进货的入库管理、退货的管理

      (3)销售管理模块:已销售的商品单管理、顾客结账管理、销售商品的查询

    3.数据库设计:

      数据库设计中的相关表设计:员工信息表、商品信息表、会员信息表、进货(入库)信息表、商品退货表、销售信息表

    三、结论

    自己的总结:

           这篇论文很简明扼要,就从架构设计和数据库设计两个大的方面讲解。看完这篇论文后,对数据的建表有了一些想法,除了上文所提到的那些信息表外,也可根据自己的系统增加一些与系统功能相关的表。数据库作为信息管理的前提,它的设计对于系统中各个功能的实现有着很大的影响。自己比较熟悉的数据库就是 Oracle ,基本的建表以及相应的操作增删改查都会。但如何是这些表之间有正确的联系,不是很有把握。之前都是单表操作,没有这种完成一个系统的数据库建表。

    四、参考文献

    [1] 郑哲坚.学校小型超市管理系统设计[J].信息与电脑(理论版),2016,99-100.

    转载于:https://www.cnblogs.com/summer-liyun/p/9942790.html

    展开全文

空空如也

空空如也

1 2 3 4 5 6
收藏数 113
精华内容 45
关键字:

中小型超市数据库