python制作web数据库系统_我的第一个python web开发框架(4)——数据库结构设计与创建...

小白做好前端html设计后,马上开始进入数据库结构设计步骤。

在开始之前,小白回忆了一下老大在公司里培训时讲过的数据库设计解说:

对于初学者来说,很多拿到原型时不知道怎么设计数据表结构,这是很正常的事,可以通过借鉴别人的项目总结经验,慢慢就会了。

拿到原型后,我们要认真观察原型里显示的内容有那些,考虑一下这些内容中那些是不变的,即写死在页面中的,那些是需要后台更改变动的,将这些变动的记录下来,添加到数据字典中。在记录这些字段时,还要做的事就是分类,一个类别就是一个数据表。(当然如果初学者很牛的话,那你也可以像一些架构师大神那样,不用原型直接打开设计工具绘制表结构关系图也没有任何问题)

然后我们再根据业务流程与业务需求,对字段进行增减优化。

最后再根据目标业务量,与一些非功能的质量属性要求,来优化表结构。做完这一步,数据表结构设计就八九不离十了。

当然在设计时,我们要注意的是表结构的可扩展性,也就是说某些字段会不会存在一对多的情况,如果你设计成一对一的话,那有可能后续要升级功能时就会遇到很多障碍了。

另外,我们也要立足当前,不能为了将来有可能的事情去增加一大堆冗余字段,到最后可能多了好多没有用过的字段存在。对于python来说,它不需要去生成一大堆实体类,所以我们在后续根据需要添加各种字段也是非常方便的,建议绝要用到时再添加对应的字段。

一、表结构设计

首先我们打开有公司介绍的页面

129385-20170906113358710-1575801118.png

129385-20170906113003038-255269237.png

可以看到公司介绍里面显示的是图片和文字信息,它属于信息编辑类型,而联系我们也是一样的,所以可以把它们放到一个信息表中统一管理,根据原型我们可以看到首页和公司介绍页面展示的图片大小是不一样的,所以需要增加一个封面图片地址字段,用来存放首页显示的图片地址,而公司介绍页的图片与内容文字可以一起存储到内容字段中(首页展示内容时,可以使用代码过滤掉内容中的图片),所以这里需要两个字段来存储对应的内容。另外,为了方便后台管理员区分这是什么内容的记录,所以再增加一个标题字段来进行说明,不用做前端展示用。

前面的分析,小白使用老大给的数据字典excel模板,设计对应的数据表结构(使用的是postgresql数据库,见下图)

129385-20170906113515147-1861399475.png

PS:主键几乎每个数据表都是必须的,一般使用自增类型的整形数值,对于数据量比较大的分布式数据结构,多数会用uuid做为主键id;另外对于信息表,还会增加一个额外的add_time来存储这条记录添加的时间

打开产品中心与产品详情页面

129385-20170906113009788-1720397034.png

129385-20170906113015366-1760427789.png

从原型的产品中心页面,我们可以看到左栏有产品分类列表,右栏是产品详细内容,所以我们需要分两个表来进行存储,并将它们关联起来。产品分类表用来存储分类信息(需要有分类名称字段),用于管理前端分类列表的展示,可以增加是否启用字段,方便新增或下架某个系列产品时,批量上线或下线操作用的(显示或隐藏该分类)。

而产品信息表则可以根据产品详情页面所展示的内容字段来进行添加(从产品详情页面上可以看到,需要产品名称、编码、规格、保质期、产地与产品描述字段)。除了页面展示内容外,我们还需要增加产品分类id字段,用来绑定产品分类表,用于点击产品分类时,后台根据这个分类id来查询出对应的产品。另外增加封面图片地址字段,用于显示产品列表时,展示对应的图片。最后是否启用字段也是为了显示和隐藏产品用的。

129385-20170906115153272-1570184602.png

除了以上内容外,我们还需要增加一个管理员管理表,用来管理后台登录用户用的,由于这个企业站太小了,所以小菜鸟偷懒不做这个管理页面,哈哈...后面的故事慢慢展开后会逐渐完善系统功能

129385-20170906115229726-55839368.png

二、数据表SQL代码生成

运行下载包中的ExcelToPostgreSql.exe(这是用C#开发的,需要Framework 3.5才能运行),选择下载包中的数据字典,然后填入Excel表名称Sheet1,点击运行就可以看到生成好的Sql执行代码了(如果用WPS打开了数据字典,点运行可能会无反应,是因为WPS独占了excel文件,需要关闭后才会正常运行)

129385-20170906194745194-1111454127.png

PS:由于这个软件是随手写出来的,所以不是很完善,必须遵循下面一些要求才行

第一行列的中文说明不能删除,不然运行时会出错;表与表之间要空一行;主键列支持PK(创建主键)、IX(生成索引)与UX(创建唯一索引)三种,如果想要创建复合索引,只能手动添加;允许空列,只需要添加no就会添加非空限制;默认值列,默认时间类型字段为null值,如果想要设置为now(),即生成当前时间,则需要将允许空列设置为no就可以了,因为now可能是excel的关键字,这个默认值程序读不出来;另外,text类型字段默认值为'',即生成时会自动添加。

三、创建数据库与数据表

打开pgAdmin连接本地postgresql数据库

点击

129385-20170906200708944-1112061441.png

在弹出窗口中,输入数据库名称:simple_db,点击确定,完成数据库创建。

129385-20170906201809038-1284404704.png

然后点击刚创建好的数据库后,再点击标题栏的sql查询分析器

129385-20170906202454147-514931731.png

在弹出来的sql编辑器窗口中粘贴前面生成好的sql语句进来,然后点击执行查询,数据表就创建好了

129385-20170906202700085-1599882885.png

接着清空sql编辑器里的代码,输入下面语句,点击执行创建后台管理员账号,方便后面开发操作

INSERT INTO manager(login_name, login_password, is_enable) VALUES ('admin', 'E10ADC3949BA59ABBE56E057F20F883E', 1);

到这里就完成了数据库的相关设计与创建工作了,点击下面链接下载相关文件

版权声明:本文原创发表于 博客园,作者为

python开发QQ群:669058475(本群已满)、733466321(可以加2群) 作者博客:http://www.cnblogs.com/EmptyFS/

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
数据库的名字叫WawaDB,是用python实现的。由此可见python是灰常强大啊! 简介 记录日志的需求一般是这样的: 只追加,不修改,写入按时间顺序写入; 大量写,少量读,查询一般查询一个时间段的数据; MongoDB的固定集合很好的满足了这个需求,但是MongoDB占内存比较大,有点儿火穿蚊子,小题大的感觉。 WawaDB的思路是每写入1000条日志,在一个索引文件里记录下当前的时间和日志文件的偏移量。 然后按时间询日志时,先把索引加载到内存中,用二分法查出时间点的偏移量,再打开日志文件seek到指定位置,这样就能很快定位用户需要的数据并读取,而不需要遍历整个日志文件。 性能 Core 2 P8400,2.26GHZ,2G内存,32 bit win7 写入测试: 模拟1分钟写入10000条数据,共写入5个小时的数据, 插入300万条数据,每条数据54个字符,用时2分51秒 读取测试:读取指定时间段内包含某个子串的日志 数据范围 遍历数据量 结果数 用时(秒) 5小时 300万 604 6.6 2小时 120万 225 2.7 1小时 60万 96 1.3 30分钟 30万 44 0.6 索引 只对日志记录的时间索引, 简介里大概说了下索引的实现,二分查找肯定没B Tree效率高,但一般情况下也差不了一个数量级,而且实现特别简单。 因为是稀疏索引,并不是每条日志都有索引记录它的偏移量,所以读取数据时要往前多读一些数据,防止漏读,等读到真正所需的数据时再真正给用户返回数据。 如下图,比如用户要读取25到43的日志,用二分法找25,找到的是30所在的点, 索 引:0 10 20 30 40 50 日志:|.........|.........|.........|.........|.........|>>>a = [0, 10, 20, 30, 40, 50]>>>bisect.bisect_left(a, 35)>>>3>>>a[3]>>>30>>>bisect.bisect_left(a, 43)>>>5>>>a[5]>>>50 所以我们要往前倒一些,从20(30的前一个刻度)开始读取日志,21,22,23,24读取后因为比25小,所以扔掉, 读到25,26,27,...后返回给用户 读取到40(50的前一个刻度)后就要判断当前数据是否大于43了,如果大于43(返回全开区间的数据),就要停止读了。 整体下来我们只操作了大文件的很少一部分就得到了用户想要的数据。 缓冲区 为了减少写入日志时大量的磁盘写,索引在append日志时,把buffer设置成了10k,系统默认应该是4k。 同理,为了提高读取日志的效率,读取的buffer也设置了10k,也需要根据你日志的大小适当调整。 索引的读写设置成了行buffer,每满一行都要flush到磁盘上,防止读到不完整的索引行(其实实践证明,设置了行buffer,还是能读到半拉的行)。 查询 啥?要支持SQL,别闹了,100行代码怎么支持SQL呀。 现在查询是直接传入一个lambada表达式,系统遍历指定时间范围内的数据行时,满足用户的lambada条件才会返回给用户。 当然这样会多读取很多用户不需要的数据,而且每行都要进行lambda表达式的运算,不过没办法,简单就是美呀。 以前我是把一个需要查询的条件和日志时间,日志文件偏移量都记录在索引里,这样从索引里查找出符合条件的偏移量,然后每条数据都如日志文件里seek一次,read一次。这样好处只有一个,就是读取的数据量少了,但缺点有两个: 索引文件特别大,不方便加载到内存中 每次读取都要先seek,貌似缓冲区用不上,特别慢,比连续读一个段的数据,并用lambda过滤慢四五倍 写入 前面说过了,只append,不修改数据,而且每行日志最前面是时间戳。 多线程 查询数据,可以多线程同时查询,每次查询都会打开一个新的日志文件的描述符,所以并行的多个读取不会打架。 写入的话,虽然只是append操作,但不确认多线程对文件进行append操作是否安全,所以建议用一个队列,一个专用线程进行写入。 锁 没有任何锁。 排序 默认查询出来的数据是按时间正序排列,如需其它排序,可取到内存后用python的sorted函数排序,想怎么排就怎么排。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值