在做数据库分类表的时候,通常会有这样的设计:一个字段是ID,另一个字段PID,PID指向自己的上级分类: 这样的设计带来的问题是:我要删除一个类,我希望它的子类全部一起删除: 在不知道分类有多少层级的时候,删除全部子类是非常麻烦的一件事情. 在设计表之初,只需要多一个辅助字段path,令path记住自己的id路径即可解决这个问题. 比如:电视的ID是1,它的PID是0(表示没有父类),海尔电视的ID是2,海尔电视的PID是1: 这时候电视的path就是"0,1",海尔电视的path就是…

MySql数据表设计,索引优化,SQL优化,其他数据库 1.数据表设计 1.1数据类型 1.2避免空值 1.3text类型优化 2.索引优化 2.1索引分类 2.2索引优化 3.SQL优化 3.1分批处理 3.2操作符<>优化 3.3OR优化 3.4IN优化 3.5不做列运算 3.6避免Select all 3.7Like优化 3.8Join优化 3.9Limit优化 4.其他数据库 原文微信公众号:芋道源码 原文地址:如何去写一手好SQL? 1.数据表设计 1.1数据类型 数据类型的选择原则…

目录: <MySQL中的两种临时表> <MySQL 多表关联更新及删除> <mysql查询优化之三:查询优化器提示(hint)> 一.      多表关联更新 问题描述:现有tdb_goods表(含有具体信息)和tdb_goods_cates表(没有具体信息),需要查询tdb_goods表的所有记录,并且按"类别"分组,且将分组结果写入到tdb_goods_cates数据表.然后通过tdb_goods_cates数据表来更新tdb_goods表 ² …

首先查找一下goods_cates表和table_goods_brands数据表 分别使用命令: root@localhost test>show columns from goods_cates;root@localhost test>select * from goods_cates; 1.无限分级表设计但这仅仅是示例,远远达不到实际的需求,比如说书籍这个类,在网站上可以搜索到在书籍这个分类下面还有历史,文学,经济等等子类,子类下面还有子类,这种无限分类如何设计呢?理论上可以设计很多张表,…

无限级分类表的设计(掌握'自身连接') 类似图书这种,会有很多种分类,而且在现实生活中这种分类会无限的往下分,所以不可能每有一个分类就创建一个分类表.应该使用下面这种语句 DROP TABLE IF EXISTS tdb_goods_types; CREATE TABLE tdb_goods_types( type_id SMALLINT PRIMARY KEY AUTO_INCREMENT COMMENT '分类ID', type_name ) COMMENT '分类名称', parent_i…

为了性能考虑,在阅读之前提醒大家,如果有子查询,子查询查询到的数据最好不要超过总数据量的30%. 查询有重复数据的记录 select * from F group by a,b,c,d having count(*)>1 select distinct * into #Tmp from tableName drop table tableName select * into tableName from #Tmp drop table #Tmp SQL删除重复数据方法 例如:  id name…

一: 设计表: user:   ID,  PWD,  name,  type archiveRecord:     referdate,   archiveNum,   owner,   user,  status,   returndate. 二: 数据库操作接口实现: 新建用户:user表, 管理员类型可以增加,删除,修改 用户. 对archive表:  增加, 删除, 改 archive检索: 6个字段可以组合查询:…

MySQL多表关联时的多表删除: DELETE t1, t2FROM    t1LEFT JOIN t2 ON t1.id = t2.idWHERE    t1.id = 25…

前言: 在我们项目开发中,数据库及表的设计可以说是非常重要,我遇到过很多库表设计比较杂乱的项目,像表名.字段名命名混乱.字段类型设计混乱等等,此类数据库后续极难维护与拓展.我一直相信只有优秀的库表设计才能发挥出MySQL最大的性能,前面有篇文章也分享了数据库的使用规范,本篇文章主要讲几个库表设计的小技巧,希望对大家有所启发. 1.int类型的选用 整型字段类型包含 tinyint.smallint.mediumint.int.bigint 五种,占用空间大小及存储范围如下图所示: 存储字节越小,…

说起用户表,大概是每个应用/网站立项动工(码农们)考虑的第一件事情.用户表结构的设计,算是整个后台架构的基石.如果基石不稳,待到后面需求跟进了发现不能应付,回过头来反复修改用户表,要大大小小作改动的地方也不少.与其如此,不妨设计用户表之初就考虑可拓展性,争取不需要太多额外代价的情况下一步到位. 先前设计 idusernamepassword用户名加上密码,解决简单需求,留个id作为其他表的外键.当然,那时候密码还可能是明文存储,好点的知道md5. 后来呢,随着业务需求的拓展,要加个用户状态 st…