2018-10-18

08:52 到公司
08:53-08:59 整理桌面卫生, 6m
08:59-09:03 倒垃圾,洗杯子, 4m
09:04-09:44 根据数据库来分析理解业务, 40m
09:45-09:51 休息, 6m
09:52-10:31 处理保存和修改教练同步处理账户的数据, 38m
10:32-10:46 参加早会和找小帅,景帅了解问题, 14m
10:47-12:02 查看MGR-web的接口调用方式处理, 75m
12:03-12:34 处理MGR-web题库无法正常引入的问题, 31m
12:35-13:34 处理MGR-web题库无法正常引入的问题, 60m
13:35-14:08 处理完成MGR-web中教练详情增加uid的开发和测试, 32m
14:09-14:14 休息, 5m
14:15-17:55 处理修改教练数据内容
17:56-19:34 开发完成保存和修改教练对用户账户的修改

今日工作安排:
1.思考为什么使用lombok ok
2.根据数据库来分析理解业务 ok
3.了解产品经理的业务分工 ok
4.测试环境走一遍网站业务
5.开发处理完成教练的保存界面 ok

处理完成
1.思考为什么使用lombok
2.根据数据库来分析理解业务
3.了解产品经理的业务分工
4.处理MGR-web题库无法正常引入的问题
5.处理完成MGR-web中教练详情增加uid的开发和测试
6.开发完成保存和修改教练对用户账户的修改

技术管理:
1.使用lombok的好处是:首先是减少大量的模板代码,get和set方法,从代码封装维度看,将大量的模板代码进行封装,不需要其他人员来不断编写,哪怕是IDE可以生成的代码,这也是重复代码,减少重复的出现;其次是从代码可读性角度来看,可以专注于查看类的属性,尤其编写代码的风格不一致,比如为了防止代码冲突,新增加的代码都在最后下面编写,之前总会看到类似的问题,新增加的属性和set和get方法写道后面,让其他人无法专注查看类本身的关键内容;第三减少代码冲突的可能,尤其增加新属性的时候,哪怕处理冲突也非常简单的,大量的bean,model,vo中减少非常多的代码维护;第四是lombok处理的toString方法,hash,equal方法等内容,当增加新属性的时候,以上方法都不需要重新编写,而是lombok直接帮助处理的,不会出现遗漏的问题和情况.就好比修改增加或修改某个属性,那么你就要处理该属性对其相关内容的变化,现在你修改后,其他内容不需要你去善后,而是直接有人给你善后一样. 使用lombok的不足:首先要求IDE增加对lombok的支持,比如IDEA中需要安装lombok的插件;其次是如果你想确认某个set或get方法是否在程序中被调用,你无法找到哪里使用的,但是我更认为这样的操作是违背了bean使用的初衷,bean尤其数据库和java类的映射bean,java对bean的定义和使用就是无参数的构造方法和set和get方法,而不应该在bean中处理任何和业务有任何关系的逻辑.
2.上午处理MGR-web的事情内容,不知道怎么脑袋混了,居然看到问题还在那边排查的,到底是没有看明白,还是因为做的比较久的原因导致的事情呢,这个需要思考的.然后验证hibernate的校验接口,现在是把公共类等放到一个项目中,数据库和entity的映射不能使用,接口数据校验不能用,怎么感觉一夜回到解放前的感觉呢.

反思总结:
1.在ubuntu上使用谷歌拼音输入法比较使用搜狗拼音输入法,之前一直使用搜狗拼音,但是会时不时地搜狗输入法崩溃,需要不断重启搜狗输入法,如果使用谷歌输入法,虽然没有搜狗输入法更加智能识别你想要的内容,但是谷歌输入法使用若干天没有发生崩溃,可以让我持续地进行输出,这一点谷歌输入法在ubuntu上做的比较好.

个人防护装备实例分割数据集 一、基础信息 • 数据集名称:个人防护装备实例分割数据集 • 图片数量: 训练集:4524张图片 • 训练集:4524张图片 • 分类类别: 手套(Gloves) 头盔(Helmet) 未戴手套(No-Gloves) 未戴头盔(No-Helmet) 未穿鞋(No-Shoes) 未穿背心(No-Vest) 鞋子(Shoes) 背心(Vest) • 手套(Gloves) • 头盔(Helmet) • 未戴手套(No-Gloves) • 未戴头盔(No-Helmet) • 未穿鞋(No-Shoes) • 未穿背心(No-Vest) • 鞋子(Shoes) • 背心(Vest) • 标注格式:YOLO格式,适用于实例分割任务,包含边界框或多边形坐标。 • 数据格式:图片数据,来源于监控或相关场景。 二、适用场景 • 工业安全监控系统开发:用于自动检测工人是否佩戴必要的个人防护装备,提升工作场所安全性,减少工伤风险。 • 智能安防应用:集成到监控系统中,实时分析视频流,识别PPE穿戴状态,辅助安全预警。 • 合规性自动化检查:在建筑、制造等行业,自动检查个人防护装备穿戴合规性,支持企业安全审计。 • 计算机视觉研究:支持实例分割、目标检测等算法在安全领域的创新研究,促进AI模型优化。 三、数据集优势 • 类别全面:覆盖8种常见个人防护装备及其缺失状态,提供丰富的检测场景,确保模型能处理各种实际情况。 • 标注精准:采用YOLO格式,每个实例都经过精细标注,边界框或多边形坐标准确,提升模型训练质量。 • 真实场景数据:数据来源于实际环境,增强模型在真实世界中的泛化能力和实用性。 • 兼容性强:YOLO格式便于与主流深度学习框架(如YOLO、PyTorch等)集成,支持快速部署和实验。
<think>我们有一个表,记录每个运单在网点的到达时间和离开时间。需要统计在2018-03-01 13:00到2018-03-01 15:00之间,在该网点有停留(即离开时间不等于到达时间)的运单数。 注意:停留意味着离开时间不等于到达时间。同时,我们要统计的是在这个时间区间内(2018-03-01 13:00到15:00)有停留的运单。注意,这里的时间区间指的是停留发生的时间区间,即停留事件必须有一部分落在这个时间区间内。 如何理解“在2018-03-01 13:00到2018-03-01 15:00之间在该网点有停留”? 停留事件的发生时间实际上是一个时间段(从到达时间到离开时间)。我们要求这个时间段与[2018-03-01 13:00, 2018-03-01 15:00)有重叠。 因此,条件为:到达时间 < 离开时间(即有停留)并且停留时间段与查询时间段有交集。 停留时间段与查询时间段有交集的条件是: - 停留时间段的开始(到达时间)小于查询时间段的结束(15:00)且停留时间段的结束(离开时间)大于查询时间段的开始(13:00) 即:到达时间 < '2018-03-01 15:00' AND 离开时间 > '2018-03-01 13:00' 另外,我们还要确保离开时间不等于到达时间,即停留事件成立。 因此,SQL语句可以这样写(假设表名为`express`,到达时间列为`arrival_time`,离开时间列为`departure_time`): ```sql SELECT COUNT(DISTINCT shipment_id) AS count FROM express WHERE arrival_time < departure_time -- 确保有停留 AND arrival_time < '2018-03-01 15:00' AND departure_time > '2018-03-01 13:00'; ``` 解释: 1. `arrival_time < departure_time` 确保该运单在这个网点有停留(停留时间大于0)。 2. `arrival_time < '2018-03-01 15:00'` 表示运单的到达时间必须在15:00之前(否则停留事件从15:00之后才开始,就不在时间段内)。 3. `departure_time > '2018-03-01 13:00'` 表示运单的离开时间必须在13:00之后(否则停留事件在13:00之前就结束了,也不在时间段内)。 注意:这里使用`COUNT(DISTINCT shipment_id)`来避免同一个运单多次出现在该网点(虽然一个运单在一个网点通常只有一条记录,但为了严谨)或者如果有重复记录的情况。 如果表中一个运单在同一个网点可能有多条记录(例如多次进出),则要根据业务逻辑判断,但根据问题描述,一个运单在一个网点的到达和离开应该是一次性记录。 如果表中的记录是一个运单在网点的完整停留记录(即一次到达和一次离开),那么我们可以直接使用上述条件。 另外,注意时间格式,确保比较的时间格式一致。这里的时间字符串是'2018-03-01 13:00'和'2018-03-01 15:00'。 如果时间列包含时区,可能需要转换,但问题中没有提到,所以按无时区处理。 因此,最终答案就是通过上述SQL查询得到结果。 注意:这里统计的是停留事件与查询时间段有重叠的运单数。也就是说,只要运单在网点的停留时间段有一部分落在查询时间段内,就统计在内。 例如: - 运单在12:50到达,13:10离开:停留时间段[12:50,13:10]与[13:00,15:00]在13:00到13:10有重叠,所以统计。 - 运单在14:50到达,15:10离开:与查询时间段在14:50到15:00有重叠,所以统计。 - 运单在12:50到达,12:55离开:整个停留时间段都在13:00之前,不统计。 - 运单在15:00到达,15:10离开:到达时间等于15:00,但是我们的条件是离开时间大于13:00且到达时间小于15:00?注意到达时间15:00不小于15:00(除非是严格小于,而15:00等于15:00,所以不满足条件)。因此不会统计。 但是,这里有一个边界问题:如果停留事件刚好在13:00开始,或者在15:00结束,是否包括? 根据条件: - 到达时间 < '2018-03-01 15:00':所以到达时间如果是15:00,则不满足(因为15:00不小于15:00)。同样,到达时间如果是13:00,满足(13:00<15:00)。 - 离开时间 > '2018-03-01 13:00':所以离开时间如果是13:00,则不满足(因为13:00不大于13:00)。离开时间如果是15:00,满足(15:00>13:00)吗?但是注意,离开时间如果是15:00,那么到达时间必须小于15:00(例如14:50),这样条件都满足,就会被统计。 所以,对于边界: - 如果停留事件在13:00开始,在13:30离开:到达时间为13:00,满足到达时间<15:00(13:00<15:00),离开时间13:30>13:00,满足。 - 如果停留事件在14:30开始,在15:00离开:到达时间14:30<15:00,离开时间15:00>13:00(因为15:00大于13:00),满足。 但是,如果停留事件在15:00开始,则到达时间为15:00,不满足arrival_time < '2018-03-01 15:00'(因为等于),所以不统计。 同样,如果停留事件在13:00结束,则离开时间等于13:00,不满足departure_time > '2018-03-01 13:00'(因为等于),所以不统计。 因此,边界条件为:左闭右开?实际上,我们统计的是停留时间段与开区间(13:00, 15:00)有重叠?不对,我们使用的是大于和小于,所以实际上是: - 停留时间段的开始时间(到达时间)必须小于15:00(即15:00及以后到达的不算) - 停留时间段的结束时间(离开时间)必须大于13:00(即13:00及之前离开的不算) 这样,停留时间段必须与(13:00, 15:00)有重叠部分。注意,由于时间段是连续的,所以即使停留事件在13:00开始,因为到达时间等于13:00,但离开时间大于13:00,所以实际上停留事件在13:00这个时间点之后还有一段时间,所以与[13:00,15:00)有重叠?但是我们的条件只要求离开时间大于13:00,到达时间小于15:00,所以实际上覆盖了[13:00, 15:00]这个闭区间内的所有停留事件?不对,因为: - 到达时间小于15:00(包括13:00,14:59:59等),离开时间大于13:00(包括13:00:01,15:00等)。 但是,如果我们想要包括在13:00开始停留的运单(到达时间为13:00)和直到15:00才离开的运单(离开时间为15:00),那么我们的条件已经包括了: - 到达时间13:00:小于15:00(成立),离开时间大于13:00(假设离开时间是13:00:01,则大于13:00,成立;但是注意,离开时间不能等于13:00,等于则不满足)。 - 同样,离开时间15:00:大于13:00(成立),到达时间小于15:00(成立)。 所以,我们实际上包括了: - 到达时间在13:00之后(大于等于13:00)且小于15:00,并且离开时间大于13:00(且可以等于15:00吗?但是离开时间等于15:00是大于13:00的,所以可以)的停留事件。 但是,如果我们有一个停留事件:到达时间12:30,离开时间13:00。则: - 到达时间12:30 < 15:00 (满足) - 离开时间13:00 > 13:00?注意,13:00>13:00是不成立的(因为等于),所以不满足。 因此,这个停留事件没有被包括。这符合我们的要求吗? 这个停留事件在13:00结束,所以它在13:00这个时间点已经离开了。也就是说,在13:00这个时间点,它已经不在网点了。那么在整个查询时间段[13:00,15:00]内,它并没有停留(因为它在13:00时已经离开)。所以不应该包括。 同理,如果在13:00到达,13:00离开(即瞬间离开),那么停留时间为0,但是我们的条件中要求`arrival_time < departure_time`,所以这种瞬间离开的记录会被排除(因为到达时间等于离开时间,不满足停留条件)。 所以,这个SQL满足需求。 总结:使用上述SQL语句即可。 另外,如果表中一个运单在同一个网点有多次停留记录(比如一个运单先到达,然后离开,然后又再次到达),那么我们需要分别统计每一次停留,但是注意,同一个运单可能被计数多次(因为同一个运单可能有多次停留事件落在该时间段内)。而问题要求的是“运单数”,即有多少个运单(而不是多少次停留事件)。所以应该使用`COUNT(DISTINCT shipment_id)`。 如果表结构中没有运单号(shipment_id)字段,那么需要根据实际情况调整,比如使用主键或者其他唯一标识。但问题描述中没有给出表结构,我们假设有运单号字段。 因此,最终SQL如下: ```sql SELECT COUNT(DISTINCT shipment_id) FROM express WHERE arrival_time < departure_time AND arrival_time < '2018-03-01 15:00' AND departure_time > '2018-03-01 13:00'; ``` 注意:如果时间字段的类型是字符串,那么需要用函数转换为时间类型,或者确保字符串比较是按时间顺序(例如格式为'YYYY-MM-DD HH:MM:SS'的字符串可以直接比较)。如果已经是时间类型(如datetime或timestamp),则可以直接比较。 如果数据库存储的是时间戳,同样可以直接比较。 所以,在编写SQL时需要确保时间格式一致。 如果用户需要更精确(比如包含毫秒),但问题中时间只精确到分钟,所以用这个格式即可。 此外,如果查询的时间区间非常大,可以考虑在arrival_time和departure_time上建立索引以加快查询速度。 以上即为统计方法。 </think>### 统计网点停留运单的方法 要统计在 **2018-03-01 13:00 到 2018-03-01 15:00** 期间网点内有停留的运单数(即离开时间 ≠ 到达时间),可通过以下 SQL 查询实现(假设表名为 `express_log`): ```sql SELECT COUNT(DISTINCT shipment_id) AS stayed_shipments FROM express_log WHERE -- 停留条件:到达时间 ≠ 离开时间 arrival_time <> departure_time AND -- 停留时间段与目标区间[13:00,15:00]存在重叠 arrival_time < '2018-03-01 15:00' AND departure_time > '2018-03-01 13:00'; ``` #### 关键逻辑说明: 1. **停留判定** `arrival_time <> departure_time` 确保运单在网点有实际停留(非即时转出)。 2. **时间区间覆盖** - `arrival_time < '2018-03-01 15:00'`:运单在 **15:00 前已到达** - `departure_time > '2018-03-01 13:00'`:运单在 **13:00 后仍未离开** 满足这两个条件时,运单的停留时间段必然与目标区间 `[13:00, 15:00]` 存在重叠[^1]。 3. **去重计数** `COUNT(DISTINCT shipment_id)` 防止同一运单多次进出网点导致的重复统计。 #### 示例场景验证: | 运单 | 到达时间 | 离开时间 | 是否统计 | 原因 | |------|--------------------|--------------------|----------|-------------------------------| | A | 12:50(13:00前) | 13:30(13:00后) | ✓ | 停留覆盖 13:00-13:30 | | B | 14:30 | 15:15(15:00后) | ✓ | 停留覆盖 14:30-15:00 | | C | 12:00 | 12:50(13:00前) | ✗ | 停留全程在 13:00 前结束 | | D | 15:05 | 15:30 | ✗ | 停留全程在 15:00 后开始 | | E | 13:00 | 13:00 | ✗ | 无停留(到达即离开) | > ⚠️ **注意**:若数据库时间字段包含时区或非标准格式,需先用函数转换(如 MySQL 的 `STR_TO_DATE()`)。 ***
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值