数据库是“按照数据结构来组织、存储和管理数据的仓库”。 是一个长期存储在计算机内的、有组织的、可共享的、统一管理的大量数据的集合。 数据库是以一定方式储存在一起、能与多个用户共享、具有尽可能小的冗余度、与应用程序彼此独立的数据集合， 可视为电子化的文件柜，存储电子文件的处所， 用户可以对文件中的数据进行新增、查询、更新、删除等操作。
数据库类型：
数据库作为存储数据的系统，产生了非常多的类型以应对不同的场景。 从存储的形式来区分，可以分为关系型数据库与非关系型数据库， 非关系型数据库又可以进一步分为文档型数据库、key-value 数据库与图形数据库等。
关系型数据库
关系型数据库非常重要。在上面的分类中， 首先是按“关系型”与“非关系型”进行的区分，“非关系型”中再论其他。
关系型数据库，存储的格式可以直观地反映实体间的关系。 关系型数据库和常见的表格比较相似，关系型数据库中表与表之间是有很多复杂的关联关系的。 常见的关系型数据库有Mysql，SqlServer等。 在轻量或者小型的应用中，使用不同的关系型数据库对系统的性能影响不大， 但是在构建大型应用时，则需要根据应用的业务需求和性能需求， 选择合适的关系型数据库。
标准SQL语句
虽然关系型数据库有很多，但是大多数都遵循SQL（结构化查询语言，Structured Query Language）标准。 常见的操作有查询，新增，更新，删除，求和，排序等。
- 查询语句：
SELECT param FROM table WHERE condition该语句可以理解为从 table 中查询出满足 condition 条件的字段 param。 - 插入语句：
INSERT INTO table (param1，param2，param3) VALUES (value1，value2，value3)该语句可以理解为向table中的param1，param2，param3字段中分别插入value1，value2，value3。 - 更新语句：UPDATE table SET param=new_value WHERE condition 该语句可以理解为将满足condition条件的字段param更新为 new_value 值。
- 删除语句：DELETE FROM table WHERE condition 该语句可以理解为将满足condition条件的数据全部删除。
这儿甚至有单独的词汇 CRUD（Create、Read、Update、Delete ） ，中文一般称为“增、删、改、查”。
对应SQL语言的操作为 SELECT ，INSERT ，UPDATE ，DELETE 语句。
关系型数据库对于结构化数据的处理更合适，如学生成绩、地址等，
这样的数据一般情况下需要使用结构化的查询，例如 join ，
这样的情况下，关系型数据库就会比NoSQL数据库性能更优，而且精确度更高。
由于结构化数据的规模不算太大，数据规模的增长通常也是可预期的，所以针对结构化数据使用关系型数据库更好。
关系型数据库十分注意数据操作的事务性、一致性，如果对这方面的要求关系型数据库无疑可以很好的满足。
非关系型数据库（NoSQL）
随着近些年技术方向的不断拓展， 大量的NoSql数据库如MongoDB、Redis、Memcache出于简化数据库结构、避免冗余、影响性能的表连接、摒弃复杂分布式的目的被设计。 指的是分布式的、非关系型的、不保证遵循ACID原则的数据存储系统。 NoSQL数据库技术与CAP理论、一致性哈希算法有密切关系。 所谓CAP理论，简单来说就是一个分布式系统不可能满足可用性、一致性与分区容错性这三个要求，一次性满足两种要求是该系统的上限。 而一致性哈希算法则指的是NoSQL数据库在应用过程中，为满足工作需求而在通常情况下产生的一种数据算法， 该算法能有效解决工作方面的诸多问题但也存在弊端，即工作完成质量会随着节点的变化而产生波动， 当节点过多时，相关工作结果就无法那么准确。 这一问题使整个系统的工作效率受到影响， 导致整个数据库系统的数据乱码与出错率大大提高， 甚至会出现数据节点的内容迁移，产生错误的代码信息。 尽管如此，NoSQL数据库技术还是具有非常明显的应用优势， 如数据库结构相对简单，在大数据量下的读写性能好 ；能满足随时存储自定义数据格式需求， 非常适用于大数据处理工作。
NoSQL数据库适合追求速度和可扩展性、业务多变的应用场景。 对于非结构化数据的处理更合适，如文章、评论， 这些数据如全文搜索、机器学习通常只用于模糊处理， 并不需要像结构化数据一样，进行精确查询， 而且这类数据的数据规模往往是海量的，数据规模的增长往往也是不可能预期的， 而NoSQL数据库的扩展能力几乎也是无限的， 所以NoSQL数据库可以很好的满足这一类数据的存储。 NoSQL数据库利用key-value可以大量的获取大量的非结构化数据， 并且数据的获取效率很高，但用它查询结构化数据效果就比较差。
目前NoSQL数据库仍然没有一个统一的标准，它现在有四种大的分类：
- 键值对存储（key-value）：代表软件Redis，它的优点能够进行数据的快速查询，而缺点是需要存储数据之间的关系。
- 列存储：代表软件Hbase，它的优点是对数据能快速查询，数据存储的扩展性强。而缺点是数据库的功能有局限性。
- 文档数据库存储：代表软件MongoDB，它的优点是对数据结构要求不特别的严格。而缺点是查询性的性能不好，同时缺少一种统一查询语言。
- 图形数据库存储：代表软件InfoGrid，它的优点可以方便的利用图结构相关算法进行计算。而缺点是要想得到结果必须进行整个图的计算，而且遇到不适合的数据模型时，图形数据库很难使用。
两者区别
存储方式
传统的关系型数据库采用表格的储存方式， 数据以行和列的方式进行存储， 要读取和查询都十分方便。而非关系型数据不适合这样的表格存储方式， 通常以数据集的方式，大量的数据集中存储在一起，类似于键值对、图结构或者文档。 存储结构 关系型数据库按照结构化的方法存储数据， 每个数据表都必须对各个字段定义好（也就是先定义好表的结构）， 再根据表的结构存入数据，这样做的好处就是由于数据的形式和内容在存入数据之前就已经定义好了， 所以整个数据表的可靠性和稳定性都比较高，但带来的问题就是一旦存入数据后， 如果需要修改数据表的结构就会十分困难。而NoSQL数据库由于面对的是大量非结构化的数据的存储， 它采用的是动态结构，对于数据类型和结构的改变非常的适应， 可以根据数据存储的需要灵活的改变数据库的结构。
存储规范
关系型数据库为了避免重复、规范化数据以及充分利用好存储空间， 把数据按照最小关系表的形式进行存储，这样数据管理的就可以变得很清晰、一目了然， 当然这主要是一张数据表的情况。如果是多张表情况就不一样了， 由于数据涉及到多张数据表，数据表之间存在着复杂的关系， 随着数据表数量的增加，数据管理会越来越复杂。 而NoSQL数据库的数据存储方式是用平面数据集的方式集中存放， 虽然会存在数据被重复存储， 从而造成存储空间被浪费的问题（从当前的计算机硬件的发展来看，这样的存储空间浪费的问题微不足道）， 但是由于基本上单个数据库都是采用单独存放的形式， 很少采用分割存放的方式，所以这样数据往往能存成一个整体， 这对于数据的读写提供了极大的方便。
关系型数据库采用结构化查询语言（即SQL）来对数据库进行查询， SQL早已获得了各个数据库厂商的支持，成为数据库行业的标准， 它能够支持数据库的CRUD（增加，查询，更新，删除）操作，具有非常强大的功能， SQL可以采用类似索引的方法来加快查询操作。 NoSQL数据库使用的是非结构化查询语言（UnQL）， 它以数据集（像文档）为单位来管理和操作数据， 由于它没有一个统一的标准，所以每个数据库厂商提供产品标准是不一样的， NoSQL中的文档Id与关系型表中主键的概念类似， NoSQL数据库采用的数据访问模式相对SQL更简单而精确。
规范化
在数据库的设计开发过程中开发人员通常会面对同时需要对一个或者多个数据实体（包括数组、列表和嵌套数据）进行操作， 这样在关系型数据库中，一个数据实体一般首先要分割成多个部分， 然后再对分割的部分进行规范化，规范化以后再分别存入到多张关系型数据表中， 这是一个复杂的过程。好消息是随着软件技术的发展， 相当多的软件开发平台都提供一些简单的解决方法，例如， 可以利用ORM层（也就是对象关系映射）来将数据库中对象模型映射到基于SQL的关系型数据库中去以及进行不同类型系统的数据之间的转换。 对于NoSQL数据库则没有这方面的问题，它不需要规范化数据， 它通常是在一个单独的存储单元中存入一个复杂的数据实体。
事务性
关系型数据库强调ACID规则（原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability））， 可以满足对事务性要求较高或者需要进行复杂数据查询的数据操作， 而且可以充分满足数据库操作的高性能和操作稳定性的要求。 并且关系型数据库十分强调数据的强一致性，对于事务的操作有很好的支持。 关系型数据库可以控制事务原子性细粒度，并且一旦操作有误或者有需要， 可以马上回滚事务。 而NoSQL数据库强调BASE原则（基本可用（Basically Available）、软状态（Soft-state）、最终一致性（Eventual Consistency））， 它减少了对数据的强一致性支持，从而获得了基本一致性和柔性可靠性， 并且利用以上的特性达到了高可靠性和高性能，最终达到了数据的最终一致性。 NoSQL数据库虽然对于事务操作也可以使用，但由于它是一种基于节点的分布式数据库， 对于事务的操作不能很好的支持，也很难满足其全部的需求， 所以NoSQL数据库的性能和优点更多的体现在大数据的处理和数据库的扩展方面。
SQL注入攻击是通过操作输入来修改SQL语句，用以达到执行代码对WEB服务器进行攻击的方法。 简单的说就是在post/getweb表单、输入域名或页面请求的查询字符串中插入SQL命令， 最终使web服务器执行恶意命令的过程。
由此可以在URL中插入恶意的SQL语句并进行执行。另外，在网站开发过程中， 开发人员使用动态字符串构造SQL语句，用来创建所需的应用， 这种情况下SQL语句在程序的执行过程中被动态的构造使用， 可以根据不同的条件产生不同的SQL语句，比如需要根据不同的要求来查询数据库中的字段。 这样的开发过程其实为SQL注入攻击留下了很多的可乘之机。
随着项目越来越大，采用写原生SQL的方式在代码中会出现大量的SQL语句， 那么问题就出现了：
SQL语句重复利用率不高，越复杂的SQL语句条件越多，代码越长。 会出现很多相近的SQL语句。
很多SQL语句是在业务逻辑中拼出来的，如果有数据库需要更改， 就要去修改这些逻辑，这会很容易漏掉对某些SQL语句的修改。
写SQL时容易忽略web安全问题，给未来造成隐患。SQL注入。
ORM ，全称 Object Relational Mapping ，中文叫做对象关系映射， 通过 ORM 可以通过类的方式去操作数据库，而不用再写原生的SQL语句。 通过把表映射成类，把行作实例，把字段作为属性， ORM 在执行对象操作的时候最终还是会把对应的操作转换为数据库原生语句。 使用 ORM 有许多优点：
易用性：使用 ORM 做数据库的开发可以有效的减少重复SQL语句的概率， 写出来的模型也更加直观、清晰。
性能损耗小： ORM 转换成底层数据库操作指令确实会有一些开销。 但从实际的情况来看，这种性能损耗很少（不足5%），只要不是对性能有严苛的要求， 综合考虑开发效率、代码的阅读性，带来的好处要远远大于性能损耗，而且项目越大作用越明显。
设计灵活：可以轻松的写出复杂的查询。
可移植性： Django 封装了底层的数据库实现，支持多个关系数据库引擎， 包括流行的 MySQL 、 PostgreSQL 和 SQLite 。可以非常轻松的切换数据库。
ORM 模型一般都是放在 app 的 models.py 文件中。每个 app 都可以拥有自己的模型。
并且如果这个模型想要映射到数据库中，
那么这个 app 必须要放在 settings.py 的 INSTALLED_APP 中进行安装。
这个模型继承自 django.db.models.Model ，如果这个模型想要映射到数据库中，
就必须继承自这个类。这个模型以后映射到数据库中，表名是模型名称的小写形式，
为 book 。在这个表中，有四个字段，一个为 name ，这个字段是保存的是书的名称，
是 varchar 类型，最长不能超过20个字符，并且不能为空。第二个字段是作者名字类型，
同样也是 varchar 类型，长度不能超过20个。第三个是出版时间，
数据类型是 datetime 类型，默认是保存这本书籍的时间。第五个是这本书的价格，
是浮点类型。还有一个字段就是主键 id ，在 django 中，如果一个模型没有定义主键，
那么将会自动生成一个自动增长的 int 类型的主键，并且这个主键的名字就叫做 id.
ORM模块
SQLObject
SQLObject是一种流行的对象关系管理器，用于为数据库提供对象接口， 其中表为类，行为实例，列为属性。 SQLObject包含一个基于Python对象的查询语言，使SQL更抽象， 并为应用程序提供了大量的数据库独立性。
优点：
- 采用了易懂的ActiveRecord 模式
- 一个相对较小的代码库
缺点：
- 方法和类的命名遵循了Java 的小驼峰风格
- 不支持数据库session隔离工作单元
Storm
Storm 是一个介于 单个或多个数据库与Python之间 映射对象的 Python ORM 。
为了支持动态存储和取回对象信息，它允许开发者构建跨数据表的复杂查询。
Stom中 table class 不需要是框架特定基类 的子类 。
每个table class是 的sqlobject.SQLObject 的子类。
优点：
- 清爽轻量的API，短学习曲线和长期可维护性
- 不需要特殊的类构造函数，也没有必要的基类
缺点：
- 迫使程序员手工写表格创建的DDL语句，而不是从模型类自动派生
- Storm的贡献者必须把他们的贡献的版权给Canonical公司
Django's ORM
因为Django的ORM 是紧嵌到web框架的， 所以也不推荐在一个独立的非Django的Python项目中使用它的ORM。 Django，一个最流行的Python web框架， 有它独有的 ORM。 相比 SQLAlchemy， Django 的 ORM 更吻合于直接操作SQL对象， 操作暴露了简单直接映射数据表和Python类的SQL对象 。
优点：
- 易用，学习曲线短
- 和Django紧密集合，用Django时使用约定俗成的方法去操作数据库
缺点：
- 不好处理复杂的查询，强制开发者回到原生SQL
- 紧密和Django集成，使得在Django环境外很难使用
peewee：
优点：
- Django式的API，使其易用
- 轻量实现，很容易和任意web框架集成
缺点：
- 不支持自动化 schema 迁移
- 多对多查询写起来不直观
相比其他的ORM， SQLAlchemy 意味着，无论何时写SQLAlchemy代码， 都专注于工作单元的前沿概念 。DB Session 的概念可能最初很难理解和正确使用， 但是后来会欣赏这额外的复杂性，这让意外的时序提交相关的数据库bug减少到0。 在SQLAlchemy中处理多数据库是棘手的， 因为每个DB session 都限定了一个数据库连接。 但是，这种类型的限制实际上是好事， 因为这样强制绞尽脑汁去想在多个数据库之间的交互， 从而使得数据库交互代码很容易调试。