数据库的分析

数据库的需求分析方法

结论： 1 . 超市进销存管理系统需商品分类管理，商品类型不可删除若有关联。
2 . 需记录供应商品，数量单位明确，销售单需数量和单价。
3 . 进货需供应商信息，报损需原因，操作员信息记录。
4 . 管理员权限控制，默认管理员不可删除。
5 . 信息增删改查，库存更新，分析热门商品。

数据项设计：
商品类型：编号、名称。

商品：编号、名称、介绍、库存量。

单位：编号、名称。

供应商：名称、介绍。

进货：商品、数量、单位、单价、时间、经手人。

销售：商品、数量、单位、单价、时间。

报损：商品、数量、单位、原因、时间。

管理员：账号、密码、默认账号。

实体设计：
商品类型信息。

商品信息。

商品单位信息。

供应商信息。

进货信息。

销售信息。

报损信息。

管理员信息。

数据分析常用的数据库知识

数据库这东西啊，得知道点实在的。

1 . 数据库基础语言
DDL：就是定义数据库结构，比如创建表啊，删表啊。
像 CREATE TABLE 这种语句就是DDL。

DML：操作数据，增删改查，INSERT、DELETE、UPDATE 都是DML。

DCL：控制权限，谁能干嘛，谁不能干嘛，GRANT、REVOKE 属于这个。

DQL：查数据，最常用的就是 SELECT。

2 . SQL语句执行流程 比如你在MySQL里跑一条SQL，得经过几步：
先去缓存看看有没有，没有就去解析，解析完优化器帮你把查询跑得更快，最后查权限，能跑就反馈结果。

3 . 数据表创建与数据加载
Hive：用 CREATE TABLE 创建表，数据加载用 LOAD DATA。

MySQL：也是 CREATE TABLE 创建表，可以指定主键啥的。

4 . SQL查询语句内部执行顺序 查询的时候，顺序得对：
先把 FROM 和 ON 搞定，然后 WHERE 筛选，再分组、聚合，HAVING 过滤，最后算表达式、选列、排序，要是还用 LIMIT 就按数量截断。

5 . 常用函数
算术函数：ABS、ROUND，比如 ROUND(1 .9 9 , 0) 就是取整。

字符串函数：CONCAT 拼接，LENGTH 数长度，UPPER 全大写，LOWER 全小写，SUBSTR 截取，REPLACE 替换。

日期函数：CURDATE 当前日期，YEAR 提取年，DATEDIFF 计算天数差。

转换函数：CAST 类型转换，比如 CAST('1 2 3 ' AS INT) 把字符串转整数。

6 . 聚合与窗口函数
聚合函数：MAX 最大值，MIN 最小值，AVG 平均值，COUNT 数个数，SUM 加起来。

窗口函数：RANK 排名，ROW_NUMBER 行号，SUM 聚合但分窗口算。

7 . 关联查询
左关联：左表全拿，右表匹配的也拿，不匹配的右表空着。

右关联：反过来，右表全拿，左表匹配的也拿，不匹配的左表空着。

全关联：左右表全拿，匹配的匹配，不匹配的补空。

8 . 数据导入安全 MySQL 8 .0 批量导入要注意，文件得放安全路径。
比如 /secure/data 这种地方。

9 . 常见数仓结构
ODS层：原始数据，啥都放。

DW层：ETL处理完的数据，干净点儿。

DM层：报表用，面向业务。

说实话，这些搞懂了，数据分析和处理就容易多了。

数据库分析用的哪种方法

说实话，做差异性分析用非参数检验挺常见的，我自己之前搞个电商用户行为研究，那数据偏态挺严重，非参数方法反而比T检验靠谱。
SPSSAU这玩意儿我用过几次，在线操作确实省事，打开网页就能跑，里面那种分析方法分类清晰，找起来不费劲。
不过你要是数据量特别大，比如几十万条记录，用它的时候可能卡一下，我当时处理一个A/B测试数据，5 00K记录跑检验花了快十分钟。

说到权限控制，这绝对是老生常谈但必须抠细节的活儿。
我之前接手过一个系统，前面维护人员搞权限的时候完全放飞自我，结果一个普通运营居然能删核心用户表，把我吓一跳。
所以现在我们内部定规矩，用户登录系统后，能看到的数据库、能执行的命令都给限定死。
比如销售部同事只能碰销售数据库，后台开发不能随意摸用户行为库。
这种最小权限原则说白了，就是防君子不防小人，但对付普通操作失误绝对有效。

防火墙这块我也踩过坑。
有次测试环境没开好，结果把生产库的端口给漏开了，好几个晚上被外部扫描到，虽然没造成数据泄露，但那晚我直接没睡着。
现在我们修改默认端口后，防火墙上就一条规则：除了内网特定IP和几个必要端口，其他全部拦截。
还启用了SYN Flood防护，主要是防那种暴力扫描，记得当时用Wireshark抓包看，那些扫描包连我都看花眼。

加密存储这事儿，我建议分场景搞。
像用户身份证号、支付流水这种绝对敏感的，必须用强加密。
但有些统计指标，比如月活用户数这种，加不加密影响不大，还可能拖慢查询速度。
我们当时给核心数据用了AES-2 5 6 ，备份文件则用了数据库自带的透明加密功能，感觉是个平衡点。
有个教训是，加密后别忘了测试恢复流程，我有个同事恢复数据时忘了解密密钥，结果系统瘫痪了半天。

聊到数据结构，SQL和NoSQL确实有代沟。
我自己用MySQL的时候，最烦的就是那种半结构化数据，比如日志里夹杂着不规则的字段，每次建表都要跟业务方扯皮半天。
后来接触MongoDB，发现它那套BSON格式处理起来灵活多了，想加个新字段直接追加就行。
不过NoSQL也有它的短板，比如跨文档查询效率差，我在处理一个文档里关联了多张表的场景时，硬是把我逼疯了。
所以现在我们做项目时，会根据数据特性选型，结构稳定的选关系型，杂乱无章的试试NoSQL。

数据表设计这块，我强烈推荐先画ER图。
之前有个项目，业务需求变更太频繁，结果数据表设计来回改了三版，最后整个团队都疯了。
表结构定义的时候，每个字段类型、长度、是否可为空都得想清楚。
有个细节特别重要，比如日期字段，我建议统一用ISO 8 6 01 格式存，SQL和NoSQL都能兼容，省得后续转换。
还有外键约束，虽然开发慢点，但数据一致性绝对保得住，我有个项目因为忘了加外键，结果数据被删了一半，那叫一个惨。

参考资料这块，百度百科确实方便，但关键技术细节还是得看官方文档。
像PostgreSQL的JSON支持，网上文章五花八门，官方文档里那几页解释清楚多了。
不过有时候社区讨论也挺有启发，比如Stack Overflow上有人问的"SQL vs NoSQL在事务支持上的区别"，底下有人用Python脚本模拟了真实业务场景，这种实践分享比教科书靠谱。