V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  Marstin  ›  全部回复第 21 页 / 共 32 页
回复总数  638
1 ... 17  18  19  20  21  22  23  24  25  26 ... 32  
2019-10-16 09:48:00 +08:00
回复了 ChengNaNA 创建的主题 Vue.js 小白前端,不懂就问,如何自定义数组内汉字的排序
最简单的就是冒泡啊。
但是你这排序规则怎么定义呢,取前几位字符,汉字转阿拉伯数字,再根据阿拉伯数字排序?
2019-10-16 08:49:50 +08:00
回复了 jessun1990 创建的主题 生活 好了,程序员职业玩过瘾了,准备二次转行。
平时做工作记录,面试之前看笔记
关羽张飞都英年早逝,诸葛亮呕心沥血鞠躬尽瘁死而后已,这不仅要努力工作,还要命啊
@johnyu 拿一份钱做一份事,怎么加这么多戏?老板不满意员工,可以选择拿更高的待遇招更好的人。做老板不容易太难,可以选择倒闭或者卖掉公司,给别人打工,做员工只要关心自己的薪资和自己的发展前景。
2019-09-27 11:23:34 +08:00
回复了 drupal 创建的主题 问与答 关于礼节问题
发信息给对方,对方不回复,这就是沟通能力缺失啊,招进来也不好与团队协作工作的
你是用什么形式发的什么内容的信息?
一般面试流程下来,都是邮件或者电话联系,怎么会不回复呢,不回复怎么进行后续流程,这是真的有点憨。除了面试失败通知,其他的不回复都会影响面试结果吧
我以为我会看到 av 男优,h 文写手之类的
支持#11 老哥
2019-09-25 17:49:28 +08:00
回复了 Marstin 创建的主题 问与答 v2 的用户主流都是前端吗,为什么这么排斥 sql
@otakustay 没说不走索引!没说不走索引!都建议分区了,咋能不走索引呢,只是查询出百万条数据,这真扛不住,你内存扛得住,网络都扛不住了,分批取那得多久啊,优化 sql,百万条绝对是 3 秒以内的
2019-09-25 17:27:49 +08:00
回复了 Marstin 创建的主题 问与答 v2 的用户主流都是前端吗,为什么这么排斥 sql
@nnnToTnnn
第一、我只是提倡多点包容,不要群嘲,没有意义
第二、还是场景问题,每种解决方案都有适用场景。正确不代表普适性,肯定要考虑场景和成本。这个解决方案,你怎么做,全表数据导出在业务代码中处理,还是为了这一个需求做数据分离?你可以提出你的解决方案,友好讨论
第三、我没有说那个 sql 写得没问题,从表结构设计到 sql 都充满了问题,但是那个业务逻辑确实很简单,只是 sql 写的时候写得有问题,才会使逻辑看起来很复杂,我提出了相应意见,包括你说的“逻辑放到业务层,减少数据库的负担”。但是不代表“尽量把逻辑放到业务层,减少数据库的负担”这句话就有用。
@otakustay 除了内存还有 IO 啊,大数据量即便是分批去取,同样是需要考虑吞吐量的,这个对于简单需求真的得不偿失。我只能说解决方案是解决现实问题的,而且,即便楼上 @nnnToTnnn 老哥跟我如此辩论,我记得他也是看了 sql,提了一些方案的。讲道理,一句“尽量把逻辑放到业务层,减少数据库的负担”除了显得自己像那么回事以外,并没有什么卵用,大家的水平都不差,肯定也是迫于现实的嘛
@l00t 问题很多,估计这老哥也是接盘,以后有得玩了
2019-09-25 16:58:38 +08:00
回复了 Marstin 创建的主题 问与答 v2 的用户主流都是前端吗,为什么这么排斥 sql
@marcong95 互联网不等于所有场景,同样也不是一个解决方案就能适用于所有场景。
我并非对前端不太友好,只是我认为在“尽量把逻辑放到业务层,减少数据库的负担”这个问题上前端没有发言权,你们工作环境并没有接触到相关知识,更多来源于他人描述和书本。
而往往前端同学又喜欢用这样“尽量把逻辑放到业务层,减少数据库的负担”这样的回答去答复 sql 的相关问题,你真的了解相应的场景、架构、业务逻辑和解决方案吗?
2019-09-25 16:49:51 +08:00
回复了 Marstin 创建的主题 问与答 v2 的用户主流都是前端吗,为什么这么排斥 sql
@blless 我非常同意你的观点,推动架构的改变需要一个过程,以此作为通用的解决方案,对于当事人来说往往是望梅止渴。
PS:企业级应用经常存在面向领导编程和面向客户编程,百万级的数据量就很尴尬,说大不大,说小不小,还就统计这么一个功能专用,为这个上大数据,往往得不到支持和资源。
@l00t 我是出于业务角度去考虑修改的,不好意思,可能确实有失妥当。
目前的查询逻辑是查所有 kpi 信息,那么就可能查出来没有对应人员的 kpi 数据,且不能查出哪些人员的 kpi 数据缺失,
我认为应该是针对所有有效人员去查 kpi。(该业务逻辑确实是我的问题,我还是坚持这种方式更好点,哈哈)

基于以上考虑
account_number AS empNumber 且 GROUP BY ah.account_number 那么 account_number 为空,应该是脏数据了,在 where 中去掉应该没问题,where 中可以加上 ahh.empNumber != 0

最费解的是他这里 account_number 应该就是账户信息了,怎么用 qq 去匹配,如果 qq 对应的就是 account_number 字段,那就直接=,如果有生成逻辑,那就要冗余一个字段吧,用 qq 的 like 匹配肯定会有问题啊。
123456 就会匹配到 1234567 12345678 的数据
2019-09-25 16:16:36 +08:00
回复了 Marstin 创建的主题 问与答 v2 的用户主流都是前端吗,为什么这么排斥 sql
@love 对他人的不足适当包容,而非群起嘲讽,不是更友好吗
两秒钟格式化的时间于我而言,并不费力,为什么不和善一点呢。“请尽量让自己的回复能够对别人有帮助”,我认为忽略不足,回以答案,更有帮助
2019-09-25 16:11:37 +08:00
回复了 Marstin 创建的主题 问与答 v2 的用户主流都是前端吗,为什么这么排斥 sql
@linkedsh1005 前面还是调侃,后面部分回复里已经出现了这种自以为是的粗暴式解决方案了。
2019-09-25 16:09:23 +08:00
回复了 Marstin 创建的主题 问与答 v2 的用户主流都是前端吗,为什么这么排斥 sql
@murmur 对于这一点,我也觉得是很不正确的,需要改进,也提了意见。这也不属于嘲讽
1 ... 17  18  19  20  21  22  23  24  25  26 ... 32  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   5205 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 39ms · UTC 03:28 · PVG 11:28 · LAX 19:28 · JFK 22:28
Developed with CodeLauncher
♥ Do have faith in what you're doing.