图片 10

数据删除设计,MySQL技能提升篇

4,不能被用作历史表

History,
当你不知道怎么直接写sql时,你需要将从界面上操作的sql记录下来,查看历史记录,找出改动的sql,也帮助下次提升sql能力打下基础!

if exists(
    select null 
    from Product 
    where name ='xxx' and IsDeleted=1
)
update 
    set IsDeleted=0,
        ...
from Product 
where name ='xxx' and IsDeleted=1
else 
insert Product(...) 
values(....)

图片 1

用户的删除操作是将IsDeleted设置为1,在逻辑上表示删除数据,如果用户由于误操作,将重要数据行删除,那么只需要将IsDeleted重置为0,就能恢复数据。

图片 2

这样的Table Schema 设计看似完美:ID字段具有做clustered
index的天赋:窄类型,自增,不会改变;Name上的唯一约束,能够满足业务逻辑上的需求。但是,如果业务人员操作失误,将Product
的 Name 写错,需要将其删除,最简单的方式是使用delete
命令,直接将数据行删除,但是这种方式带来的隐患特别大:如果业务人员一不小心将重要的数据删除,那么,恢复数据的成本可能非常高。如果数据库很大,仅仅为恢复一条数据,可能需要N个小时执行还原操作。如何设计Table
Schema,才能避免在维护系统时出现被动的情况?

如果遇到要给领导或者同事展示数据库结构,那这个东西就很好了。直观形象看到关系,而且能够快速编辑字段(双击字段即可更改),用于数据结构审核更改,非常方便。

在实际的产品环境中,数据删除操作有两种方式:软删除和硬删除,也称作Logic
Delete 和 Physical
Delete。硬删除是指使用delete命令,从table中直接删除数据行;软删除是在Table
Schema中增加一个bit类型的column:IsDeleted,默认值是0,设置IsDeleted=1,表示该数据行在逻辑上是已删除的。

图片 3

2,每次引用该表时,必须设置filter

其实想说的高级,也许正是体现在这里,够直观,够快速!

delete Product
where Name='xxx'

mysql作为绝大部分公司使用的数据库,自然是牛牛牛!

Product(ID,Name,Content,IsDeleted,DeletedBy)

七、备份导出,保证不丢失你的数据;

delete from Product 
output deleted.ID,
    deleted.Name,
    deleted.Content,
    'Delete' as CommandType 
    '' as UpdatedBy,
    getdate() as UpdatedTime
into History_table
where Name ='xxx' -- or use Id=yyy as filter

一、创建新库新表,开始你的工作;

 

图片 4

数据表是用来存储数据的,不是用来用户操作的历史记录。如果需要存储用户操作的历史记录,必须使用另外一个HistoryOperation来存储。

八、查询出的结果,进行优化展示及修改;

在设计一个新系统的Table
Schema的时候,不仅需要满足业务逻辑的复杂需求,而且需要考虑如何设计schema才能更快的更新和查询数据,减少维护成本。

创建视图、存储过程、触发器、事件,高级mysql应用,这些事应该是DBA的活,但是作为普通开发或其他类型工作,了解一下还是有必要的。

3,手动处理外键关系

六、界面式设计数据,更好的展示关系图;

在设计思路上,ID是自增的Identity字段,用以唯一标识一个Product;在业务逻辑上要求Name字段是唯一的,通过Name能够确定一个Product。业务上和设计上有所冲突在所难免,解决冲突的方法其实很简单:将ID字段做主键,并创建clustered
index;在Name字段上创建唯一约束,保证Product Name是唯一的。

每个人都能设计数据库,都能从删库到跑路。但是,如何做到更好,更快,更准地建立你的mysql数据库,这是个值得关注的问题(尽管很多人已经去搞大数据去了,但是思路仍然是通用的)。

如果Product表的数据量十分大,额外的查询操作,会增加插入操作的延迟,同时,"无效"的历史数据降充斥在数据表中,也会降低数据查询的速度。

图片 5

update Product
set IsDeleted=1
where Name='xxx'  -- or  use ID=yyyy as filter

由浅入深!!!

如果在该表上创建外键关系,那么可能存在外键关系引用被逻辑删除的数据,造成数据的不一致性,这可能是很难发现的bug:如果需要保持关键关系的一致性,需要做特殊的处理。在将数据行逻辑删除之时,必须在一个事务中,将外键关系全部删除。

在做测试时,往往有些环境上没有你需要的东西,而你又知道有一个最新的库,这里就想直接将这里的数据同步过去。快速复制就可以,同步相对麻烦!

Product(ID,Name,Content)
OperationHistory(ID,ProductID,ProductName,ProductContent,CommandType,UpdatedBy,UpdatedTime)

总体来说,存储过程和事件会显得更有用,存储过程可以你频繁操作的多个表,连在一起操作带逻辑,事件可以清理一些通用工作。add一个:

1,能够快速恢复被误删除的数据

图片 6

--view definition
select ID,Name,Content
from Product
where IsDeleted=0

所谓,见多,则识广!

设计目的:在短时间内恢复被误删除的数据,以使系统尽快恢复

图片 7

Product(ID,Name,Description)

五、快速复制一个基准的数据库到另外的机器上,让同步不再麻烦;

软删除实际上是一个Update
操作,将IsDeleted字段更新为1,在逻辑上将数据删除,并没有将数据行从物理上删除。使用软删除,能够保留有限的数据删除的历史记录,以便audit,但是,这可能导致外键关系引用被逻辑删除的数据;如果历史记录太多,这又会导致数据表中有效数据行的密度降低,降低查询速度。

图片 8

恢复误删的数据,只需要到History表找到相应的数据,将其重新插入到Prodcut
表中,并且,History
表中不仅可以存储用户删除操作的历史记录,而且可以存储用户更新的历史记录,对于系统的维护,解决用户纠纷和故障排除,十分有帮助。

sqlyog查询出的结果默认是不让修改的,需要手动设置一下。有时一个输入框无法正常显示的,可以使用文本进行展示。

单纯从业务需求上考虑,软删是首选的design,定期清理软删的冗余数据,也可以提高数据查询的速度,不过,在清理数据时,可能会产生大量的索引碎片,造成并发性降低等问题。

图片 9

模拟一个场景,有如下Table Schema:

三、添加索引,优化你的数据;

使用软删除设计,增加IsDelete=1
字段,实际上降低了有效数据的密度,在使用软删除时,必须慎重考虑这一点。改进的删除数据的设计是:在一个事务中,将删除的数据存储到另外一个History表中。

管理好外键是关键呢。要建立外键必须有几个前提。1.
两个表必须是InnoDB表类型。2. 使用在外键关系的域必须为索引型(Index)。3.
使用在外键关系的域必须与数据类型相似。
满足这几个条件后,直接拖动字段即可生成关系。

任何引用该表的查询语句中,必须设置Filter:IsDeleted=0,为来避免遗漏filter,可以创建视图,不直接引用该表,而是直接引用视图。

四、创建视图、存储过程、触发器、事件,高级mysql应用,DBA干的事;

上述Product表中Name字段上存在一个唯一约束,如果用户将相同Name的Product重新插入到table中,Insert
操作因为违反唯一约束而失败,针对这种情况,软删除操作必须额外进行一次判断:

每个工具都有自己的强项,合理利用好强项,能让工作更加顺利!

5,将删除的数据存储到History表

Alter Table > Indexes > Columns
添加索引,添加适当的索引,是一个数据库设计的基本常识。

为设计Product
表的删除操作,需要两个Table,对于OperationHistory表,可以做的更通用一些。抛砖引玉,提供一个思路,我就不做扩展了。

在没有sql桌面工具时(或者对于大牛来说),他们是不会用到桌面工具的,都是一个字一个字的码出数据库,这当然是根本。但是,能够高效地利用工具,尤其在有的场合必须要用工具时,又何偿不是一种好事呢!下面我就来总结下mysql桌面工具
sqlyog 的一些应用吧,在总结的同时,也希望能点燃你不经意的眼睛。

图片 10

【编辑推荐】

Tables > Create Table , 话不多说,填写表名,选择引擎,字符集

二、查看历史记录,记录下你不会的SQL,上线时使用;

这个功能是最基本的,直接右击导出,导入即可。
但是对于大数据量的导入,往往会发生错误,这时,就得自己删除部分数据,再进行导入了。