1. 数据库怎么设置兼容级别！
查看或更改数据库的兼容级别
连接到 SQL Server 数据库引擎 的相应实例之后，在对象资源管理器中，单击服务器名称。
展开“数据库”，然后根据数据库的不同，选择用户数据库，或展开“系统数据库”，再选择系统数据库。
右键单击数据库，再单击“属性”。
“数据库属性”对话框将打开。
在“选择页”窗格中，单击“选项”。
当前兼容级别显示在“兼容级别”列表框中。
若要更改兼容级别，请从列表中选择其他选项。可用选项包括SQL Server 2005 (90)、SQL Server 2008 (100)或SQL Server 2012 (110)。
2. 如何实现Oracle，Mysql，SqlServer数据库的兼容
没个数据库的语法总会有那么点
或多或少的区别，你说的兼容
是指
做项目的时候，切换不同的数据库，而只需写一种语句么？如果是的话，那我推荐你使用
Hibernate
，给它配置
sessionFactory
，几个数据库，就写几个sessionFactory
，这样就能只需写个hql语句，就能实现我说的
切换数据库了，不知道
是不是你需要的
3. 表格改变字段时，该如何兼容历史数据
业务是不断变化发展的，产品也是会随之不停迭代的，数据表格作为基本组件也常常需要变动，这在我们的日常工作中是非常常见的。
比如下面这个例子，一款分析淘宝商家移动端店铺数据的产品，其中菜单“流量来源”是对店铺流量的分析，在店铺发展初期“淘内免费”、“付费流量”、“自主访问”能够支撑业务方对于店铺数据的分析，但是随着店铺业务不断发展做大做强，对于流量分析的颗粒度要求越来越细，只是对流量的简单划分已经无法满足业务方的需求。希望能对于淘内流量能有更细的分类，帮助业务方对店铺流量有更细致的了解，从而根据不同流量大小调整运营策略，促进店铺销售数据的发展。
现状：淘内免费 付费流量 自主访问
期望：手淘搜索 我的淘宝 淘内免费其他 手淘微淘 手淘扫一扫等
需求：改动“流量来源”数据表格中的字段
当原有产品无法满足当前的业务发展时，为了满足业务的新需要，服务于新的场景。不得不要求我们去改变最初的产品设计，改动表格中的字段设计。而改动“数据表格”的字段很容易引发数据冲突的情况，包括数据类型冲突、数据格式冲突等。
如果在改动表格字段时，不去考虑数据冲突的影响，不去考虑如何兼容历史数据，会导致产品内的数据在完整性和一致性上出现问题，比如上文中案例如果不进行历史数据兼容处理，选择在3.19号上线新的统计功能，关于流量的划分就会存在两种不一样的统计方式，19号前的流量数据划分方式和19号之后不一致，按月维度下没有办法对3月的流量数据做一个统一划分。
历史数据一定意义上成为了“脏数据”，有句话说的好叫“垃圾数据进垃圾数据出”，数据质量对于分析结果的重要性甚至高于分析方式和模型。混入脏数据后产出的结果对业务造成严重的影响，甚至做出了错误的决策，带来不可磨灭的损失
因此，我们有必要去解决“表格改变字段”后产生的数据冲突，去兼容历史数据，减少改动对数据产生的负面影响。那么问题来了，我们该怎么去兼容历史数据呢？
01 历史数据都是需要保留的吗
表格改变字段出现数据冲突的情况后，在我们去兼容历史数据之前可以先思考一个问题：历史数据都是需要保留的吗？一起来看下下面的两个场景。
场景1
某电商to b产品，在一次迭代中，对“店铺销售”菜单增加了“客单价”字段，那么历史数据中的客单价对我们有意义吗？
场景2
我们设计了一套问卷用于统计“国内大学生的不同专业的就业情况”，投放问卷一段时间后对问题就行了修改，那么收集的历史数据对我们还有意义吗？
通过两个具体的场景，我们可以发现“历史数据”在不同的场景下的保留策略是不同的：
场景1中的“客单价”能帮助复盘店铺历史的客单价情况，和当前时间的“客单价”进行对比，对店铺策略起到数据指导作用，在此场景下历史数据具有重要意义，需要保留。
而场景2中收集的“你的国家是什么”和场景题干“国内大学生”矛盾，问卷的修改也是为了解决这一矛盾才修改题目的，所以该题目收集来的历史数据无效，不需要保留可以直接废弃。
历史数据是对过去业务情况的记录和反馈，但并不是所有的历史数据都是有意义的，也不是所有历史数据都需要保留的。当需要考虑历史数据兼容问题前，建议先从实际的场景出发去分析一下“历史数据”对于业务的价值和意义，如果关联不大或者本身就是错误的数据，直接废弃历史数据就OK了。对于要保留的历史数据，才需要去考虑冲突在哪里，以及怎么去兼容
02 怎么去兼容历史数据
在我们思考了历史数据的价值和意义之后，确定要保留历史数据，那么我们怎么去兼容历史数据呢？首先，我们需要区分不同的数据表格改变方式，会带来怎么样的数据冲突，再根据不同的冲突情况去提出相对应的兼容方案
1. 增加字段
我们经常会遇到在表格上“增加字段”的情况，比如增加了新的业务字段，增加了新的统计项。
如果不做兼容处理，就会出现增加的字段有增加后的新数据，但是没有历史数据。这种情况下，需要我们判断历史数据能否被补全，若能，则补全历史数据；若无法补全，新增的字段历史数据空白展示。
2. 减少字段
当出现“减少字段”的情况，如果不做处理，会出现减少的字段没有新数据，但是有历史数据。这种情况下，我们的处理方式是保留历史数据，减少统计后该字段空白展示。
3. 原字段统计逻辑或规则改变
统计逻辑或规则被改变时，不进行数据兼容的话，因为新数据和历史数据的统计方式不一致，会导致数据结果出现差异。这个时候，需要我们去判断历史数据能否按新的统计逻辑换算，若能，则按新逻辑重新统计；若不能保留历史数据，并记录统计逻辑的改变记录。
4. 原字段下钻或合并统计
这种改变会出现新字段和历史字段是包含或者被包含的关系，需要我们去补全历史数据，比如字段A被下钻成了新字段B+新字段C，根据下钻规则补全新字段B和C的历史数据值。
而在实际的场景中，数据冲突会同时存在多种，所采用的方案也是多个解决手段组合的。
比如下面这个案例，我们对“客户管理”模块进行迭代，通过调研发现内部销售团队希望能在“客户管理”菜单中增加“客户微信”字段，并提供根据客户等级自动计算出“下次回访时间”，为此我们对“客户管理”的字段进行了调整。
表格改动为：增加“客户微信”、“下次回访时间”字段，减少“创建时间”字段。这里就涉及到了“增加字段”和“减少字段”两种情况，通过分析“客户微信”和“下次回访”字段对存量客户具有重要意义，收集到客户的微信联系方式和具体的回访时间，方便业务员展开业务，两个字段的数据也有被补全的条件；而减少的“创建时间”字段对于业务影响不大，可以废弃。基于上面的考虑，我们对“客户管理”菜单做了如图处理。
迭代发布上线后，产品同学提出“下次回访时间”直接展示时间，对销售团队来说不够直观，可以对“下次回访时间”进一步处理，更加直接明了，因为“下次回访时间”字段中原有的时间格式是支持现在的规则换算的，就可以对时间进行了换算处理。
对“下次回访时间”的展示进行处理，计算“下次回访时间”和当前时间的差值：
原统计格式：yyyy-mm-dd
新统计格式：X天后回访；已过期X天
随着业务的发展又遇到了“字段统计逻辑和规则无法转化”的情况，“客户管理”中“意向产品”的可选项从“商品1，商品2，商品3”变成了“商品5，商品6，商品7”，改动前后的数据没有办法去简单的进行兼容，而前后数据对于业务来说都是具有意义的，那么我们需要在保留两者数据格式的前提下，做一些文案上的提示，例如在操作日志记录系统对于规则的更改。
从上面这个案例中我们发现，表格的变动不单单只有出现一种冲突，我们采取的解决方案也是多样的。
03 兼容历史数据的价值和场景
表格字段的改动会导致历史数据和改动后数据的冲突，而数据冲突会导致在产品层面的数据没有连贯性，进一步导致了用户无法理解前后数据，对产品产生了疑问，以至于产生了负面情绪。
简单的对表格字段进行增减，对于用户的影响相对于较少，降低了用户对数据的可读性，比如上文案例中增加减少字段，不做处理的话，用户会对部分情况有数据部分情况无数据产生疑惑增加了理解成本。
但是对于更改统计逻辑的，就不只是简单用户体验上的问题了，会给业务带来实际的影响，比如上文中意向产品中可选择的产品变更了，如果不及时对于历史数据进行兼容，做相关的变动说明处理，很容易给业务员带来之前的商品仍然可以进行销售的误判，最终导致下错订单甚至下单后无法发货，给公司业务带来实质的亏损
由此可见，兼容历史数据的价值，在于解决这一系列的数据冲突，既保证了产品层面的数据连贯性，也让用户了解到数据变动的原因，降低了用户的负面情绪和理解成本。更重要的是，不仅可以 能帮助用户复盘业务情况，对业务起到指导作用，而且避免事故和损失的发生
但是兼容历史数据也不是在所有场景都适用的，当我们涉及到的改动非常大的时候，比如业务发生巨大的变化导致原有表格字段全部推翻重新设计时，就不建议采用上文的兼容方案，可以选择新老数据交替过渡，原有的表格提供对老数据的支持，新建一个表格用于支持新字段的展示，通过这种方式，完成从历史存量业务到新业务的过渡；又比如整体项目需要重构，可以选择数据迁移方案
现在当我们再次遇到历史数据冲突需要兼容的情况时，可以判断如何选择了吗？