数据库

REST API with Mongoose 在REST API Server中，每一个来自前端的请求都要进行相应的后端数据库操作。 例如，响应 GET 请求要在数据库进行数据检索：为了端到端地处理 GET 请求，一个来自客户端的 GET 请求，意味着客户端想要在服务端检索数据来使用；所以，要经过多个Express 服务的处理，然后业务逻辑需要在数据库中执行一个查询操作；启动一个查询操作，从数据库获取一组documents，再转换为回复信息，发回给服务器。 所以，这个端到端的请求响应处理涉及到两个部分，一部分是处理业务逻辑，一部分是与数据库进行交互。 再来看 POST 请求： ​ POST 请求通过请求体发送信息，请求体经Express Server处理后，启动相应的 create 请求到MongoDB，在 create 请求中，将在数据库中某个 collection 中创建新的 document ，并将处理后的请求体信息存储到其中。最后，这个操作到的结果通过响应发回给客户端。 所以，对REST API端执行的任何操作，无论是GET、PUT、POST还是DELETE，都会在背后启动对应的数据库操作。也就是说，在REST API端收到的HTTP请求必须映射到相应的数据库操作。 更改 dishRouter.js const express = require('express')

//添加Oracle数据库字段是，日期字段自动添加系统时间 insert into 表名 (字段名) values(sysdate) //建表时，设置为自动添加时间 建表的时候指定默认值即可default sysdate 如: create table t1(d date default sysdate) //把表中的时间修改成自动添加系统时间 alter table t1 modify(d default sysdate) 来源： https://www.cnblogs.com/131409230414zzf/p/12590662.html

这里主要介绍最常用的两种存储引擎。 1.InnoDB InnoDB是一个事务型的存储引擎，有行级锁定和外键约束。 Innodb引擎提供了对数据库ACID事务的支持，并且实现了SQL标准的四种隔离级别，关于数据库事务与其隔离级别的内容请见数据库事务与其隔离级别这类型的文章。该引擎还提供了行级锁和外键约束，它的设计目标是处理大容量数据库系统，它本身其实就是基于MySQL后台的完整数据库系统，MySQL运行时Innodb会在内存中建立缓冲池，用于缓冲数据和索引。但是该引擎不支持FULLTEXT类型的索引，而且它没有保存表的行数，当SELECT COUNT(*) FROM TABLE时需要扫描全表。当需要使用数据库事务时，该引擎当然是首选。由于锁的粒度更小，写操作不会锁定全表，所以在并发较高时，使用Innodb引擎会提升效率。但是使用行级锁也不是绝对的，如果在执行一个SQL语句时MySQL不能确定要扫描的范围，InnoDB表同样会锁全表。 适用场景： 1）经常更新的表，适合处理多重并发的更新请求。 2）支持事务。 3）可以从灾难中恢复（通过bin-log日志等）。 4）外键约束。只有他支持外键。 5）支持自动增加列属性auto_increment。 2.MyIsam MyIASM是MySQL默认的引擎，但是它没有提供对数据库事务的支持，也不支持行级锁和外键，因此当INSERT(插入

@MappedSuperclass使用条件： 　　当我们进行开发项目时，我们经常会用到实体映射到数据库表的操作，此时我们经常会发现在我们需要映射的几个实体类中，有几个 共同的属性 ，例如编号ID，创建者，创建时间，修改者，修改时间，备注等。遇到这种情况，我们可能会想到把这些属性 抽象出来当成一个父类，然后再以不同的实体类来继承这个父类 。 　　那么，我们便可以使用 @MappedSuperclass注解 ，通过这个注解，我们可以将该实体类当成基类实体，它 不会映射到数据库表 ，但继承它的子类实体在映射时会自动扫描该基类实体的映射属性，添加到子类实体的对应数据库表中。 @MappedSuperclass使用场景深入了解 基于代码复用和模型分离的思想，在项目开发中使用JPA的 @MappedSuperclass 注解将实体类的多个属性分别封装到不同的非实体类中。 1.@MappedSuperclass注解只能标准在类上，用来标识父类的： @Target({java.lang.annotation.ElementType.TYPE}) 2.标注为@MappedSuperclass的 类将不是一个完整的实体类 ，他将不会映射到数据库表，但是他的属性都将映射到其子类的数据库字段中。 3.标注为@MappedSuperclass的 类不能再标注@Entity或@Table注解

转载自：http://www.cnblogs.com/snooper/archive/2009/09/07/1561715.html 搭建 Mantis 缺陷管理系统 By Snooper 错误必有！欢迎指正！ 什么是 Mantis MantisBT is a free popular web-based bugtracking system (feature list). It is written in the PHP scripting language and works with MySQL, MS SQL, and PostgreSQL databases and a webserver. MantisBT has been installed on Windows, Linux, Mac OS, OS/2, and others. Almost any web browser should be able to function as a client. It is released under the terms of the GNU General Public License (GPL). Mantis 是一个 BUG 管理系统。主要特点如下： 1、 用 php 写的系统，安装方便，不用像 bugzilla 那样安装那么多 perl 支持； 2、

参考文献： http://msdn.microsoft.com/en-us/library/ms187103.aspx 概述 SQL Server 使用日志传送，您可以自动将“主服务器”实例上“主数据库”内的事务日志备份发送到单独“辅助服务器”实例上的一个或多个“辅助数据库”。 事务日志备份分别应用于每个辅助数据库。 可选的第三个服务器实例（称为“监视服务器”）记录备份和还原操作的历史记录及状态，还可以在无法按计划执行这些操作时引发警报。 优点 为单个主数据库以及一个或多个辅助数据库（每个数据库都位于单独的 SQL Server 实例上）提供灾难恢复解决方案。 支持对辅助数据库的受限的只读访问权限（在还原作业之间的间隔期间）。 允许用户将延迟时间定义为：从主服务器备份主数据库日志到辅助服务器必须还原（应用）日志备份之间的时间。 例如，如果主数据库上的数据被意外更改，则较长的延迟会很有用。 如果很快发现意外更改，则通过延迟，您可以在辅助数据库反映此更改之前从其中检索仍未更改的数据。 术语和定义 主服务器 (primary server)：位于生产服务器上的 SQL Server 实例。 主数据库 (primary database)：希望备份到其他服务器的主服务器上的数据库。 通过 SQL Server Management Studio

一、 Derby 数据库介绍 Apache Derby 是一个完美的， 100% Java 编写的内存数据库，属于 Apache 的一个开源项目。并且是一个容易管理的关系数据库管理系统，可以和一些商业产品的特性进行交付。 Apache Derby 是一个与平台无关的数据库引擎，它以 Java 类库的形式对外提供服务。 与其他难以部署的数据库不同， Derby 数据库体积小、安装非常简单，只需要将其 *.jar 文件复制到系统中并为用户的项目添加该 *.jar 文件即可。 另外在 MyEclipse 中集成了 Derby 数据库的插件应用，并且 Derby 还提供了 Eclipse 的插件供开发人员使用。 尽管 Derby 很容易安装，但是它的特性却非常丰富。它可以支持关系数据库中的所有企业级的特性，包括崩溃恢复、事务回滚和提交、行 / 表级锁、视图、主键 / 外键约束、触发器、子查询表达式等。一部分的列表特性使 Derby从其他的 Java 关系数据库管理系统中分离出来，包括： 100% Java 实现 100% Java 类型 4 JDBC 驱动 SQL92E 标准支持大部分 SQL 99 特性 ACID 完全的事务独立的事务支持 J2EE 支持 JNDI ，连接池和 XA 视图，临时表和保存 BLOB 和 CLOB 数据类型 行和表锁定 有价值的基本查询优化 服务器端指示约束

Cache Aside Pattern 最初级的缓存不一致问题及解决方案 比较复杂的数据不一致问题分析 分布式缓存是现在很多分布式应用中必不可少的组件，但是用到了分布式缓存，就可能会涉及到缓存与数据库双存储双写，你只要是双写，就一定会有数据一致性的问题，那么你如何解决一致性问题？ Cache Aside Pattern 最经典的缓存+数据库读写的模式，就是 Cache Aside Pattern。 读的时候，先读缓存，缓存没有的话，就读数据库，然后取出数据后放入缓存，同时返回响应。 更新的时候，先更新数据库，然后再删除缓存。 为什么是删除缓存，而不是更新缓存？ 原因很简单，很多时候，在复杂点的缓存场景，缓存不单单是数据库中直接取出来的值。 比如可能更新了某个表的一个字段，然后其对应的缓存，是需要查询另外两个表的数据并进行运算，才能计算出缓存最新的值的。 另外更新缓存的代价有时候是很高的。是不是说，每次修改数据库的时候，都一定要将其对应的缓存更新一份？ 也许有的场景是这样，但是对于比较复杂的缓存数据计算的场景，就不是这样了。 如果你频繁修改一个缓存涉及的多个表，缓存也频繁更新。但是问题在于，这个缓存到底会不会被频繁访问到？ 举个栗子，一个缓存涉及的表的字段，在 1 分钟内就修改了 20 次，或者是 100 次，那么缓存更新 20 次、100 次；但是这个缓存在 1 分钟内只被读取了

如何为数据库同步筛选数据 了解筛选器 我们知道，在为数据库准备同步时，我们需要定义同步作用域来描述同步的数据范围，它是对进行同步的对象的一种逻辑分组。对于数据库同步，一个同步作用域通常是一组数据表。但有时候，我们希望在同步作用域的基础上对同步的数据进行筛选，比如，按照销售人员同步订单数据。这个时候，我们就可以使用Sync Framework的筛选器机制来对同步数据进行筛选。 Sync Framework 可以创建两种类型的筛选器：“静态筛选器”和“基于参数的筛选器”。 静态筛选器定义为同步作用域的一部分，并且定义筛选字段的值。静态筛选器在源数据库使用的存储过程中进行编码，以便为作用域枚举变更。定义了某一静态筛选器后，就不能对其进行更改。在本篇的设置数据库一节中，我们已经定义了一个静态筛选器的完整示例。 基于参数的筛选器由一个筛选子句以及映射到同步作用域中表的列的一组参数定义。基于参数的筛选器在两个阶段中定义。第一个阶段定义筛选子句和参数，并且建立与该筛选器相关联的作用域的说明。在这个阶段中，筛选器和作用域仅采用模板格式。第二个阶段为筛选器设置参数值并且根据模板创建同步作用域。在此阶段中创建的作用域是目标提供程序用来与源数据库同步的作用域。用于基于参数的筛选的源数据库可以是 SQL Server 或 SQL Azure 数据库，目标数据库可以是 SQL Server、SQL

针对同步进行设置 在可以使用 Sync Framework 同步数据库之前，需要通过称为“设置（provisioning）”的流程配置它。所需的设置类型因数据库类型而异。本篇提供有关设置 SQL Server 和 SQL Server Compact 数据库的背景信息、操作步骤以及完整代码示例。 了解设置和取消设置(Provision and Deprovision) 为同步配置数据库的第一步是定义一个作用域，该作用域标识要同步的内容。在您定义同步作用域后，就可以使用该同步作用域来设置数据库，以便创建变更跟踪和元数据管理基础结构，该基础结构由元数据表、触发器和存储过程构成。在设置了某一数据库后，可以通过使用某一提供程序（例如 SqlSyncProvider）来表示该数据库和使用 SyncOrchestrator 对象管理同步会话并连接到其他同步提供程序以实现数据同步。为同步设置数据库是有别于与其他数据库同步的单独任务，这部分代码通常位于单独的应用程序中。 设置(Provision) 在设置(Provision)数据库时，通常会在数据库中创建以下某些或全部元素： 在同步作用域中包含的基表。 作用域中每个基表的一个跟踪表。该跟踪表跟踪对关联基表进行的变更。 在直接对基表进行更改时更新跟踪表的触发器。 用于同步操作的存储过程，例如枚举变更、插入变更、更新数据或删除数据