数据库常见场景有哪些，BS的典型应用场景有哪些非常急

本文目录一览

1，BS的典型应用场景有哪些非常急
2，开发数据库和测试数据库的不同使用场景
3，常见NoSQL数据库的应用场景是怎么样的
4，Java工程师进入互联网公司需要学习什么技术
5，数据库事务原子性一致性是怎样实现的

1，BS的典型应用场景有哪些非常急

在对数据库的应用上，C/S是将应用逻辑放在客户端，数据库放在SERVER端，而B/S全放在SERVER端，并且通过Browser即浏览器来作为UI的载体。傻蛋！！！

java

BS的典型应用场景有哪些非常急

2，开发数据库和测试数据库的不同使用场景

开发数据库，主要用来写代码的，测试数据库，应该是把在开发数据库写好的代码放到测试数据库，然后把测试数据导入到测试数据库进行测试。

主键与索引的区别如下：主键是一种约束，唯一索引是一种索引，两者在本质上是不同的。主键创建后一定包含一个唯一性索引，唯一性索引并不一定就是主键。唯一性索引列允许空值，而主键列不允许为空值。主键列在创建时，已经默认不为空值 + 唯一索引了。主键可以被其他表引用为外键，而唯一索引不能。一个表最多只能创建一个主键，但可以创建多个唯一索引。主键更适合那些不容易更改的唯一标识，如自动递增列、身份证号等。建立索引常用的规则如下： 1、表的主键、外键必须有索引；2、数据量超过300的表应该有索引；3、经常与其他表进行连接的表，在连接字段上应该建立索引；4、经常出现在where子句中的字段，特别是大表的字段，应该建立索引；5、索引应该建在选择性高的字段上；6、索引应该建在小字段上，对于大的文本字段甚至超长字段，不要建索引；7、复合索引的建立需要进行仔细分析；尽量考虑用单字段索引代替：8、频繁进行数据操作的表，不要建立太多的索引；9、删除无用的索引，避免对执行计划造成负面影响；

开发数据库和测试数据库的不同使用场景

3，常见NoSQL数据库的应用场景是怎么样的

文档数据库　　源起：受Lotus Notes启发。　　数据模型：包含了key-value的文档集合　　例子：CouchDB, MongoDB 　　优点：数据模型自然，编程友好，快速开发，web友好，CRUD。　　图数据库　　源起：欧拉和图理论。　　数据模型：节点和关系，也可处理键值对。　　例子：AllegroGraph, InfoGrid, Neo4j 　　优点：解决复杂的图问题。　　关系数据库　　源起： E. F. Codd 在A Relational Model of Data for Large Shared Data Banks提出的　　数据模型：各种关系　　例子：VoltDB, Clustrix, MySQL 　　优点：高性能、可扩展的OLTP，支持SQL，物化视图，支持事务，编程友好。　　对象数据库　　源起：图数据库研究　　数据模型：对象　　例子：Objectivity, Gemstone 　　优点：复杂对象模型，快速键值访问，键功能访问，以及图数据库的优点。　　Key-Value数据库　　源起：Amazon的论文 Dynamo 和 Distributed HashTables。　　数据模型：键值对　　例子：Membase, Riak 　　优点：处理大量数据，快速处理大量读写请求。编程友好。　　BigTable类型数据库　　源起：Google的论文 BigTable。　　数据模型：列簇，每一行在理论上都是不同的　　例子：HBase, Hypertable, Cassandra 　　优点：处理大量数据，应对极高写负载，高可用，支持跨数据中心， MapReduce。　　数据结构服务　　源起： ? 　　数据模型：字典操作，lists, sets和字符串值　　例子：Redis 　　优点：不同于以前的任何数据库　　网格数据库　　源起：数据网格和元组空间研究。　　数据模型：基于空间的架构　　例子：GigaSpaces, Coherence 　　优点：适于事务处理的高性能和高扩展性

搜一下：常见NoSQL数据库的应用场景是怎么样的

常见NoSQL数据库的应用场景是怎么样的

4，Java工程师进入互联网公司需要学习什么技术

1.Core Java，就是Java基础、JDK的类库，很多童鞋都会说，JDK我懂，但是懂还不足够，知其然还要知其所以然，JDK的源代码写的非常好，要经常查看，对使用频繁的类，比如String，集合类（List，Map，Set）等数据结构要知道它们的实现，不同的集合类有什么区别，然后才能知道在一个具体的场合下使用哪个集合类更适合、更高效，这些内容直接看源代码就OK了2.多线程并发编程，现在并发几乎是写服务端程序必须的技术，那对Java中的多线程就要有足够的熟悉，包括对象锁机制、synchronized关键字，concurrent包都要非常熟悉，这部分推荐你看看《Java并发编程实践》这本书，讲解的很详细3.I/O，Socket编程，首先要熟悉Java中Socket编程，以及I/O包，再深入下去就是Java NIO,再深入下去是操作系统底层的Socket实现,了解Windows和Linux中是怎么实现socket的4.JVM的一些知识，不需要熟悉，但是需要了解，这是Java的本质，可以说是Java的母体, 了解之后眼界会更宽阔，比如Java内存模型（会对理解Java锁、多线程有帮助）、字节码、JVM的模型、各种垃圾收集器以及选择、JVM的执行参数（优化JVM）等等,这些知识在《深入Java虚拟机》这本书中都有详尽的解释,或者去oracle网站上查看具体版本的JVM规范.5.一些常用的设计模式，比如单例、模板方法、代理、适配器等等，以及在Core Java和一些Java框架里的具体场景的实现，这个可能需要慢慢积累，先了解有哪些使用场景，见得多了，自己就自然而然会去用。6.常用数据库（Oracle、MySQL等）、SQL语句以及一般的优化7.JavaWeb开发的框架，比如Spring、iBatis等框架，同样他们的原理才是最重要的，至少要知道他们的大致原理。8.其他一些有名的用的比较多的开源框架和包，Netty网络框架，Apache common的N多包，Google的Guava等等，也可以经常去Github上找一些代码看看。暂时想到的就这么多吧，1-4条是Java基础，全部的这些知识没有一定的时间积累是很难搞懂的，但是了解了之后会对Java有个彻底的了解，5和6是需要学习的额外技术，7-8是都是基于1-4条的，正所谓万变不离其宗，前4条就是Java的灵魂所在，希望能对你有所帮助9.（补充）学会使用Git。如果你还在用SVN的话，赶紧投入Git的怀抱吧

1.core java，就是java基础、jdk的类库，很多童鞋都会说，jdk我懂，但是懂还不足够，知其然还要知其所以然，jdk的源代码写的非常好，要经常查看，对使用频繁的类，比如string，集合类（list，map，set）等数据结构要知道它们的实现，不同的集合类有什么区别，然后才能知道在一个具体的场合下使用哪个集合类更适合、更高效，这些内容直接看源代码就ok了2.多线程并发编程，现在并发几乎是写服务端程序必须的技术，那对java中的多线程就要有足够的熟悉，包括对象锁机制、synchronized关键字，concurrent包都要非常熟悉，这部分推荐你看看《java并发编程实践》这本书，讲解的很详细3.i/o，socket编程，首先要熟悉java中socket编程，以及i/o包，再深入下去就是java nio,再深入下去是操作系统底层的socket实现,了解windows和linux中是怎么实现socket的4.jvm的一些知识，不需要熟悉，但是需要了解，这是java的本质，可以说是java的母体, 了解之后眼界会更宽阔，比如java内存模型（会对理解java锁、多线程有帮助）、字节码、jvm的模型、各种垃圾收集器以及选择、jvm的执行参数（优化jvm）等等,这些知识在《深入java虚拟机》这本书中都有详尽的解释,或者去oracle网站上查看具体版本的jvm规范.5.一些常用的设计模式，比如单例、模板方法、代理、适配器等等，以及在core java和一些java框架里的具体场景的实现，这个可能需要慢慢积累，先了解有哪些使用场景，见得多了，自己就自然而然会去用。6.常用数据库（oracle、mysql等）、sql语句以及一般的优化7.javaweb开发的框架，比如spring、ibatis等框架，同样他们的原理才是最重要的，至少要知道他们的大致原理。8.其他一些有名的用的比较多的开源框架和包，netty网络框架，apache common的n多包，google的guava等等，也可以经常去github上找一些代码看看。

5，数据库事务原子性一致性是怎样实现的

这个问题的有趣之处，不在于问题本身（“原子性、一致性的实现机制是什么”），而在于回答者的分歧反映出来的另外一个问题：原子性和一致性之间的关系是什么？我特别关注了@我练功发自真心的答案，他正确地指出了，为了保证事务操作的原子性，必须实现基于日志的REDO/UNDO机制。但这个答案仍然是不完整的，因为原子性并不能够完全保证一致性。按照我个人的理解，在事务处理的ACID属性中，一致性是最基本的属性，其它的三个属性都为了保证一致性而存在的。首先回顾一下一致性的定义。所谓一致性，指的是数据处于一种有意义的状态，这种状态是语义上的而不是语法上的。最常见的例子是转帐。例如从帐户A转一笔钱到帐户B上，如果帐户A上的钱减少了，而帐户B上的钱却没有增加，那么我们认为此时数据处于不一致的状态。在数据库实现的场景中，一致性可以分为数据库外部的一致性和数据库内部的一致性。前者由外部应用的编码来保证，即某个应用在执行转帐的数据库操作时，必须在同一个事务内部调用对帐户A和帐户B的操作。如果在这个层次出现错误，这不是数据库本身能够解决的，也不属于我们需要讨论的范围。后者由数据库来保证，即在同一个事务内部的一组操作必须全部执行成功（或者全部失败）。这就是事务处理的原子性。为了实现原子性，需要通过日志：将所有对数据的更新操作都写入日志，如果一个事务中的一部分操作已经成功，但以后的操作，由于断电/系统崩溃/其它的软硬件错误而无法继续，则通过回溯日志，将已经执行成功的操作撤销，从而达到“全部操作失败”的目的。最常见的场景是，数据库系统崩溃后重启，此时数据库处于不一致的状态，必须先执行一个crashrecovery的过程：读取日志进行REDO（重演将所有已经执行成功但尚未写入到磁盘的操作，保证持久性），再对所有到崩溃时尚未成功提交的事务进行UNDO（撤销所有执行了一部分但尚未提交的操作，保证原子性）。crashrecovery结束后，数据库恢复到一致性状态，可以继续被使用。日志的管理和重演是数据库实现中最复杂的部分之一。如果涉及到并行处理和分布式系统（日志的复制和重演是数据库高可用性的基础），会比上述场景还要复杂得多。但是，原子性并不能完全保证一致性。在多个事务并行进行的情况下，即使保证了每一个事务的原子性，仍然可能导致数据不一致的结果。例如，事务1需要将100元转入帐号A：先读取帐号A的值，然后在这个值上加上100。但是，在这两个操作之间，另一个事务2修改了帐号A的值，为它增加了100元。那么最后的结果应该是A增加了200元。但事实上，事务1最终完成后，帐号A只增加了100元，因为事务2的修改结果被事务1覆盖掉了。为了保证并发情况下的一致性，引入了隔离性，即保证每一个事务能够看到的数据总是一致的，就好象其它并发事务并不存在一样。用术语来说，就是多个事务并发执行后的状态，和它们串行执行后的状态是等价的。怎样实现隔离性，已经有很多人回答过了，原则上无非是两种类型的锁：一种是悲观锁，即当前事务将所有涉及操作的对象加锁，操作完成后释放给其它对象使用。为了尽可能提高性能，发明了各种粒度（数据库级/表级/行级……）/各种性质（共享锁/排他锁/共享意向锁/排他意向锁/共享排他意向锁……）的锁。为了解决死锁问题，又发明了两阶段锁协议/死锁检测等一系列的技术。一种是乐观锁，即不同的事务可以同时看到同一对象（一般是数据行）的不同历史版本。如果有两个事务同时修改了同一数据行，那么在较晚的事务提交时进行冲突检测。实现也有两种，一种是通过日志UNDO的方式来获取数据行的历史版本，一种是简单地在内存中保存同一数据行的多个历史版本，通过时间戳来区分。锁也是数据库实现中最复杂的部分之一。同样，如果涉及到分布式系统（分布式锁和两阶段提交是分布式事务的基础），会比上述场景还要复杂得多。@我练功发自真心提到，其他回答者说的其实是操作系统对atomic的理解，即并发控制。我不能完全同意这一点。数据库有自己的并发控制和锁问题，虽然在原理上和操作系统中的概念非常类似，但是并不是同一个层次上的东西。数据库中的锁，在粒度/类型/实现方式上和操作系统中的锁都完全不同。操作系统中的锁，在数据库实现中称为latch（一般译为闩）。其他回答者回答的其实是“在并行事务处理的情况下怎样保证数据的一致性”。最后回到原来的问题（“原子性、一致性的实现机制是什么”）。我手头有本DatabaseSystemConcepts（4ed，有点老了），在第15章的开头简明地介绍了ACID的概念及其关系。如果你想从概念上了解其实现，把这本书的相关章节读完应该能大概明白。如果你想从实践上了解其实现，可以找innodb这样的开源引擎的源代码来读。不过，即使是一个非常粗糙的开源实现（不考虑太复杂的并行处理，不考虑分布式系统，不考虑针对操作系统和硬件的优化之类），要基本搞明白恐怕也不是一两年的事。

文章TAG：数据数据库常见场景数据库常见场景有哪些