web数据库

比较 PHP 和 JSP 这两个 Web开发 技术，在目前的情况是其实是比较PHP和 Java 的Web开发。以下是我就几个主要方面进行比较： 一、 语言比较 PHP是解释执行的服务器脚本语言，首先php有简单容易上手的特点。语法和c语言比较象，所以学过c语言的程序员可以很快的熟悉php的开发。而java需要先学好java的语法和熟悉一些核心的类库，懂得面向对象的程序设计方法。所以java不如php好学。 Java首先要编译成字节码.class文件，然后在java虚拟机上解释执行。Java的Web开发首先最容易想到的就是JSP（现在已经到 JSP2.0），原来的java的Web开发都是用servlet来实现的，用servlet来开发需要程序员在java的源文件中嵌入大量的html代码。所以后来就出现了JSP,JSP可以方便的嵌入到html文件当中，其实jsp文件在服务器上执行的时候首先会被应用服务器转换成servlet，然后再编译执行。Jsp可以通过servlet和JavaBean的支持产生强大的功能。JavaBean 是一种可复用的、跨平台的软件组件。使用javabean可以方便的实现java代码和html的分离，能够增强系统的功能和软件的复用性。 Java的Web开发属于SUN公司定义的J2EE其中的规范。而且在J2EE中包括了java的Web开发的所有方面，如：JSP

一般而言Redis在Javaweb应用中存在两个主要的场景,一个是缓存常用的数据,另一个是在需要高速读/写的场合使用它快速读/写,比如一些需要进行商品抢购和抢红包的场合. 一,缓存 在对数据库的读／写操作中，现实的情况是读操作的次数远超写操作， 一般是1 : 9 到3 : 7 的比例，所以需要读的可能性是比写的可能性多得多。当发送S QL 去数据库进行读取时，数据库就会去磁盘把对应的数据索引回来， 而索引磁盘是一个相对缓慢的过程。如果把数据直接放在运行在内存中的Redis 服务器上，那么不需要去读／写磁盘了，而是直接读取内存，显然速度会快得多，并且会极大减轻数据库的压力。 而使用内存进行存储数据开销也是比较大的，因为磁盘可以是TGB 级别，而且十分廉价，内存一般是几百个GB 就相当了不起了，所以内存虽然高效但空间有限，价格也比磁盘高许多，因此使用内存代价较高，并不是想存什么就存什么，因此我们应该考虑有条件的存储数据。一般而言，存储一些常用的数据，比如用户登录的信息： 一些主要的业务信息，比如银行会存储一些客户基础信息、银行卡信息、最近交易信息等。一般而言在使用 Red is 存储的时候，需要从3 个方面进行考虑。 ·业务数据常用吗？命中率如何？如果命中率很低，就没有必要写入缓存。 · 该业务数据是读操作多，还是写操作多，如果写操作多，频繁需要写入数据库，也没有必要使用缓存。

不喜欢看md原文的 可以访问这个链接： http://note.youdao.com/noteshare?id=6a91e3dea7cdf5195bb0e851d9fcb5a5 # web sql 增删改查 ## 打开数据库 ``` /* * @description openDatabase方法打开一个已经存在的数据库，如果数据库不存在， 它还可以创建数据库 * @param name {string} - 数据库名称 * @param version {string} - 版本号 * @param baseDesc {string} - 数据库描述 * @param size {number|string} - 设置数据的大小 * @param callback {function} - 回调函数(可省略) * example : * var db = openDatabase('mydb', '1.0', 'Test DB', 2 * 1024 * 1024,function() * {}) */ var db = openDatabase(name, version, baseDesc,size,callback) ``` ## 数据库语句使用方法 ``` db.transaction(function(tx) { /* * @description 数据库方法使用语句

千万级的注册用户，千万级的帖子，nTB级的附件，还有巨大的日访问量，大型网站采用什么系统架构保证性能和稳定性？ 首先讨论一下大型网站需要注意和考虑的问题。 数据库 海量数据处理：负载量不大的情况下select、delete和update是响应很迅速的，最多加几个索引就可以搞定，但千万级的注册用户和一个设计不好的多对多关系将带来非常严重的性能问题。另外在高UPDATE的情况下，更新一个聚焦索引的时间基本上是不可忍受的。索引和更新是一对天生的冤家。 高并发死锁：平时我们感觉不到，但数据库死锁在高并发的情况下的出现的概率是非常高的。 文件存储的问题：大型网站有海量图片数据、视频数据、文件数据等等，他们如何存储并被有效索引？高并发的情况下IO的瓶颈问题会迅速显现。也许用RAID和专用存贮 服务器 能解决眼下的问题，但是还有个问题就是各地的访问问题，也许我们的服务器在北京，可能在云南或者新疆的访问速度如何解决？如果做分布式，那么我们的文件索引以及架构该如何规划。 接下来讨论大型网站的底层系统架构，来有效的解决上述问题。 毋庸置疑，对于规模稍大的网站来说，其背后必然是一个服务器集群来提供网站服务，例如，2004年eBay的服务器有2400台，估计现在更多。当然，数据库也必然要和应用服务分开，有单独的数据库服务器集群。对于像淘宝网这样规模的网站而言，就是应用也分成很多组。 下面

现在市场上的电子商务软件基本上可归结为两大阵营，即PHP阵营和Java阵营。但对接触电子商务不久的用户来说，看到的往往只是它们的表相，只是明显的价格差异，却很难看出它们之间的实际差异。其实，PHP+ MySQL高效的开发、品质优良的特性，已经让风靡大学校园的Java变的越来越难堪。而作为PHP+ MySQL为什么在历史的进程中，后来居上，独领风骚呢？为什么基于Java架构的的电子商务除了高额的开发成本，而变的前途暗淡呢?首先得明白PHP和Java之间的差异才行。 1、 出身 Java本来的设计初衷是为了家用消费电子产品开发一个分布式代码系统。 PHP就是为了互联网的应用而生的。 　　2、系统的技术架构比较 分层是将系统进行有效组织的方式，分而治之的思想是计算机领域中非常重要的思想。在好的分层思想引导下，便能实现“高内聚、低耦合”，也能将具体的问题割 裂开来，易于控制、易于延展，更易于分配资源。从PHP5版本之后，PHP对于系统架构方面也有了质的飞跃。ShopNC 采用PHP语言开发，可以完美的实现多层架构分布。运用MVC的设计模式，可使电子商务软件具有更加高效、合理的系统架构。使得系统在可拓展性、需求应变性上与Java编写的电子商务软件系统的毫不逊色。 Gutmans 在前年发表过一篇文章，其中也阐述了多核环境中多线程（JVM）与多进程（LAMP）的比较

1. 数据库命名规范 由小写字母及下划线组成，一般采用业务名称简写。如 web_19floor_net web_car 备份数据库名称为正式库+当前时间 . web_19floor_net_20070403 web_car_20070403 2. 数据库表命名规范 数据表名使用小写英文以及下划线组成,尽量说明是那个应用或者系统在使用的. 相关应用的数据表使用同一前缀,如 论坛的表使用cdb_前缀,博客的数据表使用supe_前缀,前缀名称一般不超过5字 比如: web_user web_group supe_userspace 备份数据表名使用正式表名加上备份时间组成,如: web_user_20070403 web_group_20070403 supe_userspace_20070403 3. 字段命名规范 字段名称使用单词组合完成,首字母小写,后面单词的首字母大写,最好是带表名前缀. 如 web_user 表的字 段: userId userName userPassword 表与表之间的相关联字段要用统一名称, 如 web_user 表 里面的 userId 和 web_group 表里面的 userId 相对应 4. 字段类型规范 规则:用尽量少的存储空间来存 数一个字段的数据. 比如能用int的就不用char或者varchar 能用tinyint的就不用int 能用

SQL注入部分 第一题： 基础知识： ORDER BY 语句用于根据指定的列对结果集进行排序。 ORDER BY 语句默认按照升序对记录进行排序。 如果您希望按照降序对记录进行排序，可以使用 DESC 关键字 ----------------------------- UNION 操作符用于合并两个或多个 SELECT 语句的结果集。 请注意，UNION 内部的 SELECT 语句必须拥有相同数量的列。列也必须拥有相似的数据类型。同时，每条 SELECT 语句中的列的顺序必须相同。 ------------------------------- 在MySQL中，把 information_schema 看作是一个数据库，确切说是信息数据库。其中保存着关于MySQL服务器所维护的所有其他数据库的信息。如数据库名，数据库的表，表栏的数据类型与访问权 限等。在INFORMATION_SCHEMA中，有数个只读表。它们实际上是视图，而不是基本表，因此，你将无法看到与之相关的任何文件。 ------------------------------------- 来源： https://www.cnblogs.com/betong/p/12347167.html

千万级的注册用户，千万级的帖子，nTB级的附件，还有巨大的日访问量，大型网站采用什么系统架构保证性能和稳定性？ 首先讨论一下大型网站需要注意和考虑的问题。 数据库海量数据处理 ：负载量不大的情况下select、delete和update是响应很迅速的，最多加几个索引就可以搞定，但千万级的注册用户和一个设计不好的多对多关系将带来非常严重的性能问题。另外在高UPDATE的情况下，更新一个聚焦索引的时间基本上是不可忍受的。索引和更新是一对天生的冤家。 高并发死锁 ：平时我们感觉不到，但数据库死锁在高并发的情况下的出现的概率是非常高的。 文件存储的问题 ：大型网站有海量图片数据、视频数据、文件数据等等，他们如何存储并被有效索引？高并发的情况下IO的瓶颈问题会迅速显现。也许用RAID和专用存贮服务器能解决眼下的问题，但是还有个问题就是各地的访问问题，也许我们的服务器在北京，可能在云南或者海南的访问速度如何解决?如果做分布式，那么我们的文件索引以及架构该如何规划。 接下来讨论大型网站的底层系统架构，来有效的解决上述问题。 毋庸置疑，对于规模稍大的网站来说，其背后必然是一个服务器集群来提供网站服务，例如，2004年eBay的服务器有2400台，估计现在更多。当然，数据库也必然要和应用服务分开，有单独的数据库服务器集群。对于像淘宝网这样规模的网站而言，就是应用也分成很多组。 下面

千万级的注册用户，千万级的帖子，nTB级的附件，还有巨大的日访问量，大型网站采用什么系统架构保证性能和稳定性？ 首先讨论一下大型网站需要注意和考虑的问题。 数据库海量数据处理 ：负载量不大的情况下select、delete和update是响应很迅速的，最多加几个索引就可以搞定，但千万级的注册用户和一个设计不好的多对多关系将带来非常严重的性能问题。另外在高UPDATE的情况下，更新一个聚焦索引的时间基本上是不可忍受的。索引和更新是一对天生的冤家。 高并发死锁 ：平时我们感觉不到，但数据库死锁在高并发的情况下的出现的概率是非常高的。 文件存储的问题 ：大型网站有海量图片数据、视频数据、文件数据等等，他们如何存储并被有效索引？高并发的情况下IO的瓶颈问题会迅速显现。也许用RAID和专用存贮服务器能解决眼下的问题，但是还有个问题就是各地的访问问题，也许我们的服务器在北京，可能在云南或者海南的访问速度如何解决?如果做分布式，那么我们的文件索引以及架构该如何规划。 接下来讨论大型网站的底层系统架构，来有效的解决上述问题。 毋庸置疑，对于规模稍大的网站来说，其背后必然是一个服务器集群来提供网站服务，例如，2004年eBay的服务器有2400台，估计现在更多。当然，数据库也必然要和应用服务分开，有单独的数据库服务器集群。对于像淘宝网这样规模的网站而言，就是应用也分成很多组。 下面

千万级的注册用户，千万级的帖子，nTB级的附件，还有巨大的日访问量，大型网站采用什么系统架构保证性能和稳定性？ 首先讨论一下大型网站需要注意和考虑的问题。 数据库海量数据处理 ：负载量不大的情况下select、delete和update是响应很迅速的，最多加几个索引就可以搞定，但千万级的注册用户和一个设计不好的多对多关系将带来非常严重的性能问题。另外在高UPDATE的情况下，更新一个聚焦索引的时间基本上是不可忍受的。索引和更新是一对天生的冤家。 高并发死锁 ：平时我们感觉不到，但数据库死锁在高并发的情况下的出现的概率是非常高的。 文件存储的问题 ：大型网站有海量图片数据、视频数据、文件数据等等，他们如何存储并被有效索引？高并发的情况下IO的瓶颈问题会迅速显现。也许用RAID和专用存贮服务器能解决眼下的问题，但是还有个问题就是各地的访问问题，也许我们的服务器在北京，可能在云南或者海南的访问速度如何解决?如果做分布式，那么我们的文件索引以及架构该如何规划。 接下来讨论大型网站的底层系统架构，来有效的解决上述问题。 毋庸置疑，对于规模稍大的网站来说，其背后必然是一个服务器集群来提供网站服务，例如，2004年eBay的服务器有2400台，估计现在更多。当然，数据库也必然要和应用服务分开，有单独的数据库服务器集群。对于像淘宝网这样规模的网站而言，就是应用也分成很多组。 下面