精华内容
下载资源
问答
  • MySQL—DDL操作1(创、查、删、改数据库和表) 知识大纲 SQL语句的分类(什么是DDL) ...修改表结构 小练习 SQL语句分类 名字 类型 作用的对象 作用 DDL 英文全称 (Data Definition Lang

    MySQL—DDL操作1(创、查、删、改数据库和表)

    知识大纲

    • SQL语句的分类(什么是DDL)

    • 操作Database

    • 表结构操作TABLE

    学习任务

    • 操作Database
      1. 创建数据库
      2. 查看有哪些数据库
      3. 删除数据库
      4. 选择数据库
      5. 查看当前正在使用哪个数据库
    • 表结构操作TABLE
      1. 查看当前数据库所有表
      2. 创建表结构
      3. 查看表结构
      4. 删除表结构
      5. 修改表结构
    • 小练习

    SQL语句分类

    名字 类型 作用的对象 作用
    DDL 英文全称 (Data Definition Language) 数据定义语言 库、表、列 创建、删除、修改、库或表结构,对数据库或表的结构操作
    DQL 英文全称(Data Query Language) 数据查询语言 数据库记录(数据) 查、用来查询数据,对表记录的查询
    DCL 英文全称(Data Control Language) 数据控制语言 数据库用户 用来定义访问的权限和安全级别,对用户的创建,及授权
    DML 英文全称(Data Manipulation Language 数据操作语言 数据库记录(数据) 增、删、改,对表记录进行更新(增、删、改)

    DDL[数据定义语言]

    DDL 用于结构定义、操作方法定义等。

    包括:数据段、数据库、表、列、索引等数据库对象操作。

    主要的语句关键字包括: create drop alter等

    操作Database

    注意:database 不能改名。一些可视化工具可以改名,它是建新库,把所有表复制到新 库,再删旧库完成的。

    在这里插入图片描述

    1.创建数据库

    create database 数据库名 [charset 字符集]; (关键字大写效果:CREATE DATABASE 数据库名;)

    如果不指定字符集,则按照安装 mysql 服务时选择的默认字符集。例如:

    #创建数据库
    #方式-1:直接创建[采用MySQL默认字符集latin1 -- cp1252 West European]
    CREATE DATABASE mysql03;
    
    #方式-2:创建并指定字符集[utf8 -- UTF-8 Unicode]
    CREATE DATABASE mysql04 CHARACTER SET utf8;
    
    #查看校对规则
    SHOW CHARACTER SET;
    
    #方式-3:创建并指定字符集[utf8]和校对规则[utf8_general_ci]
    CREATE DATABASE mysql05 CHARACTER SET utf8 COLLATE utf8_general_ci;
    
    #创建数据库[若数据库不存在]
    #IF EXISTS[删除表使用过]
    CREATE DATABASE IF NOT EXISTS mysql05;
    

    2.查看有哪些数据库

    show databases;

    提示:当前用户有权限查看的

    #查看有哪些数据库
    SHOW DATABASES;
    

    3.删除数据库

    drop database 数据库名;

    #删除数据库[直接删除]
    DROP DATABASE mysql03;
    
    #删除数据库[判断删除]
    DROP DATABASE IF EXISTS mysql04;
    DROP DATABASE IF EXISTS mysql05;
    

    4.选择数据库

    use 数据库名;

    #定位数据库
    USE mysql01;
    

    5.查看当前正在使用哪个数据库

    select database();

    注意:要操作表格和数据之前必须先说明是对哪个数据库进行操作,否则就要对所有 对象加上“数据库名.”。

    #查看当前正在使用的数据库
    SELECT DATABASE();
    
    #跨数据库查询表数据[数据库名.表名]
    #empinfo[mysql02]
    #SELECT * FROM mysql01.empinfo;
    SELECT * FROM mysql02.empinfo;
    

    表结构操作 TABLE

    1.查看当前数据库所有表

    show tables; #前面必须有 use 数据库名语句,否则报错

    show tables from 数据库名;

    #前往mysql02数据库
    USE mysql02;#SELECT DATABASE() -> mysql02
    #查看当前数据库所有表
    SHOW TABLES;
    
    #查看指定数据库的表内容
    SHOW TABLES FROM mysql01;
    

    2.创建表结构

    (1)基础版

    在这里插入图片描述

    (2)详细版

    在这里插入图片描述
    在这里插入图片描述

    #创建测试数据库test
    DROP DATABASE IF EXISTS test;
    CREATE DATABASE IF NOT EXISTS test CHARACTER SET utf8;
    #定位到test[若没有定位数据库 那么表会被存放到当前数据库中]
    USE test;
    #在test库中创建表Student[简单建表方式]
    CREATE TABLE student
    (
    		stu_id INT,
    		stu_name VARCHAR(20),
    		stu_sex CHAR(2),
    		stu_age INT
    );
    #插入数据
    INSERT INTO student VALUES(1001,'张三','男',16);
    INSERT INTO student VALUES(1002,'李四','女',17);
    #查询信息
    SELECT * FROM student;
    
    #SELECT DATABASE();
    
    
    /*
    建表配置 可选参数:
    ENGINE=INNODB [当前表格的引擎]
    AUTO_INCREMENT=1 [增长的起始值]
    DEFAULT CHARSET=utf8; [表数据的默认字符集]
    */
    #复杂的建表方式
    #创建表emp [要求:定义主键、自增字段、非空约束、默认值]
    DROP TABLE IF EXISTS emp;
    
    CREATE TABLE emp
    (
    		emp_id INT PRIMARY KEY AUTO_INCREMENT,
    		emp_name VARCHAR(20) NOT NULL,
    		emp_sex CHAR(2) DEFAULT '男',
    		emp_age INT NOT NULL
    )ENGINE=INNODB AUTO_INCREMENT=1000 DEFAULT CHARSET=utf8;
    
    #添加数据测试
    INSERT INTO emp(emp_name,emp_sex,emp_age) VALUES('八戒','男',28);
    INSERT INTO emp(emp_name,emp_sex,emp_age) VALUES('嫦娥','女',18);
    
    #INSERT INTO emp(emp_name,emp_sex) VALUES('梅超风','女');
    INSERT INTO emp(emp_name,emp_age) VALUES('梅超风',38);
    
    #查看所有内容
    SELECT * FROM emp;
    

    3.查看表结构

    desc 表名称;

    查看表的定义:SHOW CREATE TABLE 表名;

    #查看表结构
    DESC emp;
    
    #查看表定义[获得表定的标准SQL代码]
    SHOW CREATE TABLE emp;
    

    4.删除表结构

    drop table 表名称;

    注意:

    数据和结构都被删除

    所有正在运行的相关事务被提交

    所有相关索引被删除

    DROP TABLE 语句不能回滚

    #删除表的 数据
    DELETE FROM emp;
    
    #删除表的 数据和结构
    DROP TABLE IF EXISTS emp;
    
    #SELECT * FROM emp;
    

    5.修改表结构

    (1)重命名表

    alter table 表名 rename 新表名;

    rename table 表名 to 新表名;

    #修改表名 语法-1[emp -> employee]
    ALTER TABLE emp RENAME employee;
    #emp已经被重命名为employee(不存在)
    #SELECT * FROM emp;
    SELECT * FROM employee;
    
    #修改表名 语法-2[employee -> employees]
    RENAME TABLE employee to employees;
    SELECT * FROM employees;
    

    (2)增加一列

    alter table 表名 add 【column】 列名 数据类型; #默认在最后

    alter table 表名 add 【column】 列名 数据类型 after 某一列;

    alter table 表名 add 【column】 列名 数据类型 first;

    注意:**!没有!**alter table 表名 add 【column】 列名 数据类型 before 某一列;

    #修改表 语法-1 新增列[emp_city] [默认添加为表的最后一列]
    ALTER TABLE employees ADD emp_city VARCHAR(20);
    
    #修改表 语法-2 新增列[emp_address] [修饰"first" 使新列成为首列]
    ALTER TABLE employees ADD emp_address VARCHAR(20) FIRST;
    
    #修改表 语法-3 新增列[emp_mail] [修饰"after 列名" 使新列插入在指定的列名后]
    ALTER TABLE employees ADD emp_mail VARCHAR(20) AFTER emp_sex;
    
    #ERROR
    #ALTER TABLE employees ADD emp_xx VARCHAR(20) BEFORE emp_sex;
    

    (3)删除列

    alter table 表名 drop 【column】 列名;

    #删除列 [将刚刚添加的"emp_mail"列删除]
    ALTER TABLE employees DROP COLUMN emp_mail;
    #删除列 [将刚刚添加的"emp_address"列删除]
    ALTER TABLE employees DROP emp_address;
    
    SELECT * FROM employees;
    DESC employees;
    

    (4)修改列类型

    alter table 表名 modify 【column】 列名 数据类型;

    alter table 表名 modify 【column】 列名 数据类型 after 某一列;

    alter table 表名 modify 【column】 列名 数据类型 first;

    #修改列数据类型 语法-1 [emp_name varchar(20) -> varchar(30)]
    ALTER TABLE employees MODIFY emp_name varchar(30);
    #修改列数据类型 语法-1 [emp_age int -> float]
    ALTER TABLE employees MODIFY emp_age float;
    
    #修改列数据类型 语法-2 [使用"after 列名" 在修改类型的同时 移动列的位置到指定列的后方]
    #修改emp_age列的数据类型为int
    ALTER TABLE employees MODIFY emp_age int AFTER emp_name;
    
    #修改列数据类型 语法-3 [使用"first" 在修改类型的同时 移动列的位置到首列]
    ALTER TABLE employees MODIFY emp_age float FIRST;
    

    (5)修改列名等

    alter table 表名 change 【column】 列名 新列名 数据类型

    #修改列的名称 [emp_city -> emp_address]
    ALTER TABLE employees CHANGE emp_city emp_address VARCHAR(50);
    

    练习

    • 题目
    #创建数据库mytest1[简单创建]
    #创建数据库mytest2 指定其编码格式为utf8 查看校对规则 并选择合适的规则
    #查看有哪些数据库
    #若数据库mytest1存在 将其移除
    #定位数据库mytest2
    #查看当前正在使用的数据库是否为mytest2
    #在mytest2中查看其他数据库的表数据
    
    
    #创建学生表
    #[具备以下列:学号(自增字段)、姓名(非空约束)、性别(默认为女)、年龄(非空约束)、地址、电话]
    #[当前表格的引擎为INNODB 增长的起始值为1001 表数据的默认字符集为UTF8]
    
    #进行以下操作:
    #查看表中所有内容
    #查看表结构
    #查看表定义
    
    
    #修改表 修改表名[2种方式]
    #修改表 新增列[city-城市 ...][3种方式]
    #修改表 修改列的数据类型[name varchar2(20) -> varchar2(40) ...][3种方式]
    #修改表 修改列的名[phone-tell]
    #修改表 移除列[address]
    
    #删除表的 数据
    #删除表的 数据和结构
    
    
    • 答案
    #创建数据库mytest1[简单创建]
    CREATE DATABASE mytest1;
    
    #查看校对规则
    SHOW CHARACTER SET;
    
    #创建数据库mytest2 指定其编码格式为utf8 查看校对规则 并选择合适的规则
    CREATE DATABASE mytest2 CHARACTER SET utf8 COLLATE utf8_general_ci;
    
    #查看有哪些数据库
    SHOW DATABASES;
    
    #若数据库mytest1存在 将其移除
    CREATE DATABASE IF EXISTS mytest1;
    
    #定位数据库mytest2
    USE mytest2;
    
    #查看当前正在使用的数据库是否为mytest2
    SELECT DATABASE();
    
    #在mytest2中查看其他数据库的表数据
    SELECT * FROM mysql02.empinfo;
    
    #创建学生表
    #[具备以下列:学号(自增字段)、姓名(非空约束)、性别(默认为女)、年龄(非空约束)、地址、电话]
    #[当前表格的引擎为INNODB 增长的起始值为1001 表数据的默认字符集为UTF8]
    CREATE TABLE student
    (
           id VARCHAR(12) PRIMARY KEY AUTO_INCREMENT,
           name VARCHAR(30) NOT NULL,
           sex CHAR(2) DEFAULT '女',
           age INT NOT NULL,
           address VARCHAR(50),
           phone VARCHAR(11)
    )ENGINE=INNODB AUTO_INCREMENT=1001 DEFAULT CHARSET=utf8;
    
    #进行以下操作:
    #查看表中所有内容
    SELECT * FROM student;
    
    #查看表结构
    DESC student;
    
    #查看表定义
    SHOW CREATE TABLE student;
    
    #修改表 修改表名[2种方式]
    ALTER TABLE student RENAME students;
    RENAME TABLE students to student;
    
    #修改表 新增列[city-城市 ...][3种方式]
    ALTER TABLE student ADD city VARCHAR(20);
    ALTER TABLE student ADD column1 VARCHAR(20) FIRST;
    ALTER TABLE student ADD column2 VARCHAR(20) AFTER age;
    
    #修改表 修改列的数据类型[name varchar2(20) -> varchar2(40) ...][3种方式]
    ALTER TABLE student MODIFY name varchar2(40);
    ALTER TABLE student MODIFY column1 varchar2(22) AFTER name;
    ALTER TABLE student MODIFY column2 varchar2(24) FIRST;
    
    #修改表 修改列的名[phone-tell]
    ALTER TABLE student CHANGE phone tell VARCHAR(11);
    
    #修改表 移除列[address]
    ALTER TABLE student DROP address;
    
    #删除表的 数据
    DELETE FROM student;
    
    #删除表的 数据和结构
    DROP TABLE IF EXISTS student;
    
    展开全文
  • Hive 的使用操作方法-表创建,删除,分区的增删,修改表结构,重命名,行列互转和sql查询  做大数据或数据分析的人员应该都非常熟悉Hive吧,它是一款强大的数据分析工具,就是类sql查询语句,可以把复杂的...

    Hive 的使用操作方法-表创建,删除,分区的增删,修改表结构,重命名,行列互转和sql查询

              做大数据或数据分析的人员应该都非常熟悉Hive吧,它是一款强大的数据分析工具,就是类sql查询语句,可以把复杂的MapReduce任务转换为sql查询,方便了数据分析人员快速定位分析结果。hive是Apache软件基金会的开源的数据分析工具,功能强大,包括直接分析出结果,做ETL中的数据清洗,预处理等等。

              本文不讲述hive如何下载,安装,配置,具体的操作网上都有的,可以查询到。本文以介绍hive的表创建,删除,增加表分区,删除表分区,表结构的修改,重命名和行列互转,包括一些常用的sql函数。

           1. hive表创建(和一般关系数据库的语法基本一致)

        

    目录

    Hive 的使用操作方法-表创建,删除,分区的增删,修改表结构,重命名,行列互转和sql查询


     

    CREATE [EXTERNAL] TABLE [IF NOT EXISTS] table_name
      [(col_name data_type [COMMENT col_comment], ...)]
      [COMMENT table_comment]
      [PARTITIONED BY (col_name data_type
        [COMMENT col_comment], ...)]
      [CLUSTERED BY (col_name, col_name, ...)
      [SORTED BY (col_name [ASC|DESC], ...)]
      INTO num_buckets BUCKETS]
      [ROW FORMAT row_format]
      [STORED AS file_format]
      [LOCATION hdfs_path]

    对于创建表的语句说明:

    CREATE TABLE 创建一个指定名字的表。如果相同名字的表已经存在,则抛出异常;用户可以用 IF NOT EXIST 选项来忽略这个异常。

    EXTERNAL 关键字可以让用户创建一个外部表,在建表的同时指定一个指向实际数据的路径(LOCATION),Hive 创建内部表时,会将数据移动到数据仓库指向的路径;若创建外部表,仅记录数据所在的路径,不对数据的位置做任何改变。在删除表的时候,内部表的元数据和数据会被一起删除,而外部表只删除元数据,不删除数据。

    LIKE 允许用户复制现有的表结构,但是不复制数据。

    用户在建表的时候可以自定义 SerDe 或者使用自带的 SerDe。如果没有指定 ROW FORMAT 或者 ROW FORMAT DELIMITED,将会使用自带的 SerDe。在建表的时候,用户还需要为表指定列,用户在指定表的列的同时也会指定自定义的 SerDe,Hive 通过 SerDe 确定表的具体的列的数据。

    如果文件数据是纯文本,可以使用 STORED AS TEXTFILE。如果数据需要压缩,使用 STORED AS SEQUENCE 。

    有分区的表可以在创建的时候使用 PARTITIONED BY 语句。一个表可以拥有一个或者多个分区,每一个分区单独存在一个目录下。而且,表和分区都可以对某个列进行 CLUSTERED BY 操作,将若干个列放入一个桶(bucket)中。也可以利用SORT BY 对数据进行排序。这样可以为特定应用提高性能。

    表名和列名不区分大小写,SerDe 和属性名区分大小写。表和列的注释是字符串 。

    2   删除表和表结构的修改

     

    Drop Table

    删除一个内部表的同时会同时删除表的元数据和数据。删除一个外部表,只删除元数据而保留数据。

    Alter Table

    Alter table 语句允许用户改变现有表的结构。用户可以增加列/分区,改变serde,增加表和 serde 熟悉,表本身重命名。

    Add Partitions

    ALTER TABLE table_name ADD
      partition_spec [ LOCATION 'location1' ]
      partition_spec [ LOCATION 'location2' ] ...

    partition_spec:
      : PARTITION (partition_col = partition_col_value,
         partition_col = partiton_col_value, ...)

    用户可以用 ALTER TABLE ADD PARTITION 来向一个表中增加分区。当分区名是字符串时加引号。

      ALTER TABLE page_view ADD
        PARTITION (dt='2008-08-08', country='us')
          location '/path/to/us/part080808'
        PARTITION (dt='2008-08-09', country='us')
          location '/path/to/us/part080809';

    DROP PARTITION

    ALTER TABLE table_name DROP
        partition_spec, partition_spec,...

    用户可以用 ALTER TABLE DROP PARTITION 来删除分区。分区的元数据和数据将被一并删除。

    ALTER TABLE page_view
        DROP PARTITION (dt='2008-08-08', country='us');

    RENAME TABLE

    ALTER TABLE table_name RENAME TO new_table_name

    这个命令可以让用户为表更名。数据所在的位置和分区名并不改变。换而言之,老的表名并未“释放”,对老表的更改会改变新表的数据。

    Change Column Name/Type/Position/Comment

    ALTER TABLE table_name C [COLUMN]
      col_old_name col_new_name column_type
        [COMMENT col_comment]
        [FIRST|AFTER column_name]

    这个命令可以允许用户修改一个列的名称、数据类型、注释或者位置。

        CREATE TABLE test_change (a int, b int, c int); ALTER TABLE test_change CHANGE a a1 STRING;

       将 a 列的名字改为 a1,数据类型改成string.

      ALTER TABLE test_change CHANGE a a1 STRING AFTER b;

    将 a 列的名字改为 a1,a 列的数据类型改为 string,并将它放置在列 b 之后。

    新的表结构为:

    b int, a1 string, c int. ALTER TABLE test_change CHANGE b b1 INT FIRST;

    会将 b 列的名字修改为 b1, 并将它放在第一列。

    新表的结构为: b1 int, a string, c int.

         注意:对列的改变只会修改 Hive 的元数据,而不会改变实际数据。用户应该确定保证元数据定义和实际数据结构的一致性。

    添加/替换 列

    Add/Replace Columns

    ALTER TABLE table_name ADD|REPLACE
      COLUMNS (col_name data_type [COMMENT col_comment], ...)
    

    ADD COLUMNS 允许用户在当前列的末尾增加新的列,但是在分区列之前。

    REPLACE COLUMNS 删除以后的列,加入新的列。只有在使用 native 的 SerDE(DynamicSerDe or MetadataTypeColumnsetSerDe)的时候才可以这么做。

    Alter Table Properties

    ALTER TABLE table_name SET TBLPROPERTIES table_properties
    table_properties:
      : (property_name = property_value, property_name = property_value, ... )
    

    用户可以用这个命令向表中增加 metadata,目前 last_modified_user,last_modified_time 属性都是由 Hive 自动管理的。用户可以向列表中增加自己的属性。可以使用 DESCRIBE EXTENDED TABLE 来获得这些信息

            增加序列化属性

    Add Serde Properties

    ALTER TABLE table_name
        SET SERDE serde_class_name
        [WITH SERDEPROPERTIES serde_properties]
    
    ALTER TABLE table_name
        SET SERDEPROPERTIES serde_properties
    
    serde_properties:
      : (property_name = property_value,
        property_name = property_value, ... )
    

    这个命令允许用户向 SerDe 对象增加用户定义的元数据。Hive 为了序列化和反序列化数据,将会初始化 SerDe 属性,并将属性传给表的 SerDe。如此,用户可以为自定义的 SerDe 存储属性

            

    Alter Table File Format and Organization

    ALTER TABLE table_name SET FILEFORMAT file_format
    ALTER TABLE table_name CLUSTERED BY (col_name, col_name, ...)
      [SORTED BY (col_name, ...)] INTO num_buckets BUCKETS
    

    这个命令修改了表的物理存储属性。

    Loading files into table

    当数据被加载至表中时,不会对数据进行任何转换。Load 操作只是将数据复制/移动至 Hive 表对应的位置。

    Syntax:

    LOAD DATA [LOCAL] INPATH 'filepath' [OVERWRITE]
        INTO TABLE tablename
        [PARTITION (partcol1=val1, partcol2=val2 ...)]
    

    Synopsis:

    Load 操作只是单纯的复制/移动操作,将数据文件移动到 Hive 表对应的位置。

    • filepath 可以是:
      • 相对路径,例如:project/data1
      • 绝对路径,例如: /user/hive/project/data1
      • 包含模式的完整 URI,例如:hdfs://namenode:9000/user/hive/project/data1
    • 加载的目标可以是一个表或者分区。如果表包含分区,必须指定每一个分区的分区名。
    • filepath 可以引用一个文件(这种情况下,Hive 会将文件移动到表所对应的目录中)或者是一个目录(在这种情况下,Hive 会将目录中的所有文件移动至表所对应的目录中)。
    • 如果指定了 LOCAL,那么:
      • load 命令会去查找本地文件系统中的 filepath。如果发现是相对路径,则路径会被解释为相对于当前用户的当前路径。用户也可以为本地文件指定一个完整的 URI,比如:file:///user/hive/project/data1.
      • load 命令会将 filepath 中的文件复制到目标文件系统中。目标文件系统由表的位置属性决定。被复制的数据文件移动到表的数据对应的位置。
    • 如果没有指定 LOCAL 关键字,如果 filepath 指向的是一个完整的 URI,hive 会直接使用这个 URI。 否则:
      • 如果没有指定 schema 或者 authority,Hive 会使用在 hadoop 配置文件中定义的 schema 和 authority,fs.default.name 指定了 Namenode 的 URI。
      • 如果路径不是绝对的,Hive 相对于 /user/ 进行解释。
      • Hive 会将 filepath 中指定的文件内容移动到 table (或者 partition)所指定的路径中。
    • 如果使用了 OVERWRITE 关键字,则目标表(或者分区)中的内容(如果有)会被删除,然后再将 filepath 指向的文件/目录中的内容添加到表/分区中。
    • 如果目标表(分区)已经有一个文件,并且文件名和 filepath 中的文件名冲突,那么现有的文件会被新文件所替代。
    • 查询语句:  Select  

             

    SELECT [ALL | DISTINCT] select_expr, select_expr, ...
      FROM table_reference
      [WHERE where_condition]
      [GROUP BY col_list]
      [
        CLUSTER BY col_list
        | [DISTRIBUTE BY col_list]
        [SORT BY col_list]
      ]
    [LIMIT number]
    
    • 一个SELECT语句可以是一个union查询或一个子查询的一部分。
    • table_reference是查询的输入,可以是一个普通表、一个视图、一个join或一个子查询
    • 简单查询。例如,下面这一语句从t1表中查询所有列的信息。
    SELECT * FROM t1
    

    WHERE Clause

    where condition 是一个布尔表达式。例如,下面的查询语句只返回销售记录大于 10,且归属地属于美国的销售代表。Hive 不支持在WHERE 子句中的 IN,EXIST 或子查询。

    SELECT * FROM sales WHERE amount > 10 AND region = "US"
    

    ALL and DISTINCT Clauses

    使用ALL和DISTINCT选项区分对重复记录的处理。默认是ALL,表示查询所有记录。DISTINCT表示去掉重复的记录。

    基于Partition 分区的查询

    一般 SELECT 查询会扫描整个表(除非是为了抽样查询)。但是如果一个表使用 PARTITIONED BY 子句建表,查询就可以利用分区剪枝(input pruning)的特性,只扫描一个表中它关心的那一部分。Hive 当前的实现是,只有分区断言出现在离 FROM 子句最近的那个WHERE 子句中,才会启用分区剪枝。例如,如果 page_views 表使用 date 列分区,以下语句只会读取分区为‘2008-03-01’的数据.  

    SELECT page_views.*
        FROM page_views
        WHERE page_views.date >= '2008-03-01'
          AND page_views.date <= '2008-03-31';

    常用SQL 函数 

    HAVING Clause

    Hive 现在不支持 HAVING 子句。可以将 HAVING 子句转化为一个字查询,例如:

    SELECT col1 FROM t1 GROUP BY col1 HAVING SUM(col2) > 10
    

    可以用以下查询来表达:

    SELECT col1 FROM (SELECT col1, SUM(col2) AS col2sum
      FROM t1 GROUP BY col1) t2
      WHERE t2.col2sum > 10
    

    LIMIT Clause

    Limit 可以限制查询的记录数。查询的结果是随机选择的。下面的查询语句从 t1 表中随机查询5条记录:

    SELECT * FROM t1 LIMIT 5
    

    Top k 查询。下面的查询语句查询销售记录最大的 5 个销售代表。

    SET mapred.reduce.tasks = 1
      SELECT * FROM sales SORT BY amount DESC LIMIT 5
    

    REGEX Column Specification

    SELECT 语句可以使用正则表达式做列选择,下面的语句查询除了 ds 和 hr 之外的所有列:

    SELECT `(ds|hr)?+.+` FROM sales

    JOIN 连接查询案例

    Join

    Syntax

    join_table:
        table_reference JOIN table_factor [join_condition]
      | table_reference {LEFT|RIGHT|FULL} [OUTER]
        JOIN table_reference join_condition
      | table_reference LEFT SEMI JOIN
          table_reference join_condition
    
    table_reference:
        table_factor
      | join_table
    
    table_factor:
        tbl_name [alias]
      | table_subquery alias
      | ( table_references )
    
    join_condition:
        ON equality_expression ( AND equality_expression )*
    
    equality_expression:
        expression = expression
    

    Hive 只支持等值连接(equality joins)、外连接(outer joins)和(left semi joins???)。Hive 不支持所有非等值的连接,因为非等值连接非常难转化到 map/reduce 任务。另外,Hive 支持多于 2 个表的连接。

     

    写 join 查询时,需要注意几个关键点:
    1. 只支持等值join,例如:

      SELECT a.* FROM a JOIN b ON (a.id = b.id)
      SELECT a.* FROM a JOIN b
        ON (a.id = b.id AND a.department = b.department)
    

    是正确的,然而:

      SELECT a.* FROM a JOIN b ON (a.id  b.id)
    

    是错误的。

    2. 可以 join 多于 2 个表,例如

      SELECT a.val, b.val, c.val FROM a JOIN b
        ON (a.key = b.key1) JOIN c ON (c.key = b.key2)
    

    如果join中多个表的 join key 是同一个,则 join 会被转化为单个 map/reduce 任务,例如:

      SELECT a.val, b.val, c.val FROM a JOIN b
        ON (a.key = b.key1) JOIN c
        ON (c.key = b.key1)
    

    被转化为单个 map/reduce 任务,因为 join 中只使用了 b.key1 作为 join key。

    SELECT a.val, b.val, c.val FROM a JOIN b ON (a.key = b.key1)
      JOIN c ON (c.key = b.key2)
    

    而这一 join 被转化为 2 个 map/reduce 任务。因为 b.key1 用于第一次 join 条件,而 b.key2 用于第二次 join。

    join 时,每次 map/reduce 任务的逻辑是这样的:reducer 会缓存 join 序列中除了最后一个表的所有表的记录,再通过最后一个表将结果序列化到文件系统。这一实现有助于在 reduce 端减少内存的使用量。实践中,应该把最大的那个表写在最后(否则会因为缓存浪费大量内存)。例如:

     SELECT a.val, b.val, c.val FROM a
        JOIN b ON (a.key = b.key1) JOIN c ON (c.key = b.key1)
    

    所有表都使用同一个 join key(使用 1 次 map/reduce 任务计算)。Reduce 端会缓存 a 表和 b 表的记录,然后每次取得一个 c 表的记录就计算一次 join 结果,类似的还有:

      SELECT a.val, b.val, c.val FROM a
        JOIN b ON (a.key = b.key1) JOIN c ON (c.key = b.key2)
    

    这里用了 2 次 map/reduce 任务。第一次缓存 a 表,用 b 表序列化;第二次缓存第一次 map/reduce 任务的结果,然后用 c 表序列化。

    LEFT,RIGHT 和 FULL OUTER 关键字用于处理 join 中空记录的情况,例如:

      SELECT a.val, b.val FROM a LEFT OUTER
        JOIN b ON (a.key=b.key)
    

    对应所有 a 表中的记录都有一条记录输出。输出的结果应该是 a.val, b.val,当 a.key=b.key 时,而当 b.key 中找不到等值的 a.key 记录时也会输出 a.val, NULL。“FROM a LEFT OUTER JOIN b”这句一定要写在同一行——意思是 a 表在 b 表的左边,所以 a 表中的所有记录都被保留了;“a RIGHT OUTER JOIN b”会保留所有 b 表的记录。OUTER JOIN 语义应该是遵循标准 SQL spec的。

    Join 发生在 WHERE 子句之前。如果你想限制 join 的输出,应该在 WHERE 子句中写过滤条件——或是在 join 子句中写。这里面一个容易混淆的问题是表分区的情况:

      SELECT a.val, b.val FROM a
      LEFT OUTER JOIN b ON (a.key=b.key)
      WHERE a.ds='2009-07-07' AND b.ds='2009-07-07'
    

    会 join a 表到 b 表(OUTER JOIN),列出 a.val 和 b.val 的记录。WHERE 从句中可以使用其他列作为过滤条件。但是,如前所述,如果 b 表中找不到对应 a 表的记录,b 表的所有列都会列出 NULL,包括 ds 列。也就是说,join 会过滤 b 表中不能找到匹配 a 表 join key 的所有记录。这样的话,LEFT OUTER 就使得查询结果与 WHERE 子句无关了。解决的办法是在 OUTER JOIN 时使用以下语法:

      SELECT a.val, b.val FROM a LEFT OUTER JOIN b
      ON (a.key=b.key AND
          b.ds='2009-07-07' AND
          a.ds='2009-07-07')
    

    这一查询的结果是预先在 join 阶段过滤过的,所以不会存在上述问题。这一逻辑也可以应用于 RIGHT 和 FULL 类型的 join 中。

    Join 是不能交换位置的。无论是 LEFT 还是 RIGHT join,都是左连接的。

      SELECT a.val1, a.val2, b.val, c.val
      FROM a
      JOIN b ON (a.key = b.key)
      LEFT OUTER JOIN c ON (a.key = c.key)
    

    先 join a 表到 b 表,丢弃掉所有 join key 中不匹配的记录,然后用这一中间结果和 c 表做 join。这一表述有一个不太明显的问题,就是当一个 key 在 a 表和 c 表都存在,但是 b 表中不存在的时候:整个记录在第一次 join,即 a JOIN b 的时候都被丢掉了(包括a.val1,a.val2和a.key),然后我们再和 c 表 join 的时候,如果 c.key 与 a.key 或 b.key 相等,就会得到这样的结果:NULL, NULL, NULL, c.val。

    LEFT SEMI JOIN 是 IN/EXISTS 子查询的一种更高效的实现。Hive 当前没有实现 IN/EXISTS 子查询,所以你可以用 LEFT SEMI JOIN 重写你的子查询语句。LEFT SEMI JOIN 的限制是, JOIN 子句中右边的表只能在 ON 子句中设置过滤条件,在 WHERE 子句、SELECT 子句或其他地方过滤都不行。

      SELECT a.key, a.value
      FROM a
      WHERE a.key in
       (SELECT b.key
        FROM B);
    

    可以被重写为:

       SELECT a.key, a.val
       FROM a LEFT SEMI JOIN b on (a.key = b.key)
    说明:  知识只有共享才能传播,才能推崇出新的知识,才能学到更多,参考了一些hive官方的介绍和一些博客的精选内容介绍,再此感谢作者的总结。

     

     

    展开全文
  • ABP默认表结构解析

    千次阅读 2020-04-01 21:45:32
    说明:此版本的表结构基于github上的tag版本号——v5.4。以下内容是通过官网下载的项目还原及相关网络文章参考而来,也有部分是自己的理解。如有不当的地方,也欢迎大家指正。 表的具体说明 表名:...

    说明:此版本的表结构基于github上的tag版本号——v5.4。以下内容是通过官网下载的项目还原及相关网络文章参考而来,也有部分是自己的理解。如有不当的地方,也欢迎大家指正。

     

    表的具体说明

     

    表名:AbpAuditLogs

    作用:用于存储审计日志的相关信息

    源码位置位于Abp.Zero.Common——Application——Auditing下,类名:AuditLog: Entity<long>, IMayHaveTenant。

    实时记录访问服务,方法等等信息,结合日志功能,方便生产环境中的问题追踪。

     

     

    表名:AbpBackgroundJobs

    作用:记录用于持久化作业的后台作业信息

    源码位置位于Abp——BackgroundJobs下,类名:BackgroundJobInfo: CreationAuditedEntity<long>。

    在使用定时任务(如Quartz.net)的时候,可以把作业放在此表。可根据具体的框架扩展表字段。其中,优先级通过定义枚举实现的。如下图所示:

     

     

    表名:AbpEditions

    作用:记录应用程序的版本信息

    源码位置位于Abp.Zero.Common——Application——Editions下,类名:Edition : FullAuditedEntity。

    仅仅在类中定义了版本的唯一名称和版本的显示名称,唯一名称默认是GUID去掉‘-’的值(代码层面,非数据库中的)。其他字段通过实现接口等方式获取。创建后有一条种子数据。默认的显示名和唯一名都是Standard

     

     

    表名:AbpEntityChanges

    作用:记录实体更改的相关信息

    源码位置位于Abp——EntityHistory下,类名:EntityChange: Entity<long>, IMayHaveTenant。

    后期补充的表(文末参考【1】中的文章里面没有此表)。和AbpEntityChangeSets是多对以关系,和AbpEntityPropertyChanges是一对多关系。暂时不清楚是出于什么目的设计的。

     

     

    表名:AbpEntityChangeSets

    作用:记录实体更改集合的相关信息

    源码位置位于Abp——EntityHistory下,类名:EntityChangeSet: Entity<long>, IHasCreationTime, IMayHaveTenant, IExtendableObject。

    后期补充的表(文末参考【1】中的文章里面没有此表)。关系同上。暂时不清楚是出于什么目的设计的。

     

     

    表名:AbpEntityPropertyChanges

    作用:记录实体属性更改的相关信息

    源码位置位于Abp——EntityHistory下,类名:EntityPropertyChange: Entity<long>, IMayHaveTenant。

    后期补充的表(文末参考【1】中的文章里面没有此表)。关系同上。暂时不清楚是出于什么目的设计的。

     

     

    表名:AbpFeatures

    作用:记录特征设置的基本信息(版本的)

    源码位置位于Abp.Zero.Common——Application——Features下,类名:FeatureSetting: CreationAuditedEntity<long>, IMayHaveTenant。

    仅仅在类中定义了特征名称和特征值,其他字段(除了EditionId和Discriminator)通过实现接口的方式获取。EditionId是外键,在其子类EditionFeatureSetting中添加的;Discriminator在生成映射(FeatureSettingMap类构造函数中)时添加的,用于鉴别子类?(FluentNHibernate.Mapping下有映射类定义)。对于中小系统,感觉这个表根本用不到。

     

     

    表名:AbpLanguages

    作用:记录应用程序的语言

    源码位置位于Abp.Zero.Common——Localization下,类名:ApplicationLanguage: FullAuditedEntity, IMayHaveTenant。

    此类是可序列化的。有初始化了种子数据,定义相关语言信息。此处定义的只是语言的基本信息,不是系统设置的显示语言。

     

     

    表名:AbpLanguageTexts

    作用:用于存储本地化文本的相关信息

    源码位置位于Abp.Zero.Common——Localization下,类名:ApplicationLanguageText : AuditedEntity<long>, IMayHaveTenant。

    此类是可序列化的。本地化的处理大多数都是通过定义xml文件的形式完成,但是也可将其数据保存到此表中完成。

     

     

    表名:AbpNotifications

    作用:用于存储通知请求,此通知是发给租户/用户的

    源码位置位于Abp——Notifications下,类名:NotificationInfo : CreationAuditedEntity<Guid>。

    此类是可序列化的。和下一个通知订阅表有点类似,只不过此表主要记录通知信息。通知类的几个表应该都是为SignalR而准备的。其中通知的严重性,或者说优先级是通过枚举定义的,如下图所示:

     

     

    表名:AbpNotificationSubscriptions

    作用:用于存储通知订阅的相关信息

    源码位置位于Abp——Notifications下,类名:NotificationSubscriptionInfo : CreationAuditedEntity<Guid>, IMayHaveTenant。

    和上面的通知表类似,只不过此表主要记录租户、用户订阅的通知。

     

     

    表名:AbpOrganizationUnitRoles

    作用:记录用户对组织单元的成员资格的相关信息

    源码位置位于Abp.Zero.Common——Organizations下,类名:OrganizationUnitRole : CreationAuditedEntity<long>, IMayHaveTenant, ISoftDelete。

    和下面的AbpOrganizationUnits表是多对一的关系。后期补充的表(文末参考中的文章里面没有此表)。和表AbpUserOrganizationUnits的作用类似,即此角色是否属于指定的单元组织,但是不知道为什么没有叫AbpRoleOrganizationUnits。(呵呵)

     

     

    表名:AbpOrganizationUnits

    作用:记录一个组织单元(OU)的相关信息

    源码位置位于Abp.Zero.Common——Organizations下,类名:OrganizationUnit : FullAuditedEntity<long>, IMayHaveTenant。

    和AbpOrganizationUnitRoles、AbpUserOrganizationUnits表是一对多关系。仅仅是组织机构的基本信息,不涉及业务逻辑。

     

     

    表名:AbpPermissions

    作用:记录用于授予/拒绝角色或用户的权限的相关信息

    源码位置位于Abp.Zero.Common——Authorization下,类名:PermissionSetting : CreationAuditedEntity<long>, IMayHaveTenant。

    记录用户、角色和租户的相关权限授予/拒绝信息,但是这个三个字段均可为空。授权默认为true(代码中的)。Abp框架默认给出了权限的保存(新增和修改)方法,检查权限一般使用特性的方式。其创建后就有默认的种子数据。

     

     

    表名:AbpRoleClaims

    作用:记录角色Claim的相关信息

    源码位置位于Abp.Zero.Common——Authorization——Roles下,类名:RoleClaim : CreationAuditedEntity<long>, IMayHaveTenant。

    后期补充的表(文末参考【1】中的文章里面没有此表),具体上不知道干嘛的。一般来讲,微软自带的身份认证里有这个(Claims)类似对象,但是在角色上,不知道要怎么用。

     

     

    表名:AbpRoles

    作用:记录角色的基本信息

    源码位置位于Abp.Zero.Common——Authorization——Roles下,类名:AbpRoleBase : FullAuditedEntity<int>, IMayHaveTenant。

    创建表时插入两条种子数据,一条和租户关联,否默认角色,另一条不和租户关联,但是是默认角色。如果标注为默认角色,系统会自动分配给新用户。Bool类型字段默认都是false。

     

     

    表名:AbpSettings

    作用:记录租户或用户的设置的相关信息

    源码位置位于Abp.Zero.Common——Configuration下,类名:Setting : AuditedEntity<long>, IMayHaveTenant。

    有默认种子数据。默认是添加电子邮件地址和收件人显示名称,还有一个默认语言——en。似乎关于用户和租户的设置,除了一些可以放在配置文件中,有些最后放在此表中,感觉上此表和AbpLanguageTexts表有点类似的作用。

     

     

    表名:AbpTenantNotifications

    作用:记录分发给相关租户的通知的相关信息

    源码位置位于Abp——Notifications下,类名:TenantNotificationInfo : CreationAuditedEntity<Guid>, IMayHaveTenant。

    和上面提到的通知表类似,此表关注的租户的。不知道此表的设计目的什么,感觉用AbpNotifications表即可,只是去掉了此表的用户相关字段。

     

     

    表名:AbpTenants

    作用:记录基本的租户信息

    源码位置位于Abp.Zero.Common——MultiTenancy下,类名:AbpTenantBase : FullAuditedEntity<int>, IPassivable。

    在生成前加入了AbpEditions表Id作为外键,默认生成一条种子数据,租户名称为Default。多租户支持(每个租户的数据自动隔离,业务模块开发者不需要在保存和查询数时写相应代码)。

     

     

    表名:AbpUserAccounts

    作用:记录摘要用户的相关信息

    源码位置位于Abp.Zero.Common——Authorization——Users下,类名:UserAccount : FullAuditedEntity<long>。

    默认有两条种子数据。不知道这个表用作是什么。

     

     

    表名:AbpUserClaims

    作用:记录用户Claim的相关信息

    源码位置位于Abp.Zero.Common——Authorization——Users下,类名:UserClaim : CreationAuditedEntity<long>, IMayHaveTenant。

    应该是使用微软自带的授权认证,记录其声明相关信息的。角色的那个类似表目标相似。

     

     

    表名:AbpUserLoginAttempts

    作用:用于保存用户的登录尝试的相关信息

    源码位置位于Abp.Zero.Common——Authorization——Users下,类名:UserLoginAttempt : Entity<long>, IHasCreationTime, IMayHaveTenant。

    通过用户名,密码登录的用户信息,记录登录的结果等信息(不管是成功还是失败)。

     

     

    表名:AbpUserLogins

    作用:用于存储用于外部登录服务的用户登录的相关信息

    源码位置位于Abp.Zero.Common——Authorization——Users下,类名:UserLogin : Entity<long>, IMayHaveTenant。

    默认没有数据,猜测是第三方登录的信息记录。

     

     

    表名:AbpUserNotifications

    作用:用于存储用户通知的相关信息

    源码位置位于Abp——Notifications下,类名:UserNotificationInfo : Entity<Guid>, IHasCreationTime, IMayHaveTenant

    默认没有数据。专注于用户通知的记录,其中包含了租户通知id字段,虽然源码中没有标识出是AbpTenantNotifications表的外键,但是猜测应该是的。另外,通知的状态由枚举定义,主要记录用户是否已经读取通知两种状态。如下图所示:

     

     

    表名:AbpUserOrganizationUnits

    作用:记录用户对组织单元(OU)的成员资格的相关信息

    源码位置位于Abp.Zero.Common——Authorization——Users下,类名:UserOrganizationUnit : CreationAuditedEntity<long>, IMayHaveTenant, ISoftDelete。

    和AbpOrganizationUnits表是多对一的关系。即此用户是否属于指定的组织单元,或者在哪个部门(通俗的说)。

     

     

    表名:AbpUserRoles

    作用:记录用户和角色之间关系的信息

    源码位置位于Abp.Zero.Common——Authorization——Users下,类名:UserRole : CreationAuditedEntity<long>, IMayHaveTenant。

     

     

    表名:AbpUsers

    作用:记录用户的基本信息

    源码位置位于Abp.Zero.Common——Authorization——Users下,类名:AbpUserBase : FullAuditedEntity<long>, IMayHaveTenant, IPassivable。

    默认用户为admin,作为种子数据加入。删除了LastLoginTime字段(参考【1】)?主要是登录用户的信息,不怎么涉及业务用户的情况。其中说明了是多个表的外键。

     

     

    表名:AbpUserTokens

    作用:记录用户的身份验证令牌的相关信息

    源码位置位于Abp.ZeroCore——Authorization——Users下,类名:UserToken : Entity<long>, IMayHaveTenant。

    后期补充的表(文末参考【1】中的文章里面没有此表)。应该主要是api要用的,记录令牌的相关消息。

     

     

    表名:AbpWebhookEvents

    作用:记录存储创建的web挂钩的相关信息

    源码位置位于Abp——Webhooks下,类名:WebhookEvent : Entity<Guid>, IMayHaveTenant, IHasCreationTime, IHasDeletionTime。

    后期补充的表(文末参考【1】中的文章里面没有此表)。具体不知道作用是什么。

     

     

    表名:AbpWebhookSendAttempts

    作用:记录存储的webhook工作项的相关信息

    源码位置位于Abp——Webhooks下,类名:WebhookSendAttempt : Entity<Guid>, IMayHaveTenant, IHasCreationTime, IHasModificationTime。

    后期补充的表(文末参考【1】中的文章里面没有此表)。具体不知道作用是什么。其中对表AbpWebhookEvents的关联有明确的定义,但是对表AbpWebhookSubscriptions没有,猜测是WebhookSubscriptionId外键。

     

     

    表名:AbpWebhookSubscriptions

    作用:记录webhook的订阅信息

    源码位置位于Abp——Webhooks下,类名:WebhookSubscriptionInfo : CreationAuditedEntity<Guid>, IPassivable。

    后期补充的表(文末参考【1】中的文章里面没有此表)。具体不知道作用是什么。

     

     

    关于外键的说明

    大多数的表中都有租户id、用户id(其他少量出现的就不一一举例了),除了有的类中明确给出了是对应哪个表的外键的,其他都是没有明确说明的。如租户id,都是通过接口获取的。有明确说的,上面我都明确标出来了。对于没有明确指定的,个人觉得也可以把它们当成外键处理。只是可能没有在数据库中,或者代码中有相关的关联关系。

     

    对时间定义的简单说明

    DateTime字段类型对应的时间格式是 yyyy-MM-dd HH:mm:ss.fff ,3个f,精确到1毫秒(ms),示例 2014-12-03 17:06:15.433 。

    DateTime2字段类型对应的时间格式是 yyyy-MM-dd HH:mm:ss.fffffff ,7个f,精确到0.1微秒(μs),示例 2014-12-03 17:23:19.2880929 。

    如果用SQL的日期函数进行赋值,DateTime字段类型要用 GETDATE() ,DateTime2字段类型要用 SYSDATETIME() 。

     

    参考

    【1】http://www.mamicode.com/info-detail-2018026.html

    【2】https://www.cnblogs.com/dudu/p/sql-server-datetime-vs-datetime2.html

    展开全文
  • WordPress数据库及各表结构

    千次阅读 2017-11-06 14:31:58
    数据库表结构

    转载:http://blog.csdn.net/ppiao1970hank/article/details/6301812

    WordPress使用MySQL数据库。作为一个开发者,我们有必要掌握WordPress数据库的基本构造,并在自己的插件或主题中使用他们。
    截至WordPress3.0,WordPress一共有以下11个表。这里加上了默认的表前缀 wp_ 。
    wp_commentmeta:存储评论的元数据
    wp_comments:存储评论
    wp_links:存储友情链接(Blogroll)
    wp_options:存储WordPress系统选项和插件、主题配置
    wp_postmeta:存储文章(包括页面、上传文件、修订)的元数据
    wp_posts:存储文章(包括页面、上传文件、修订)
    wp_terms:存储每个目录、标签
    wp_term_relationships:存储每个文章、链接和对应分类的关系
    wp_term_taxonomy:存储每个目录、标签所对应的分类
    wp_usermeta:存储用户的元数据
    wp_users:存储用户
    在WordPress的数据库结构中,存储系统选项和插件配置的wp_options表是比较独立的结构,在后文中会提到,它采用了key-value模式存储,这样做的好处是易于拓展,各个插件都可以轻松地在这里存储自己的配置。
    post,comment,user 则是三个基本表加上拓展表的组合。以wp_users为例,wp_users已经存储了每个用户会用到的基本信息,比如 login_name、display_name、 password、email等常用信息,但如果我们还要存储一些不常用的数据,最好的做法不是去在表后加上一列,去破坏默认的表结构,而是将数据存在wp_usermeta中。wp_usermeta这个拓展表和wp_options表有类似的结构,我们可以在这里存储每个用户的QQ号码、手机号码、登录WordPress后台的主题选项等等。
    比较难以理解的是term,即wp_terms、wp_term_relationships、wp_term_taxonomy。在WordPress的系统里,我们常见的分类有文章的分类、链接的分类,实际上还有TAG,它也是一种特殊的分类方式,我们甚至还可以创建自己的分类方法。WordPress将所有的分类及分类方法、对应结构都记录在这三个表中。wp_terms记录了每个分类的名字以及基本信息,如本站分为“WordPress开发”、“WPCEO插件”等,这里的分类指广义上的分类,所以每个TAG也是一个“分类”。wp_term_taxonomy记录了每个分类所归属的分类方法,如“WordPress开发”、“WPCEO插件”是文章分类(category),放置友情链接的“我的朋友”、“我的同事”分类属于友情链接分类(link_category)。wp_term_relationships记录了每个文章(或链接)所对应的分类方法。
    庆幸的是,关于term的使用,WordPress中相关函数的使用方法还是比较清晰明了,我们就没必要纠结于它的构造了。

    在上文中我们已经介绍了WordPress数据库中各个表的作用,本文将继续介绍每个表中每个列的作用。WordPress官方文档已经有比较详细的表格,本文仅对常用数据进行介绍。
    wp_commentmeta
    meta_id:自增唯一ID
    comment_id:对应评论ID
    meta_key:键名
    meta_value:键值

    wp_comments
    comment_ID:自增唯一ID
    comment_post_ID:对应文章ID
    comment_author:评论者
    comment_author_email:评论者邮箱
    comment_author_url:评论者网址
    comment_author_IP:评论者IP
    comment_date:评论时间
    comment_date_gmt:评论时间(GMT+0时间)
    comment_content:评论正文
    comment_karma:未知
    comment_approved:评论是否被批准
    comment_agent:评论者的USER AGENT
    comment_type:评论类型(pingback/普通)
    comment_parent:父评论ID
    user_id:评论者用户ID(不一定存在)

    wp_links
    link_id:自增唯一ID
    link_url:链接URL
    link_name:链接标题
    link_image:链接图片
    link_target:链接打开方式
    link_description:链接描述
    link_visible:是否可见(Y/N)
    link_owner:添加者用户ID
    link_rating:评分等级
    link_updated:未知
    link_rel:XFN关系
    link_notes:XFN注释
    link_rss:链接RSS地址

    wp_options
    option_id:自增唯一ID
    blog_id:博客ID,用于多用户博客,默认0
    option_name:键名
    option_value:键值
    autoload:在WordPress载入时自动载入(yes/no)

    wp_postmeta
    meta_id:自增唯一ID
    post_id:对应文章ID
    meta_key:键名
    meta_value:键值

    wp_posts
    ID:自增唯一ID
    post_author:对应作者ID
    post_date:发布时间
    post_date_gmt:发布时间(GMT+0时间)
    post_content:正文
    post_title:标题
    post_excerpt:摘录
    post_status:文章状态(publish/auto-draft/inherit等)
    comment_status:评论状态(open/closed)
    ping_status:PING状态(open/closed)
    post_password:文章密码
    post_name:文章缩略名
    to_ping:未知
    pinged:已经PING过的链接
    post_modified:修改时间
    post_modified_gmt:修改时间(GMT+0时间)
    post_content_filtered:未知
    post_parent:父文章,主要用于PAGE
    guid:未知
    menu_order:排序ID
    post_type:文章类型(post/page等)
    post_mime_type:MIME类型
    comment_count:评论总数

    wp_terms
    term_id:分类ID
    name:分类名
    slug:缩略名
    term_group:未知

    wp_term_relationships
    object_id:对应文章ID/链接ID
    term_taxonomy_id:对应分类方法ID
    term_order:排序

    wp_term_taxonomy
    term_taxonomy_id:分类方法ID
    term_id:taxonomy:分类方法(category/post_tag)
    description:未知
    parent:所属父分类方法ID
    count:文章数统计

    wp_usermeta
    umeta_id:自增唯一ID
    user_id:对应用户ID
    meta_key:键名
    meta_value:键值

    wp_users
    ID:自增唯一ID
    user_login:登录名
    user_pass:密码
    user_nicename:昵称
    user_email:Email
    user_url:网址
    user_registered:注册时间
    user_activation_key:激活码
    user_status:用户状态
    display_name:显示名称

    展开全文
  • 创建基本表结构

    千次阅读 2012-03-07 16:53:34
    5.3.1 创建基本表结构(1) 如下是CREATE TABLE语句的基本语法: CREATE TABLE [.][.] ( )  如果你查看在线图书,你会发现还有一大堆额外的设置项,它们可以让你把表放到一个文件组中,将表分区到多个文件组...
  • EBS常用表结构

    千次阅读 2011-05-27 17:25:00
    BOM模块常用表结构 表名: bom.bom_bill_of_materials 说明: BOM清单父项目 BILL_SEQUENCE_ID NUMBER 清单序号(关键字) ASSEMBLY_ITEM_ID NUMBER 装配件内码 ORGANIZATION_ID NUMBER 组织代码 ASSEMBLY_TYPE ...
  • WordPress表结构说明

    千次阅读 2012-08-07 11:12:56
    WordPress一共有以下11个。这里加上了默认的前缀 wp_ 。 wp_commentmeta:存储评论的元数据wp_comments:存储评论wp_links:存储友情链接(Girl is coding)wp_options:存储WordPress系统选项和插件、主题...
  • WordPress数据库及各表结构功能详解

    千次阅读 2020-09-18 08:33:57
    1、截至WordPress4.52版本,WordPress一共有以下12个。这里加上了默认的前缀 wp_ ◆ wp_commentmeta:存储评论的元数据 ◆ wp_comments:存储评论 ◆ wp_links:存储友情链接 ◆ wp_options:存储WordPress系统...
  • java数据结构与算法之顺序与链表深入分析

    万次阅读 多人点赞 2016-11-05 16:24:30
    开篇直接奔主题,无论是顺序还是链表,它们都是线性表的一种,用比较官方的话来讲,线性表是其组成元素间具有线性关系的一种线性结构,而我们恰好可以采用顺序存储和链式存储结构来表示线性表。接下来将从以下几点...
  • 用户权限管理数据库表结构设计

    千次阅读 2017-07-27 15:21:55
     B/S系统中的权限比C/S中的更显的重要,C/S系统因为具有特殊的客户端,所以访问用户的权限检测可以通过客户端实现或通过客户端+服务器检测实现,而B/S中,浏览器是每一台计算机都已具备的,如果建立一个完整的...
  • 深刻的体会到了,MongoDB可以设计集合的结构和数据类型即可使用,但代表它需要数据结构设计。一个好的系统运作,肯定需要对MongoDB的数据结构进行合理的设计才能高效运行。当然,我也建议在业务初期就进行...
  • Oracle EBS R12 AP模块主要表结构整理

    万次阅读 2013-10-17 14:34:51
    目录 1、发票:1 ...发票批AP_BATCHES_ALL. 1 1.2  发票AP_INVOICES_ALL. 1 1.3  发票分配AP_INVOICE_DISTRIBUTIONS_ALL. 3 1.4  发票接口AP_INVOICES_INTERFACE. 4 1.5  之间的关系... 5
  • 一,修改表 PostgreSQL 提供了一族命令用于修改现有表。 可以实现: 增加字段, 删除字段, 增加约束, 删除约束, 修改默认值, 重命名字段, 重命名表。 这些操作可以用:ALTER TABLE命令执行的。 1,增加字段 要...
  • 转自:...因为有客户端,没事我们也没必要通过sql语句就读取而查找表结构之类的东西。但是在以下的一些情况中可能我们就要用到了。比如:1.要写一个实体生成器的时候,我们就得读取表的字段、类型...
  • 使用alter table命令修改数据

    千次阅读 2012-03-05 11:07:19
    用ALTER TABLE 命令修改  ALTER TABLE 命令可以添加或删除的列、约束,也可以禁用或启用已存在的约束  或触发器。其语法如下:  ALTER TABLE table  { [ALTER COLUMN column_name  { new_data_type [ ...
  • ALTER SEQUENCE -- 修改一个序列生成器的定义 语法 ALTER SEQUENCE name [ INCREMENT [ BY ] increment ] [ MINVALUE minvalue | NO MINVALUE ] [ MAXVALUE maxvalue | NO MAXVALUE ] [ RESTAR
  • 很多人都将 数据库设计范式 作为数据库表结构设计“圣经”,认为只要按照这个范式需求设计,就能让设计出来的表结构足够优化,既能保证性能优异同时还能满足扩展性要求。殊不知,在N年前被奉为“圣经”的数据库...
  • 3.4 智能手表整体结构设计总结

    千次阅读 2017-07-23 18:25:58
    在智能手表设计基本遵循智能手机设计模式,通常分为市场部(以下简称MKT),外形设计部(以下简称ID),结构设计部(以下简称MD)。 分为两部分:1. 主板外购 2.主板自主研发 1. 主板外购。一个智能手表项目根据...
  • C语言实现顺序(顺序存储结构

    千次阅读 2020-01-13 16:48:04
    通过《线性表》一节的学习我们知道,线性表用于存储逻辑关系为“一对一”的数据,顺序自然也例外。 不仅如此,顺序对数据的物理存储结构也有要求。 顺序存储数据时,会提前申请一整块足够大小的物理空间,...
  • 程序开发类本科论文结构【2021年修改

    千次阅读 多人点赞 2020-02-19 18:52:45
    带论文,很多同学都知道怎么写,连结构都搞清楚。写个博文吧,方便同学们看,以后指导也方便,不用口舌去挨个讲,节约口水。 根据本专业的特色,主要是以软件(网站,游戏,前端)开发为主,我就以这为前提来做...
  • 数据结构顺序和链表的实现原理

    千次阅读 2018-07-07 16:38:32
    java数据结构与算法之顺序与链表深入分析2016年11月05日 16:24:30阅读数:14829 转载请注明出处(万分感谢!): http://blog.csdn.net/javazejian/article/details/52953190 出自【zejian的博客】关联文章:java...
  • 1、hive概述: 由Facebook开源用于解决海量结构化日志的数据统计,后称为Apache Hive为一个开源项目 --&gt;结构化数据:数据类型,字段,value---》hive--&gt;非结构化数据:比如文本、图片、音频、视频--...
  • 树形结构 数据库设计

    万次阅读 多人点赞 2015-04-30 09:46:09
    转载:逻辑数据库设计 - 单纯的树(递归关系数据) 相信有过开发经验的朋友都曾碰到过这样一个需求。... 对于这个问题,以下给出几个解决方案,各位客观可斟酌后选择。 一、邻接:依赖父节点  邻
  • 一文学懂数据结构系列之:顺序

    千次阅读 多人点赞 2021-05-08 00:27:32
    本文关键字:数据结构、基本结构、线性表、顺序结构实现。线性表的顺序存储:顺序存储的线性表,用一片地址连续的存储单元依次存放线性表中的各个数据元素。
  • SMBIOS介绍(2):结构表

    万次阅读 2010-10-03 16:50:00
    从SMBIOS 2.3版本开始,兼容SMBIOS的实现必须包含以下10个数据表结构:BIOS信息(Type 0)、系统信息(Type 1)、系统外围或底架(Type 3)、处理器信息(Type 4)、高速缓存信息(Type 7)、系统插槽(Type 9)、物理存储阵列...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 175,160
精华内容 70,064
关键字:

以下不属于修改表结构