mongoDB 删除数据库

语法

MongoDB 删除数据库的语法格式如下：

db.dropDatabase()

删除当前数据库，默认为 test，你可以使用 db 命令查看当前数据库名。

实例

以下实例我们删除了数据库 runoob。

首先，查看所有数据库：

> show dbsadmin0.000GBconfig0.000GBlocal0.000GBrunoob0.000GB

接下来我们切换到数据库 runoob：

> use runoobswitched to db runoob>

执行删除命令：

> db.dropDatabase(){ "dropped" : "runoob", "ok" : 1 }

最后，我们再通过 show dbs 命令数据库是否删除成功：

> show dbsadmin0.000GBconfig0.000GBlocal0.000GB

删除集合

集合删除语法格式如下：

db.collection.drop()

以下实例删除了 runoob 数据库中的集合 site：

> use runoobswitched to db runoob> db.createCollection("runoob")# 先创建集合，类似数据库中的表> show tables# show collections 命令会更加准确点runoob> db.runoob.drop()true> show tables>

如何在java中使用mongodb

首先你需要安装mongodb的JDBC驱动，比如。 然后把这个jar包引用到你的程序中。 import ;import ;public class MongoDBJDBC{public static void main( String args[] ){try{// 连接到 mongodb 服务MongoClient mongoClient = new MongoClient( localhost , );// 连接到数据库MongoDatabase mongoDatabase = (mycol);(Connect to database successfully);}catch(Exception e){( ()() + : + () );}}}

请问哪里可以下载到MongoDB应用实战视频教程？最近在学这个，苦于没有资料

我这里有一套22讲的相关教程，名为《深入浅出MongoDB应用实战开发(基础、开发指南、系统管理、集群及系统架构），本课程侧重于讲解MongoDB的常用特性及高级特性，从实际开发的角度出发对MongoDB进行全方位深入剖析，学员从中可领会到MongoDB设计的精妙之处，体会到MongoDB强大的类SQL查询语言，感受到MongoDB与其它Nosql数据库的异同之处。你需要的话我可以发给你

如何正确的使用MongoDB并优化其性能

e799bee5baa6e79fa5ee4b893e5b19e136数据库性能对软件整体性能的影响是不言而喻的，那么，当我们使用MongoDB时改如何提高数据库性能呢？1.范式化与反范式化在项目设计阶段，明确集合的用途是对性能调优非常重要的一步。 从性能优化的角度来看，集合的设计我们需要考虑的是集合中数据的常用操作，例如我们需要设计一个日志（log）集合，日志的查看频率不高，但写入频率却很高，那么我们就可以得到这个集合中常用的操作是更新（增删改）。 如果我们要保存的是城市列表呢？显而易见，这个集合是一个查看频率很高，但写入频率很低的集合，那么常用的操作就是查询。 对于频繁更新和频繁查询的集合，我们最需要关注的重点是他们的范式化程度，在上篇范式化与反范式化的介绍中我们了解到，范式化与反范式化的合理运用对于性能的提高至关重要。 然而这种设计的使用非常灵活，假设现在我们需要存储一篇图书及其作者，在MongoDB中的关联就可以体现为以下几种形式：1.完全分离（范式化设计）示例1：View Code{ _id : ObjectId(5124b5dc7dca), title : 如何使用MongoDB, author : [ ObjectId(144b5dc7dca),ObjectId(144b5dc7dca),ObjectId(144b5dc7dca), ] }我们将作者(comment) 的id数组作为一个字段添加到了图书中去。 这样的设计方式是在非关系型数据库中常用的，也就是我们所说的范式化设计。 在MongoDB中我们将与主键没有直接关系的图书单独提取到另一个集合，用存储主键的方式进行关联查询。 当我们要查询文章和评论时需要先查询到所需的文章，再从文章中获取评论id，最后用获得的完整的文章及其评论。 在这种情况下查询性能显然是不理想的。 但当某位作者的信息需要修改时，范式化的维护优势就凸显出来了，我们无需考虑此作者关联的图书，直接进行修改此作者的字段即可。 2.完全内嵌（反范式化设计）示例2：View Code{ _id : ObjectId(5124b5dc7dca), title : 如何使用MongoDB, author : [{ name : 丁磊 age : 40,　nationality : china,},{ name : 马云 age : 49, nationality : china,},{ name : 张召忠 age : 59, nationality : china,},]} 在这个示例中我们将作者的字段完全嵌入到了图书中去，在查询的时候直接查询图书即可获得所对应作者的全部信息，但因一个作者可能有多本著作，当修改某位作者的信息时时，我们需要遍历所有图书以找到该作者，将其修改。 3.部分内嵌（折中方案）示例3：View Code{ _id : ObjectId(5124b5dc7dca), title : 如何使用MongoDB, author : [ {　_id : ObjectId(144b5dc7dca), name : 丁磊},{ _id : ObjectId(144b5dc7dca), name : 马云},{ _id : ObjectId(144b5dc7dca), name : 张召忠},]}这次我们将作者字段中的最常用的一部分提取出来。 当我们只需要获得图书和作者名时，无需再次进入作者集合进行查询，仅在图书集合查询即可获得。 这种方式是一种相对折中的方式，既保证了查询效率，也保证的更新效率。 但这样的方式显然要比前两种较难以掌握，难点在于需要与实际业务进行结合来寻找合适的提取字段。 如同示例3所述，名字显然不是一个经常修改的字段，这样的字段如果提取出来是没问题的，但如果提取出来的字段是一个经常修改的字段（比如age）的话，我们依旧在更新这个字段时需要大范围的寻找并依此进行更新。 在上面三个示例中，第一个示例的更新效率是最高的，但查询效率是最低的，而第二个示例的查询效率最高，但更新效率最低。 所以在实际的工作中我们需要根据自己实际的需要来设计表中的字段，以获得最高的效率。