原生sql
    $result = Db::query('select * from banner_item where banner_id = ?',[$id]) ;
构造器
    封装了对不同数据库的操作 提供了一种统一操作的语法 不需要关心不同数据库sql语法的差异性
    /**
     * Db::table('banner_item')->where('banner_id','=',$id) 返回Query对象 只有调用了执行方法才会执行语句返回结果
     * 前面的辅助方法或者叫 链式方法 只有调用了find|select|update|delete|insert 才会真正执行sql
     * 构造器 find() 返回一条记录 一维数组   select()返回所有满足记录 二维数组
     */
    $result = Db::table('banner_item')->where('banner_id','=',$id)->select() ;
    <>
    Db::table('banner_item');
    Db::where('banner_id','=',$id) ;
    $result = Db::select() ;
    where('字段名','表达式','查询条件') 表达式为=的时候 可以缺省where('banner_id',$id)
    where有三种 表达式(上述) 数组 闭包(下例)
        $result = Db::table('banner_item')
                ->where(function($query) use ($id) {
                    $query->where('banner_id','=',$id) ;
                })
                ->select() ;
开启SQL日志记录
    调试sql 语句
        1>fetchSql()
            $result = Db::table('banner_item')
                        ->where('banner_id','=',$id)
                        ->fetchSql()
                        ->select() ;
            使用fetchSql() 会打印出当前拼接的sql 语句 不会真正执行
        2>开启sql日志记录  分析sql的运行时间 吞吐率 内存消耗...
            database.php   'debug' => true ,
            config.php      'app_debug'=>true ,
            关闭了自动记录日志 可以在入口文件 初始化
            Log::init([
                'type' => 'File' ,
                'path' => LOG_PATH,
                'level' => ['sql']
            ]);

模型以及关联模型
    ORM思想 Object Relation Mapping 对象关系映射
    传统sql语句查询表  表是一种数据结构(数组 二维数组)
    用ORM 做数据查询的时候  操作的不是表 是对象  对象如何获取数据不需要关心
        如此一来 表与表之间就不是数据结构与数据结构之前 是对象与对象之间的作用关系
    TP5中的模型 是ORM思想实现的一种机制 包含数据查询以及业务逻辑  可以处理复杂的业务逻辑
        例如 对应多个对象 多张表
        模型和表 对象之间没有必然联系 模型是根据自己的业务逻辑(功能)划分的
            业务逻辑简单的话 可能一张表 一个对象 对应一个模型 1<->1
            业务逻辑复杂的话 多张表 多个对象对应一个模型 多<->1
        模型不仅仅是 model一层  model细小粒度的接口 service层很多model的集合 粗粒度接口
    例如 用户登录 比对帐号密码 简单的业务 Db类执行 增删改查 不涉及复杂逻辑
                异地登录 发送短信通知
                多个设备同时登录 (PC端登录 移动端提醒 下线等)
         Db与模型相比不能很好的 包含和处理业务逻辑 Db属于底层数据库访问层 Model类似于建立在数据库访问层之上的处理业务逻辑的模型层
    使用方法
        1>class Banner extends Model  继承think\Model  默认类名对应表名   关联模型一个模型对应多张表(主从表 banner banner_item)
            class Banner extends Model
            {
                protected $table = 'category' ;   //指定 该model对应的表  类名与表名不对应
            }
        2>$banner = BannerModel::get($id) ; 调用父类方法 返回对象
        3>config.php
            // 默认输出类型  html 改成json
            'default_return_type'    => 'json',

        快捷创建模型命令   php think make:model api/BannerItem
                        namespace app\api\model;
                        use think\Model;
                        class BannerItem extends Model
                        {
                            //
                        }
        静态调用还是实例对象调用
            静态调用
                $result = BannerModel::get($id) ;
            实例对象调用
                $banner = new BannerModel() ;
                $result = $banner->get($id) ;
            模型的查询 推荐使用静态调用
                静态调用更加简洁
                数据库的单位是表以及表中的记录 BannerModel这个类对应表
                BannerModel实例化之后的对象对应表中的记录(类[属性 行为]与对象[具体事物])
                逻辑上来说
                BannerModel对应表通过get获取目标记录
                $banner = new BannerModel() ;实例化之后 $banner对应一条记录 一条记录再get() ...
            查询动词
                构造器  find()一条记录 select()多条记录
                模型   get() find()      单个对象
                       all() select()  多个对象
            Db是模型的基础 模型内部最终访问数据库还是数据库访问层Db
            模型和数据库访问层 职责不同 模型主要处理业务 Db数据库操作
            模型性能稍差 相比原生sql
            面向对象的思维设计使用模型
            模型的底层 还是数据库访问层 自动调用
            好的代码第一原则是可读性 使用框架必然有性能损耗 不如原生php快 框架就是一种抽象和封装 有性能损耗