需求：表edit需要将数据更新到表release，里边会涉及增删改操作，如何做比较好？？？
1、edit表是最新的数据，release表是线上表。
a. 需要找到edit表和release表之间的差别，那么需要记录edit表中更新的情况，需要区分modify，add，delete等不同操作，并且需要此操作是一个事务操作，向线上表更新，然后将modify和add改为done，并删除delete的数据。
b. 如果更新的数量很大的情况呢？就是很多行都会更新，需要遍历所有修改数据并update，会导致大量数据被锁住，影响线上容器对表的读取。
此时我们可以采取再建一张表，在另外一张表version里，打上到底使用哪张表. 即读取数据的时候是在两个表之间来回跳跃的
1、update version = edit，之后再慢慢更新到release表上，另外的容器读的时候，先看version指向哪个表，再去读，
2、如果需要考虑效率的话，建一个tmp表，将edit中数据insert到tmp中，然后删除release表，再给tmp表改名为release。
缺点：比较繁琐，多个线程读version表时，若有线程卡住或延时，可能会造成读取错误的表，同时该update操作需要加锁。
c. 分析一下业务逻辑，到底需要建两张表么？？？？最好的办法是只维护一张表，这样就不用考虑每次更新时的响应问题，加锁等问题
重新梳理一下业务逻辑，我们的原始需求是：
1、给每个list添加删除修改排序“tag”，当点击发布的时候需要将对tag的修改操作更新到线上，scheme应该是 tagID， tagName， listID， sort，tagID递增的
2、另外的容器读取分类是在该表查找该listID对应的所有的“tag”
3、如果编辑时增加了一个新tag，那么线上也会多了一个tag，此时出现bug，因此应该加一个status状态 enum为 ONLINE, OFFLINE，那么新增加的tag为OFFLINE，发布时改为ONLINE，此时不会影响线上
4、如果编辑时删除了一个分类，为了不影响线上，我们不能在表里删除这个tag，应该加一个valid状态，enum为VALID, INVALID， 删除的直接打上INVALID即可，即发布时将Valid的offine数据改为online。
5、修改tagName这个操作可以转化为增加和删除操作，首先将之前的tag的valid状态改为INVALID，然后insert一个和原tag都一样但name改变了的tag，但是发现之前的tagID是主键，现在重复了，所以
需要再添加一个递增id作为主键，将catID变为随机数。
6、排序操作我们默认的是冒泡法的排序，那么也可以转化为增加和删除。
缺点：增删改查变得复杂，在存储上会有一定的冗余。 好处：会记录每行的历史（如果有用的话），上线操作非常迅速，只用一条SQL语句，将将Valid的offine数据改为online，且不会对访问造成影响。