python如何断言数据库数据

Ⅰ python如何访问数据库

1.背景：

python提供了很多数据库接口， 常用的数据库有 MS SQL Server /mysql /oracle 等。

打开链接 https://wiki.python.org/moin/DatabaseInterfaces

是python 关于数据库接口的一个总结 ， 可以看到python支持的访问的数据库系统。

2.模块：

python 主要是通过模块和数据库连接的。

2.1 安装模块：

如果使用anconda，本身就会集合很多模块，不需要手动安装。如果用pycharm就要手动安装模块。

安装模块流程：

下载模块扩展包放到路径下——>cmd找到相应路径——> pip install +扩展包名字

下面列举一些常用连接数据库的模块：pymssql / sqlite3/ PyMySQL/pyodbc/odbc/adodbapi

不同模块连接的数据库不同， 支持的版本系统有的也不一样。但是大体用法都是相近的， 因为有DB-API

相关推荐：《Python教程》

3.Python DB-API

3.1背景：

在没有DB-API 之前， 不同数据库有不同的数据库接口程序， 这就导致python 访问 database 的接口程序非常混乱。如果我们学习了python 访问 mysql 的接口程序， 然后要切换到另一个数据库上， 我们还要在学习另外一个数据库的接口程序。python DB-API就是为了解决接口程序混乱而生成的。有了DB-API, 在不同数据库上移植代码就变得简单的多了。

3.2Python DB-API：

Python 定义了一套操作数据库的 DB-API 接口，它是一个规范，定义了一系列必须的对象和数据库存取方式，以便为不同的底层数据库系统提供一致的访问接口

这个链接就是python 官方给定的 DB-API 的说明 https://www.python.org/dev/peps/pep-0249/

3.3 Python DB--API的内容：

连接对象：

?Connect()创建连接:host/server /user/password/db connect方法生成一个connect对象, 我们通过这个对象来访问数据库。符合标准的模块都会实现connect方法。

?close():关闭连接

?commit():提交当前事务。做出某些更改后确保已经进行了提交，这样才可以将这些修改真正地保存到database中

?rollback() 回滚上一次调用 commit（）以来对数据库所做的更改

?cursor():创建游标。系统为用户开通的一个数据缓冲区，用于存放SQL语句执行结果。cursor游标是有状态的，它可以记录当前已经取到结果的第几个记录了，因此，一般你只可以遍历结果集一次。在上面的情况下，如果执行fetchone()会返回为空。这一点在测试时需要注意

游标对象：

?Execute()执行一个数据库查询或命令。 execute 执行sql 语句之后运行的结果不会直接output 出来 ， 而是放到了一个缓存区， 要用 fetch语句+print 可以查询sql运行的结果

?fetchone ()得到结果集的下一行

?fetchmany(size)得到结果集的下几行

?fetchall()返回结果集中剩下的所有行

?rowcount 返回影响的行数

?Close()关闭游标对象

3.4Python DB--API的工作原理及流程：

如图所示如果把python 和数据库比作两个不同的地点， connection 就是路， 能连接python和database。cursor就像在路上行驶的小货车， 可以用于执行sql 语句， 以及存储sql 运行的结果。

流程：

4.MS SQL Server 示例：

4.1 导入模块、创建连接：

4.2 创建游标： 游标创建之后就可以对数据库进行查询更改了！

4.3对数据进行操作（创建表、插入行、更新数据、增加列、删除行、列、表）：

4.4 查询 获取行：

5.其他：

使用游标的时候要注意， 每次连接只能有一个游标查询处于活跃状态。 code演示：

execute()循环和 executemany() 插入100000 条数据测速：

Ⅱ Python中何时使用断言

这个问题是如何在一些场景下使用断言表达式，通常会有人误用它，所以我决定写一篇文章来说明何时使用断言，什么时候不用。

为那些还不清楚它的人，Python的assert是用来检查一个条件，如果它为真，就不做任何事。如果它为假，则会抛出AssertError并且包含错误信息。例如：

py> x = 23
py> assert x > 0, "x is not zero or negative"
py> assert x%2 == 0, "x is not an even number"
Traceback (most recent call last):
File "", line 1, in
AssertionError: x is not an even number

很多人用assert作为一个很快和容易的方法来在参数错误的时候抛出异常。但这样做是错的，非常错误，有两个原因。首先AssertError不是在测试参数时应该抛出的错误。你不应该像这样写代码：

if not isinstance(x, int):
raise AssertionError("not an int")

你应该抛出TypeError的错误，assert会抛出错误的异常。

但是，更危险的是，有一个关于assert的困扰：它可以被编译好然后从来不执行，如果你用 –O 或 –oo
选项运行Python，结果不保证assert表达式会运行到。当适当的使用assert时，这是未来，但是当assert不恰当的使用时，它会让代码用
-O执行时出错。

那什么时候应该使用assert？没有特定的规则，断言应该用于：

防御型的编程
运行时检查程序逻辑
检查约定
程序常量
检查文档

（在测试代码的时候使用断言也是可接受的，是一种很方便的单元测试方法，你接受这些测试在用-O标志运行时不会做任何事。我有时在代码里使用
assert False来标记没有写完的代码分支，我希望这些代码运行失败。尽管抛出NotImplementedError可能会更好。）

关于断言的意见有很多，因为它能确保代码的正确性。如果你确定代码是正确的，那么就没有用断言的必要了，因为他们从来不会运行失败，你可以直接移除这些断言。如果你确定检查会失败，那么如果你不用断言，代码就会通过编译并忽略你的检查。

在以上两种情况下会很有意思，当你比较肯定代码但是不是绝对肯定时。可能你会错过一些非常古怪的情况。在这个情况下，额外的运行时检查能帮你确保任何错误都会尽早地被捕捉到。

另一个好的使用断言的方式是检查程序的不变量。一个不变量是一些你需要依赖它为真的情况，除非一个bug导致它为假。如果有bug，最好能够尽早发现，所以我们为它进行一个测试，但是又不想减慢代码运行速度。所以就用断言，因为它能在开发时打开，在产品阶段关闭。

一个非变量的例子可能是，如果你的函数希望在它开始时有数据库的连接，并且承诺在它返回的时候仍然保持连接，这就是函数的不变量：

Python

def some_function(arg):
assert not DB.closed()
... # code goes here
assert not DB.closed()
return result

断言本身就是很好的注释，胜过你直接写注释：

# when we reach here, we know that n > 2

你可以通过添加断言来确保它：

assert n > 2

断言也是一种防御型编程。你不是让你的代码防御现在的错误，而是防止在代码修改后引发的错误。理想情况下，单元测试可以完成这样的工作，可是需要面
对的现实是，它们通常是没有完成的。人们可能在提交代码前会忘了运行测试代码。有一个内部检查是另一个阻挡错误的防线，尤其是那些不明显的错误，却导致了
代码出问题并且返回错误的结果。

加入你有一些if…elif 的语句块，你知道在这之前一些需要有一些值：

# target is expected to be one of x, y, or z, and nothing else.
if target == x:
run_x_code()
elif target == y:
run_y_code()
else:
run_z_code()

假设代码现在是完全正确的。但它会一直是正确的吗？依赖的修改，代码的修改。如果依赖修改成 target = w
会发生什么，会关系到run_w_code函数吗？如果我们改变了代码，但没有修改这里的代码，可能会导致错误的调用 run_z_code
函数并引发错误。用防御型的方法来写代码会很好，它能让代码运行正确，或者立马执行错误，即使你在未来对它进行了修改。

在代码开头的注释很好的一步，但是人们经常懒得读或者更新注释。一旦发生这种情况，注释会变得没用。但有了断言，我可以同时对代码块的假设书写文档，并且在它们违反的时候触发一个干净的错误

assert target in (x, y, z)
if target == x:
run_x_code()
elif target == y:
run_y_code()
else:
assert target == z
run_z_code()

这样，断言是一种防御型编程，同时也是一种文档。我想到一个更好的方案：

if target == x:
run_x_code()
elif target == y:
run_y_code()
elif target == z:
run_z_code()
else:
# This can never happen. But just in case it does...
raise RuntimeError("an unexpected error occurred")

按约定进行设计是断言的另一个好的用途。我们想象函数与调用者之间有个约定，比如下面的：

“如果你传给我一个非空字符串，我保证传会字符串的第一个字母并将其大写。”

如果约定被函数或调用这破坏，代码就会出问题。我们说函数有一些前置条件和后置条件，所以函数就会这么写：

def first_upper(astring):
assert isinstance(astring, str) and len(astring) > 0
result = astring[0].upper()
assert isinstance(result, str) and len(result) == 1
assert result == result.upper()
return result

按约定设计的目标是为了正确的编程，前置条件和后置条件是需要保持的。这是断言的典型应用场景，因为一旦我们发布了没有问题的代码到产品中，程序会是正确的，并且我们能安全的移除检查。

下面是建议的不要用断言的场景：

不要用它测试用户提供的数据
不要用断言来检查你觉得在你的程序的常规使用时会出错的地方。断言是用来检查非常罕见的问题。你的用户不应该看到任何断言错误，如果他们看到了，这是一个bug，修复它。
有的情况下，不用断言是因为它比精确的检查要短，它不应该是懒码农的偷懒方式。
不要用它来检查对公共库的输入参数，因为它不能控制调用者，所以不能保证调用者会不会打破双方的约定。
不要为你觉得可以恢复的错误用断言。换句话说，不用改在产品代码里捕捉到断言错误。
不要用太多断言以至于让代码很晦涩。

Ⅲ 怎么写python查找数据库是否有相同数据的判断

#!/usr/bin/env python import sys str = True while (str): dig = int(input()) if dig 100: print 'please input mun between 0~100' elif dig = 90: print 'A' elif dig = 80: print 'B' elif dig = 70: print 'C' elif dig = 60: prin...

Ⅳ python如果列表中元素少了，如何和数据库中数据做对比去判断，然后删除实际列表中少了的那条数据

首先，不要使用保留字作为变量名：list

# 迭代出所有不包含在list中的项：

for key in filter(labmda _:_ not in list, dbdata):

....delrecord(key) # 删除操作

Ⅳ Python 3.6发起post请求，对返回的数据进行断言

不需要。返回数据是因为交互需要牵手。了解状态，如果ajax后您的回调不需要数据的话，就不用等他返回数据，api返回空就行了

Ⅵ 如何使用python对数据库进行操作

你可以访问Python数据库接口及API查看详细的支持数据库列表。不同的数据库你需要下载不同的DB API模块，例如你需要访问Oracle数据库和Mysql数据，你需要下载Oracle和MySQL数据库模块。
DB-API 是一个规范. 它定义了一系列必须的对象和数据库存取方式, 以便为各种各样的底层数据库系统和多种多样的数据库接口程序提供一致的访问接口 。
Python的DB-API，为大多数的数据库实现了接口，使用它连接各数据库后，就可以用相同的方式操作各数据库。
Python DB-API使用流程：

引入 API 模块。
获取与数据库的连接。
执行SQL语句和存储过程。
关闭数据库连接。

什么是MySQLdb?

MySQLdb 是用于Python链接Mysql数据库的接口，它实现了 Python 数据库 API 规范 V2.0，基于 MySQL C API 上建立的。

如何安装MySQLdb?

为了用DB-API编写MySQL脚本，必须确保已经安装了MySQL。复制以下代码，并执行：
#!/usr/bin/python
# -*- coding: UTF-8 -*-

import MySQLdb

如果执行后的输出结果如下所示，意味着你没有安装 MySQLdb 模块：
Traceback (most recent call last):
File "test.py", line 3, in <mole>
import MySQLdb
ImportError: No mole named MySQLdb

Ⅶ python 操作查询mysql数据库 如何判断返回是否为空值

通常我先检查 cam_row是否为空，然后再检查它的长度，如果长度与你预期的长度1不相符也不对。

加一句 if not cam_row:continue就可以了

Ⅷ 用python怎么实现数据库资源的权限控制

若一个规则的断言返回 False, 权限检查时视为这条规则不存在.
"""
#: 对资源标识不属于 blog-post 的, 断言无效
if not isinstance(res, basestring):
return False
#: 分割形如 "blog-post:10001" 的资源标识
splited = res.split(":", 1)
#: 对资源标识不属于 blog-post 的, 断言无效
if len(splited) != 2 or splited[0] != "blog-post":
return False
#: 取出资源对应的模型
blog_post = myapp.get_blog_post_by_id(splited[1])
#: 断言是否生效取决于博文的作者是否是当前用户
return blog_post.author == myapp.get_current_user()

Ⅸ Python中何时使用断言 assert

使用断言表达式，通常会有人误用它，所以我决定写一篇文章来说明何时使用断言，什么时候不用。为那些还不清楚它的人，Python的assert是用来检查一个条件，如果它为真，就不做任何事。如果它为假，则会抛出AssertError并且包含错误信息。例如：py>x=23py>assertx>0,"xisnotzeroornegative"py>assertx%2==0,"xisnotanevennumber"Traceback(mostrecentcalllast):File"",line1,inAssertionError:xisnotanevennumber很多人用assert作为一个很快和容易的方法来在参数错误的时候抛出异常。但这样做是错的，非常错误，有两个原因。首先AssertError不是在测试参数时应该抛出的错误。你不应该像这样写代码：ifnotisinstance(x,int):raiseAssertionError("notanint")你应该抛出TypeError的错误，assert会抛出错误的异常。但是，更危险的是，有一个关于assert的困扰：它可以被编译好然后从来不执行，如果你用–O或–oo选项运行Python，结果不保证assert表达式会运行到。当适当的使用assert时，这是未来，但是当assert不恰当的使用时，它会让代码用-O执行时出错。那什么时候应该使用assert？没有特定的规则，断言应该用于：防御型的编程运行时检查程序逻辑检查约定程序常量检查文档（在测试代码的时候使用断言也是可接受的，是一种很方便的单元测试方法，你接受这些测试在用-O标志运行时不会做任何事。我有时在代码里使用assertFalse来标记没有写完的代码分支，我希望这些代码运行失败。尽管抛出NotImplementedError可能会更好。）关于断言的意见有很多，因为它能确保代码的正确性。如果你确定代码是正确的，那么就没有用断言的必要了，因为他们从来不会运行失败，你可以直接移除这些断言。如果你确定检查会失败，那么如果你不用断言，代码就会通过编译并忽略你的检查。在以上两种情况下会很有意思，当你比较肯定代码但是不是绝对肯定时。可能你会错过一些非常古怪的情况。在这个情况下，额外的运行时检查能帮你确保任何错误都会尽早地被捕捉到。另一个好的使用断言的方式是检查程序的不变量。一个不变量是一些你需要依赖它为真的情况，除非一个bug导致它为假。如果有bug，最好能够尽早发现，所以我们为它进行一个测试，但是又不想减慢代码运行速度。所以就用断言，因为它能在开发时打开，在产品阶段关闭。一个非变量的例子可能是，如果你的函数希望在它开始时有数据库的连接，并且承诺在它返回的时候仍然保持连接，这就是函数的不变量：defsome_function(arg):assertnotDB.closed()#codegoeshereassertnotDB.closed()returnresult断言本身就是很好的注释，胜过你直接写注释：#whenwereachhere,weknowthatn>2你可以通过添加断言来确保它：assertn>2断言也是一种防御型编程。你不是让你的代码防御现在的错误，而是防止在代码修改后引发的错误。理想情况下，单元测试可以完成这样的工作，可是需要面对的现实是，它们通常是没有完成的。人们可能在提交代码前会忘了运行测试代码。有一个内部检查是另一个阻挡错误的防线，尤其是那些不明显的错误，却导致了代码出问题并且返回错误的结果。加入你有一些if…elif的语句块，你知道在这之前一些需要有一些值：#targetisexpectedtobeoneofx,y,orz,andnothingelse.iftarget==x:run_x_code()eliftarget==y:run_y_code()else:run_z_code()假设代码现在是完全正确的。但它会一直是正确的吗？依赖的修改，代码的修改。如果依赖修改成target=w会发生什么，会关系到run_w_code函数吗？如果我们改变了代码，但没有修改这里的代码，可能会导致错误的调用run_z_code函数并引发错误。用防御型的方法来写代码会很好，它能让代码运行正确，或者立马执行错误，即使你在未来对它进行了修改。在代码开头的注释很好的一步，但是人们经常懒得读或者更新注释。一旦发生这种情况，注释会变得没用。但有了断言，我可以同时对代码块的假设书写文档，并且在它们违反的时候触发一个干净的错误asserttargetin(x,y,z)iftarget==x:run_x_code()eliftarget==y:run_y_code()else:asserttarget==zrun_z_code()这样，断言是一种防御型编程，同时也是一种文档。我想到一个更好的方案：iftarget==x:run_x_code()eliftarget==y:run_y_code()eliftarget==z:run_z_code()else:#Thiscanneverhappen.("anunexpectederroroccurred")按约定进行设计是断言的另一个好的用途。我们想象函数与调用者之间有个约定，比如下面的：“如果你传给我一个非空字符串，我保证传会字符串的第一个字母并将其大写。”如果约定被函数或调用这破坏，代码就会出问题。我们说函数有一些前置条件和后置条件，所以函数就会这么写：deffirst_upper(astring):assertisinstance(astring,str)andlen(astring)>0result=astring[0].upper()assertisinstance(result,str)andlen(result)==1assertresult==result.upper()returnresult按约定设计的目标是为了正确的编程，前置条件和后置条件是需要保持的。这是断言的典型应用场景，因为一旦我们发布了没有问题的代码到产品中，程序会是正确的，并且我们能安全的移除检查。下面是我建议的不要用断言的场景：不要用它测试用户提供的数据不要用断言来检查你觉得在你的程序的常规使用时会出错的地方。断言是用来检查非常罕见的问题。你的用户不应该看到任何断言错误，如果他们看到了，这是一个bug，修复它。有的情况下，不用断言是因为它比精确的检查要短，它不应该是懒码农的偷懒方式。不要用它来检查对公共库的输入参数，因为它不能控制调用者，所以不能保证调用者会不会打破双方的约定。不要为你觉得可以恢复的错误用断言。换句话说，不用改在产品代码里捕捉到断言错误。不要用太多断言以至于让代码很晦涩。

Ⅹ python怎么判断mysql中是否存在某个表

下面代码示例中的exist_of_table(table_name)是个人自写的一个方法：

即city表已经存在。

仅供参考！