如何做一个在线查询数据库~~ 用于市场价格查询

基本上是个python的web框架都可以写，简单的有bottle、webpy等，高并发性能的tornado、twisted等。

具体例子你查查rest风格的数据接口，比如用户用get方法获得html *** 作界面，post方法发送商品名称、年月等信息返回json查询结果等。用户注册和登录信息存在session里。网页微信同时利用一个后台。

说白了就是个最简单的动态网站，只涉及数据库和session。

你要是新手，看看python bottle的例子就好，关注数据库和session的实现，一天就能学会，为了提高并发可以使用gevent，配合写个脚本多进程运行，将就用是没问题的。想提高并发性能，以后抽空学下tornado，没啥难度。。。

比如：数据冗余，功能和性能方面存在的问题已经严重影响应用软件的使用

软件测试人员往往重视对软件功能和编码的测试，而忽略对软件性能，特别是数据库访问并发测试

因为，他们固有的思想中认为数据库设计存在问题对系统性能影响不大，或从根本上忽略了数据库在软件开发中的地位，直到出现了问题，才想到对数据库的测试，但往往也是仅仅通过对编码的测试工作中捎带对数据库进行一定的测试，这远远是不够的

目前，中铁网上订票系统在大用户同时在线订票中系统频频瘫痪，就是最好的佐证

所以，在应用软件的测试工作中，应该将数据库作为一个独立的部分进行充分的测试，这样才可以得到应用软件所需要的性能优化的数据库

那么，应该对哪些内容进行测试，如何进行测试呢2、数据库设计的测试数据库是应用的基础，其性能直接影响应用软件的性能

为了使数据库具有较好的性能，需要对数据库中的表进行规范化设计

规范化的范式可分为第一范式、第二范式、第三范式、BCNF范式、第四范式和第五范式

一般来说，逻辑数据库设计应满足第三范式的要求，这是因为满足第三范式的表结构容易维护，且基本满足实际应用的要求

因此，实际应用中一般都按照第三范式的标准进行规范化

但是，规范化也有缺点：由于将一个表拆分成为多个表，在查询时需要多表连接，降低了查询速度

故数据库设计的测试包括前期需求分析产生数据库逻辑模型和后期业务系统开发中的测试两部分（这里指的是后者），我在这里称为实体测试

数据库是由若干的实体组成的，包括（表，视图，存储过程等），数据库最基本的测试就是实体测试，通过对这些实体的测试，可以发现数据库实体设计得是否充分，是否有遗漏，每个实体的内容是否全面，扩展性如何

实体测试，可以用来发现应用软件在功能上存在的不足，也可以发现数据冗余的问题

经过测试，测试人员对有异议的问题要及时和数据库的设计人员进行沟通解决

3、数据一致性测试在进行实体测试后，应进一步检查下面的内容以保障数据的一致性：3

1表的主键测试根据应用系统的实际需求，对每个表的主键进行测试，验证是否存在记录不唯一的情况，如果有，则要重新设置主键，使表中记录唯一

3

2表之间主外键关系的测试数据库中主外键字段在名称，数据类型，字段长度上的一致性测试

3

3级联表，删除主表数据后，相应从报表数据应同时删除的问题例如学生表和学生成绩表，学生数据已经删除，成绩表中相应学生的成绩记录应同时删除

3

4存储过程和触发器的测试存储过程可以人工执行，但触发器不能人工处理，所以在对存储过程和触发器执行的过程中针对SQLSERVER2005及以上版本可以使用MicrosoftSQLServerProfiler性能测试工具进行测试

MicrosoftSQLServerProfiler是SQL跟踪的图形用户界面，用于监视数据库引擎或AnalysisServices的实例

测试人员可以捕获有关每个事件的数据并将其保存到文件或表中供以后分析

例如：可以对生产环境进行监视，了解哪些存储过程由于执行速度太慢影响了性能

4、数据库的容量测试随着数据库系统的使用，数据量在飞速增长，如何在使用前对数据容量的增长情况进行初步估算，为最终用户提供参考，这在数据库使用和维护过程中，是非常重要的

可以通过对数据库设计中基本表的数据大小，和每天数据表的数据产生量进行初步估算

记录数据量=各个字段所占字节数的总和表的数据量=记录数据量记录数数据库大小=各表数据量的总和当然，数据库的大小不仅仅只是基本表的大小，还有系统表，视图，存储过程等其它实体所占的容量，但最基本的数据是表的数据

另外，数据库的容量还包括数据库日志文件的容量，一般应预留数据库文件的2倍左右

5、数据库的性能测试应用软件除了功能外，很重要的一部分就是软件的性能，而对于数据库系统，数据库性能的好坏会直接影响应用软件的性能，这部分的测试，一般手工测试就显得无能为力了，这时就要借助自动化的测试软件，例如：DataFactory，DataFactory是一种强大的数据产生器，它允许开发人员和测试人员很容易产生百万行有意义的正确的测试数据库，该工具支持DB2、Oracle、Sybase、SQLServer数据库

这样，就可以模拟出应用软件长期使用后，海量数据存储的数据库的性能状况

从而尽早发现问题，进行数据库性能的优化

这里要注意，进行性能测试的时候，一定要注意测试环境的一致性，包括： *** 作系统、应用软件的版本以及硬件的配置等，而且在进行数据库方面的测试的时候一定要注意数据库的记录数、配置等要一致，只有在相同条件下进行测试，才可以对结果进行比较

否则无法和用户对软件的性能的观点达成一致

6、数据库的压力测试说起测试，我们首先想到的就是软件正确性的测试，即常说的功能测试

软件功能正确仅是软件质量合格指标之一

在实际开发中，还有其它的非功能因素也起着决定性的因素，例如软件的响应速度

影响软件响应速度的因素有很多，有些是因为算法不够高效；还有些可能受用户并发数的影响

在众多类型的软件测试中，压力测试正是以软件响应速度为测试目标，尤其是针对在较短时间内大量并发用户的访问时，软件的抗压能力

但压力测试往往是手工难以测试的，必须借助自动化测试工具

常用的压力测试有：Web测试、数据库测试等

数据库在大多数软件项目中是不可缺少的，对于它进行压力测试是为了找出数据库对象是否可以有效地承受来自多个用户的并发访问

这些对象主要是：索引、触发器、存储过程和锁

通过对SQL语句和存储过程的测试，自动化的压力测试工具可以间接的反应数据库对象是否需要优化

这些自动化的测试工具很多，各有特点，基于Java的项目可以使用JMeter，Net项目可以采用

Net集成开发环境中提供的测试方案

7、结束语总之，在应用系统的测试中，把数据库应当作为独立的系统来测试，这无疑会为应用软件的质量增加可靠的保障，同时还必须结合应用软件进行集成测试，只有二者有机结合起来，才能最大限度的发挥数据库和应用软件的功能

采用自增长主要是性能

早期的数据库系统，经常采用某种编号，比如身份z号码，公司编号等等作为数据库表的

然而，很快，大家就发现其中的不利之处

比如早期的医院管理系统，用身份z号码作为病人表的

然而，第一，不是每个人都有身份z；第二，对于国外来的病人，不同国家的病人的证件号码并不见得没有重复

因此，用身份z号码作为病人表的是一个非常糟糕的设计

考虑到没有医生或者护士会刻意去记这些号码，使用自增长是更好的设计

公司编号采用某种特定的编码方法，这也是早期的数据库系统常见的做法

它的缺点也显而易见：很容易出现像千年虫的软件问题，因为当初设计数据库表的时候设计的位数太短，导致系统使用几年后不能满足要求，只有修改程序才能继续使用

问题在于，任何人设计系统的时候，在预计某某编号多少位可以够用的时候，都存在预计不准的风险

而采用自增长则不存在这种问题

同样的道理，没有人可以去记这些号码

使用自增长另外一个原因是性能问题

略有编程常识的人都知道，数字大小比较比字符串大小比较要快得多

使用自增长可以大大地提高数据查找速度

2

避免用复合主键(compound)这主要还是因为性能问题

数据检索是要用到大量的值比较，只比较一个字段比比较多个字段快很多

使用单个从编程的角度也很有好处，sql语句中where条件可以写更少的代码，这意味着出错的机会大大减少

3

双主键双主键是指数据库表有两个字段，这两个字段独立成为主键，但又同时存在

数据库系统的双主键最早用在用户管理模块

最早的来源可能是参照 *** 作系统的用户管理模块

*** 作系统的用户管理有两个独立的主键： *** 作系统自己自动生成的随机ID(Linux,windows的SID),loginid

这两个ID都必须是唯一的，不同的是，删除用户test然后增加一个用户test,SID不同，loginid相同

采用双主键主要目的是为了防止删除后增加同样的loginid造成的混乱

比如销售经理hellen本机共享文件给总经理peter,一年后总经理离开公司，进来一个普通员工peter，两个peter用同样的loginid,如果只用loginid作 *** 作系统的用户管理主键，则存在漏洞：普通员工peter可以访问原来只有总经理才能看的文件

*** 作系统自己自动生成的随机ID一般情况下面用户是看不到的

双主键现在已经广泛用在各种数据库系统中，不限于用户管理系统

4

以固定的数据库、表应付变化的客户需求这主要基于以下几个因素的考虑：4

1大型EPR系统的正常使用、维护需要软件厂商及其众多的合作伙伴共同给客户提供技术服务，包括大量的二次开发

如果用户在软件正常使用过程中需要增加新的表或者数据库，将给软件厂商及其众多的合作伙伴带来难题

4

2软件升级的需要

没有一个软件能够让客户使用几十上百年不用升级的

软件升级往往涉及数据库表结构的改变

软件厂商会做额外的程序将早期版本软件的数据库数据升级到新的版本，但是对于用户使用过程中生成的表进行处理就比较为难

4

3软件开发的需要

使用固定的数据库库表从开发、二次开发来说，更加容易

对于用户使用过程中生成的表，每次查找数据时都要先查表名，再找数据，比较麻烦

举例来说，早期的用友财务软件用Aess作数据库，每年建立一个新的数据库

很快，用户和用友公司都发现，跨年度数据分析很难做

因此这是一个不好的设计

在ERP中，很少有不同的年度数据单独分开

一般来说，所有年份的数据都在同一个表中

对于跨国公司甚至整个集团公司都用同一个ERP系统的时候，所有公司的数据都在一起

这样的好处是数据分析比较容易做

现在大多数数据库系统都能做到在常数时间内返回一定量的数据

比如，Oracle数据库中，根据在100万条数据中取10条数据，与在1亿条数据中取10条数据，时间相差并不多

5

避免一次取数据库大量数据，取大量数据一定要用分页

这基本上是现在很多数据库系统设计的基本守则

ERP系统中超过100万条数据的表很多，对于很多表中的任何一个，一次取所有的会导致数据库服务器长时间处于停滞状态，并且影响其它在线用户的系统响应速度

一般来说，日常 *** 作，在分页显示的情况下面，每次取得数据在1-100之间，系统响应速度足够快，客户端基本没有特别长的停顿

这是比较理想的设计

这也是大型数据库系统往往用ODBC,ADO等等通用的数据库联接组件而不用特定的速度较快的专用数据库联接组件的原因

因为系统瓶颈在于数据库(Database)方面(数据量大)，而不在于客户端(客户端每次只取少量数据)

在B/S数据库系统中，分页非常普遍

早期的数据库系统经常有客户端程序中一次性取大量数据做缓冲

现在已经不是特别需要了，主要原因有：5

1数据库本身的缓冲技术大大提高

大部分数据库都会自动将常用的数据自动放在内存中缓冲，以提高性能

5

2数据库联接组件的缓冲技术也在提高

包括ADO在内的一些数据库联接组件都会自动对数据结果集(resultset)进行缓冲，并且效果不错

比较新颖的数据库联接组件，比如Hibernate也加入了一些数据结果集缓冲功能

当然，也有一些数据库联接组件没有对数据结果集进行缓冲，比如JDBCDriver，不过几年之内情况应该有所改观

也有些不太成功的数据缓冲，比如EJB中的实体Bean，性能就不尽如人意，实体Bean数据也是放在内存中，可能是因为占用内存过多的缘故

相对来说，今天的程序员写客户端数据缓冲，能够超过以上两个缓冲效果的，已经比较难了

以上就是关于如何做一个在线查询数据库~~ 用于市场价格查询全部的内容，包括:如何做一个在线查询数据库~~ 用于市场价格查询、软件测试跟数据库有什么关系吗、大型ERP数据库系统常见的几种设计有什么(ERP系统设计)等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！