帖子标记 ‘Database’

随着MySQL的命运飘忽不定,又涌现出许多开源数据库,包括了HadoopDB, Drizzle, MongoDB, Cassandra DB以及 CouchDB,这样的势头将在接下来的2010年持续下去。

NOSql概念值得关注。NOSQL适合高并发和超大规模数据的情况。NOt only sql,可见是关系数据的有益补充。具体可见此文章

可以预见,PostgreSQL又将热起来。互联网上的选择,有时很忌讳商业公司。。就是这个缘故会造成部分(也难说是大部分)会选择 PostgreSQL。而成熟的开源免费的关系数据库,不多。PostgreSQL现在获得了很好的际遇。
(全文 …)

新的安全漏洞名单列出了可导致数据破坏的最常见的数据库问题。
对于Application Security公司新的十大数据库漏洞名单中所列出的问题,数据库管理员都非常熟悉。从预设密码的使用到补丁问题,数据库管理系统受到各种问题的困扰,使其容易受到攻击。当我报告数据库管理问题时,数据库管理员告诉我,他们都意识到这些常见的可能导致数据破坏的安全问题。但是,他们常说包含敏感数据的DBMS通常由许多不同的安全系统包围,这减少了攻击的威胁。
(全文 …)

自从上次由于没有成功备份导致博客的大部分文章无法还原之后,我就更加小心博客的备份了,并且还尝试了多种的备份方法,以下是其中三种直接备份 WordPress 博客的方法。

所谓直接备份,是指不需要借助于 WordPress 插件、第三方服务或者程序代码,而直接通过 WordPress 后台或者 cPanel 备份,这样的备份方法是最安全的,只不过需要手动。

方法一:通过 WordPress 后台备份博客数据库

备份 WordPress 博客数据库
(全文 …)

通过服务器直接备份博客数据库虽然最安全,但是需要手动不方便;通过 WordPress 插件备份虽然可以全自动,但是可能会出现问题。所以,如果能够把数据库备份到服务器,同时也备份到邮箱,不需要安装任何插件,并且一切都是自动 完成的,那就好了。

事实上,AutoMySQLBackup 程序是可以实现这个想法的,虽然并不适合所有的服务器。下面先介绍 AutoMySQLBackup 程序的使用方法,然后再说说它的不足之处。

一、通过 AutoMySQLBackup 备份博客数据库的具体步骤:

第一步. 下载 AutoMySQLBackup 文件

下载地址:AutoMySQLBackup
(全文 …)

直接备份 WordPress 博客数据库的方法虽然比较安全,但是也比较麻烦,因为你每次都要手动操作。于是,有人想到了通过使用插件的方法来自动备份 WordPress 博客的数据库。

WordPress 博客数据库备份插件不少,下面 10 个则是其中的佼佼者,它们都是免费的并且都兼容于 WordPress 2.9.2:

1. WordPress Database Backup

WordPress backup
(全文 …)

————————————————————————–
– Author : htl258(Tony)
– Date : 2010-04-18 10:45:14
– Version:Microsoft SQL Server 2008 (RTM) – 10.0.1600.22 (Intel X86)
– Jul 9 2008 14:43:34
– Copyright (c) 1988-2008 Microsoft Corporation
– Developer Edition on Windows NT 5.1 <X86> (Build 2600: Service Pack 2)
– Blog :http://blog.csdn.net/htl258
– Subject:数据库备份存储过程(判断盘符、路径,错误盘符返回,不存在的路径自动创建)
————————————————————————–
–适用环境:SQL Server 2005及以上版本
USE master
GO
–1.周期性备份数据库代码(保留原来备份的):
–备份文件名为:原数据库名称+’_'+备份日期.bak
IF OBJECT_ID(‘sp_backupdatabase’) IS NOT NULL
DROP PROC sp_backupdatabase
GO
CREATE PROC sp_backupdatabase
@path NVARCHAR(100)–路径
AS
–路径名格式标准化
IF RIGHT(@path,1)<>’\’ SET @path=@path+’\’
–获取文件夹信息
DECLARE @t TABLE(id INT IDENTITY,a INT,b INT,c INT)
DECLARE @fpath NVARCHAR(3)
SET @fpath=LEFT(@path,3)
INSERT @t EXEC master..xp_fileexist @fpath
INSERT @t EXEC master..xp_fileexist @path
–如果指定盘符有误不存在,则返回错误提示:
IF EXISTS(SELECT 1 FROM @t WHERE id=1 AND c=0)
BEGIN
RAISERROR(N’输入的盘符不存在,请重新输入!’,16,1)
RETURN
END
–如果不存在指定的文件夹,则创建:
ELSE IF EXISTS(SELECT 1 FROM @t WHERE b=0 AND id=2)
BEGIN
DECLARE @mddir NVARCHAR(100)
SET @mddir=’md ‘+@path
EXEC master..xp_cmdshell @mddir
END
–开始备份数据库到指定的目录
DECLARE @s nvarchar(4000)
SELECT @s=ISNULL(@s+’;',”)
+N’BACKUP database ['+name+'] TO DISK = ”’
+@path+name+’_'+CONVERT(NVARCHAR(8),getdate(),112)+N’.bak”’
FROM master..sysdatabases
WHERE name NOT IN(‘master’,'tempdb’,'model’,'msdb’,'pubs’)–这里筛选不参加备份的数据库
EXEC(@S)
GO
–调用方法:
EXEC sp_backupdatabase ‘f:\Backup\tony’
/*
–返回信息:
已为数据库 ‘mydb’,文件 ‘mydb’ (位于文件 1 上)处理了 312 页。
已为数据库 ‘mydb’,文件 ‘mydb_log’ (位于文件 1 上)处理了 1 页。
BACKUP DATABASE 成功处理了 313 页,花费 0.733 秒(3.336 MB/秒)。
已为数据库 ‘test’,文件 ‘test’ (位于文件 1 上)处理了 208 页。
已为数据库 ‘test’,文件 ‘test_log’ (位于文件 1 上)处理了 1 页。
BACKUP DATABASE 成功处理了 209 页,花费 0.413 秒(3.951 MB/秒)。
–备份后的文件列表:
mydb_20100418.bak
test_20100418.bak
*/

–2.周期性备份数据库代码(自动删除原备份文件):
–备份文件名为:原数据库名称.bak
IF OBJECT_ID(‘sp_backupdatabase’) IS NOT NULL
DROP PROC sp_backupdatabase
GO
CREATE PROC sp_backupdatabase
@path NVARCHAR(100)–路径
AS
–路径名格式标准化
IF RIGHT(@path,1)<>’\’ SET @path=@path+’\’
–获取文件夹信息
DECLARE @t TABLE(id INT IDENTITY,a INT,b INT,c INT)
DECLARE @fpath NVARCHAR(3)
SET @fpath=LEFT(@path,3)
INSERT @t EXEC master..xp_fileexist @fpath
INSERT @t EXEC master..xp_fileexist @path
–如果指定盘符有误不存在,则返回错误提示:
IF EXISTS(SELECT 1 FROM @t WHERE id=1 AND c=0)
BEGIN
RAISERROR(N’输入的盘符不存在,请重新输入!’,16,1)
RETURN
END
–如果不存在指定的文件夹,则创建:
ELSE IF EXISTS(SELECT 1 FROM @t WHERE b=0 AND id=2)
BEGIN
DECLARE @mddir NVARCHAR(100)
SET @mddir=’md ‘+@path
EXEC master..xp_cmdshell @mddir
END
–开始备份数据库到指定的目录
DECLARE @s nvarchar(4000)
SELECT @s=ISNULL(@s+’;',”)
+N’BACKUP database ['+name+'] TO DISK = ”’
+@path+name+N’.bak” WITH INIT’
FROM master..sysdatabases
WHERE name NOT IN(‘master’,'tempdb’,'model’,'msdb’,'pubs’)–这里筛选不参加备份的数据库
EXEC(@S)
GO
–调用方法:
EXEC sp_backupdatabase ‘f:\Backup\tony2′
/*
–返回信息:
已为数据库 ‘mydb’,文件 ‘mydb’ (位于文件 1 上)处理了 312 页。
已为数据库 ‘mydb’,文件 ‘mydb_log’ (位于文件 1 上)处理了 1 页。
BACKUP DATABASE 成功处理了 313 页,花费 0.599 秒(4.082 MB/秒)。
已为数据库 ‘test’,文件 ‘test’ (位于文件 1 上)处理了 208 页。
已为数据库 ‘test’,文件 ‘test_log’ (位于文件 1 上)处理了 1 页。
BACKUP DATABASE 成功处理了 209 页,花费 0.351 秒(4.651 MB/秒)。
–备份后的文件列表:
mydb.bak
test.bak
*/

1. 原始单据与实体之间的关系

可以是一对一、一对多、多对多的关系。在一般情况下,它们是一对一的关系:即一张原始单据对应且 只对应一个实体。在特殊情况下,它们可能是一对多或多对一的关系,即一张原始单据对应多个实体,或多张原始单据对应一个实体。这里的实体可以理解为基本 表。明确这种对应关系后,对我们设计录入界面大有好处。

〖例1〗:一份员工履历资料,在人力资源信息系统中,就对应三个基本表: 员工基本情况表、社会关系表、工作简历表。这就是“一张原始单据对应多个实体”的典型例子。

2. 主键与外键

一般而言,一个实体不能既无主键又无外键。在E-R 图中, 处于叶子部位的实体, 可以定义主键,也可以不定义主键(因为它无子孙), 但必须要有外键(因为它有父亲)。

主键与外键的设计,在全局数据库的设计中,占有重要地位。当全局数据库的设计完成以后,有个美 国数据库设计专家说:“键,到处都是键,除了键之外,什么也没有”,这就是他的数据库设计经验之谈,也反映了他对信息系统核心(数据模型)的高度抽象思 想。因为:主键是实体的高度抽象,主键与外键的配对,表示实体之间的连接。
(全文 …)

前言:

实验的数据表如下定义:

mysql> desc tbl_name;
+-------+--------------+------+-----+---------+-------+
| Field | Type         | Null | Key | Default | Extra |
+-------+--------------+------+-----+---------+-------+
| uid   | int(11)      | NO   |     | NULL    |       |
| sid   | mediumint(9) | NO   |     | NULL    |       |
| times | mediumint(9) | NO   |     | NULL    |       |
+-------+--------------+------+-----+---------+-------+
3 rows in set (0.00 sec)

存储引擎是MyISAM,里面有10,000条数据。
(全文 …)

Databases Files
Advantages
  • You can easily add new fields, or modify existing fields.
  • Updating player statistics (from outside the game) is much easier.
  • You can instantly and efficiently retrieve various statistics, via SQL queries.
  • There is no need to perform file I/O operations yourself, the database server will do that for you.
  • Easy to update/restore.
  • Very fast access (read/write).
  • Easy to implement.
  • No additional libraries needed.
  • No dependence on a database server. Therefore, you don’t have to worry about getting database updates or security issues.
Disadvantages
  • Easy to make mistakes. For example, doing an update query where you omit the ‘where’ clause. It can have disastrous effects, especially if you have old (or no) backups.
  • Databases may be slower than actually opening/writing a player file. You might lose a few milliseconds when retrieving some data, especially if a lot of players log in/out at the same time.
  • Additional code is required to convert your data to/from the database.
  • Database and SQL experience is required. In addition, you will need a library to interface between your program and the database.
  • If for some reason the database file becomes corrupt, you are out of luck; you can lose all the players (especially if no recent backups).
  • It can be very difficult to add new fields, unless you carefully design the file format/structure from the beginning.
  • Inability to do player-wide queries (this can be circumvented by having a program that adds every night the important fields in a database server).
  • Needs special coding if you want to update/check player stats.
  • A little bit harder to update/restore.