关系数据库教程

来自NoSQL Ecosystem选择NoSQL的几种种理由：

越来越多的Web应用程序需要数据存储，传统的关系数据库已经不能完全满足要求。面向对象和面向文档的数据库提供了一个选择，最近这个发展领域的发生很多活动，10月22日柏林举办了一次NoSQL大会：

自从工作后，有机会接触到了高并发，大数据量的系统。最近由于业务量的突增，数据量变的很大，我们的系统是1个主数据库带多个从库。插入和删除都要在主库上进行，而查询的时候则随机使用主库和从库。最近由于数据量的突增，因此主库变成了瓶颈，为了能够支撑系统，只能使用更好的主机。目前进行了测试，虽然更换

最近公司有个新项目，对于负载和并发的要求很高，因此考虑使用key/value store去解决数据持久化的问题，但是在思考过程中碰到一些问题,在这里提出来希望能有高人指点一下1.建模如何做.通常一个实体在应用中有多个地方需要引用，比如，以论坛为例，一个帖子如果存储在用户对象中，那么，各版块引

今天我们迎来了令人激动的NoSQL运动，叫它是NoSQL或者是Not Only SQL,这个运动有一个目标，不是所有应用都是以同样方式存储和处理数据的。 存储也应该被纳入架构考虑（不是一种默认根本不需要讨论的话题），直到今天，我们还总是希望靠一种技术打遍天

在当前NoSQL运动和缓存为王的思想推动下，来自Oracle and

这篇文章讲了伸缩性和可用性方面的反模式，也按照自己的理解翻译了一下，欢迎各位探讨。 1 单点失败（Single Point of Failure） 大部分的人都坚持在单一

说到伸缩性，我们一般都会想到存储的伸缩以及本身应用程序的伸缩，下面这篇文章讲解了对传统的关系数据的伸缩以及如何通过内存数据网格来进行应用程序的伸缩。 首先对于传统的RDBMS的伸缩，大家比较熟悉主要有以下两种方式：

首先想说的是面向过程的的数据流分析方法不是不正确，只是它不符合对象分析方法。两者的出发点是不同的，就象向两个不同方向前进的队伍，是无法调合的。而现在很普遍的所谓面向对象设计时“先建立数据库表，然后将其封装，设计类”则是彻头彻尾的错误! 套上一个面向对象的马甲，干的是完全不面向对象的事情。面向过

现在公司要开发一个web系统，各种原因确定了要用C# .net来开发。早就厌烦了.net基于控件、数据库的设计方式，以后该需求恐怕系统要重做。这次想说运用OO设计思想，尽量解耦合。但是OO思想在.net中实现起来太纠结。例如设计这么一个类：

我们的项目中要用到应用项目跟oracle数据库的中间层，即：不让应用系统直接跟oracle数据库进行交互（用户考虑到安全问题，一直坚持！）。我们的很多软件项目已经成型，属于半产品类型的项目，本来也是考虑应用跟数据库中间加缓存来实现，但是我们的dao底层是jdbc封装，要那么改的话，工作量比较

弱弱的问，CAP为什么不能三者都达到呢？现在的关系型数据库产品不是基本上达到了这三点了吗？

今天无意间看到javaeye.com里的一篇贴子原文:http://www.javaeye.com/topic/556641 引用:作为架构师或者开发人员，面对业务方提出的数据结构变化的需求总是很头痛的，今天让你加个描述字段，明天让你再加个

本身hibernate并不提倡用存储过程 ，它认为存储过程和具体的DBMS有很强的耦合性。但存储过程的确很高效的能处理数据。对于这种情况，大家都是怎么做的。和怎么想的。

我现在有个项目，想把数据全部放在内存中，数据不是很多，一万条以下，所以我想用HSQLDB ，但是当数据有增，删，改的时候怎么持久化啊，是不是还要用一个数据库来专门持久化还是直接持久化到文件中啊， 还有就是HSQLDB 一般都在什么项目中适合啊，我也是刚刚开始关注内存数据库的，请bang

今天遇到一个技术上的问题，还是老的话题。 一个软件设计是围绕数据库的还是领域对象的问题，问题是这样的。有两个系统，分别有两套数据库结构，经理非要将其中一个代码修改一下，将两个数据库结构融合在一起，也就是说原来是两张数据表现在放在一张里，目的是为了将两个系统做一个整合。 我的意