zack_hj的博客

一、建表规约必须使用小写字符或者数字 禁止出现数字开头 禁止两个下划线中间只出现数字 不适用负数名词 禁用保留字（1）数据类型：小数类型为decimal 货币数据使用最小货币单位，数据类型为Bigint 字符串长度几乎相等使用char varchar长度不要超过5000，否则使用text（2）表必备三个字段id create_time update_tim（3）建表建议表的命名最好是遵循“业务名称加表的作用” 库名与应用名称尽量一致 如果修改字段含义或对字段表示的

1.根据之前的需求分析，主要分为3个模块用户模块 订单模块 票务模块（1）用户模块比较简单的模块，主要记录用户账号的基本信息，如姓名、密码、是否实名认证之类的（2）订单模块对用户每次订单进行记录，支持新增、修改。（3）票务模块最复杂的模块，支持订票、退票、查看车次、查看车票信息等业务。具体表如下：车票表：顾名思义，车票的基本信息。具体的车次信息、座位信息，只存了id。车次表：时刻表：经过车站表：车厢表：座位表...

购票系统的需求分析：主要模块1.订单模块2.用户模块3.

简介T31训练营是以购票系统为背景，通过这个让我们了解整个系统从0-1的过程，抽象业务，了解系统设计的方法论，增强代码规范，增强自身解决问题的能力和团队协作能力。感想今天孤尽从架构的维度，给我们完整的讲述了，整个系统设计的过程。系统设计根本是更好的解决问题，不应该过于追求技术，应该从实际问题出发，以解决问题为根本，所有的技术只是为了更好的解决问题。影响最深的一句话就是，架构是一种能力，不是一个职位。任何的需求和设计都包含了架构的部分思想，对需求的看待应该从更高的维度去看，将有助于以后的扩展。