V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  lanlanye  ›  全部回复第 15 页 / 共 20 页
回复总数  382
1 ... 7  8  9  10  11  12  13  14  15  16 ... 20  
2022-02-19 16:12:50 +08:00
回复了 mantis 创建的主题 Go 编程语言 golang 中 channel 的一个问题
你可以在这里找到详细的解释: [基于 select 的多路复用]( https://book.itsfun.top/gopl-zh/ch8/ch8-07.html)
2022-02-19 16:07:18 +08:00
回复了 secsilm 创建的主题 程序员 V2EXer 的图床使用情况的不保真统计
……很少发帖的我都是需要的时候临时去搜一个出来用
2022-02-19 16:06:18 +08:00
回复了 uudj 创建的主题 剧集 有好看的剧,蹲家里刷刷剧了。
Ted Lasso
2022-01-27 01:26:33 +08:00
回复了 627Ryan 创建的主题 知乎 大家对 「少数派」 是数码圈「小红书」的说法有什么看法?
看的不多,当时 Apple Music 换区的时候有篇文章很有帮助,然后 iPad + Apple Pencil 难道不算生产力工具?
2022-01-27 01:20:13 +08:00
回复了 kilims 创建的主题 职场话题 tx 新瓜,怎么看
@xilixjd 吴军在书里提到过早年 Google 周末是不休息的,人家也有过那个阶段,现在应该是加班费成本高于加班时员工创造的价值了。不过人家加班是在做有意义的事,国内很多情况是由于管理层无能导致的无效加班。
2022-01-27 01:14:21 +08:00
回复了 EyebrowsWhite 创建的主题 程序员 关于国内技术社区的一点随想
国内社区的两大特点:

1. 任何社区做大了都会被监管干死
1. 任何小社区时间长了不是自己凉了就是和第一条同样的结局

国内只有少数坚持自己写博客分享的大佬干货比较多,CSDN 和博客园虽然也有干货,但这几年被各路复制粘贴造简历的人污染得已经到了可以直接屏蔽的程度了。

我觉得本站已经相当友好了,访问困难 + 人少没准是优势。
2022-01-24 09:40:29 +08:00
回复了 lanlanye 创建的主题 数据库 又是一个关于外键的问题
@dcoder 你说的这个我也不反对,跨库场景下外键当然起不到作用,但非跨库的情况下你做的无非是自己实现了一遍数据库做的事。

对于一个团队来说,这种方式想要达到和数据库一样的效果,需要每个成员均熟悉相关知识,以及依靠大量的测试和代码 review ,即使这样也很难说完全不会出错,所以代价比直接设置外键高多了。
2022-01-23 17:40:40 +08:00
回复了 lanlanye 创建的主题 数据库 又是一个关于外键的问题
@Gota 非常感谢您的回复!解答了我的很多疑惑。

根据上述方案,可以将业务库的数据控制在一个较小的级别,让物理外键的存在不至于导致性能问题,同时可以利用好其完整性约束和级联操作等特性。一切的前提是需要引入一套高效可靠的日志服务,对吗?

我 28 楼的提问主要是考虑 **软删除** 这个情况下需要将数据存档。如果存在可以回放的日志,那就不需要软删除了,对数据的存档也早在记录日志时就已经完成了,这个问题也得到了解决。
2022-01-23 15:31:48 +08:00
回复了 lanlanye 创建的主题 数据库 又是一个关于外键的问题
@Gota 涉及到引用关系的数据在写入冷存储时似乎也只能靠开发人员约束,这就和使用逻辑外键一样了,同理还有需要在开始写入冷存储到实际删除数据前的这段时间里避免产生新的引用,也得依靠主动加锁。

要避免加锁,可以先对要删除的数据做软删除来避免后续业务引用它,再逐步删除已经存在的引用,但这依然要求开发人员在写入数据时做检查,同时因为目标数据和引用数据分别删除,需要考虑后续删除失败时手动回滚,感觉问题会变得更复杂……
@Wuuuu 筛选分为相等,排除,比较等形式,添加如 eq lt le gt ge 等标志可解,排序定义一个单独的参数即可。但我认为这只不过是一种接口设计的思路,实际上遵循的思想是 “尽可能少造轮子”,比如利用已存在的 HTTP 状态码代替自己定义错误信息,楼内也有人说了,非增删改查的复杂逻辑是很难用这种方式设计的,所以需要变通,比如当前端把筛选区做成一个很大的表单时,使用 POST 方法提交其实也很合理。
2022-01-23 12:40:27 +08:00
回复了 lanlanye 创建的主题 数据库 又是一个关于外键的问题
醒来看了一下各位的讨论,有以下几种情况:

@iseki 领导坚持不用这种问题确实存在,这里只考虑技术上使用物理外键是否比逻辑外键更好。我自认为已经把上下文定义得相对清晰了,即:非单表大量数据,非分布式情况,通常不超过百万但含有较复杂引用关系的业务数据。

@dcoder 确实存在认为数据库应该只做存储这一件事的看法,但这其实是放弃了 RDBMS 的部分功能,关于程序员希望少关心 SQL 这件事我也感到疑惑,因为 ORM 固然强大,但很难只靠它就写好业务逻辑,对一个后端开发人员来说了解数据库相关知识应该是必须的,而外键并不算什么特别生僻的知识吧?

典型场景下:如需要确保引用的数据存在,开发上需要先查询并加锁,再执行插入,而目前我接触过的 ORM 都不会在查询时加锁,这说明 ORM 也默认了开发者理解数据库行为并会自己去处理这件事,这显然不符合你说的 “少研究 SQL 也能写清楚逻辑”,而我疑惑的原因是手动加锁和使用外键约束相比并不高效,还需要投入额外的开发精力。

@cwek 如果 “没必要” 是说无论有和没有都不会影响功能的实现,那我也同意,但本帖想要讨论的问题是 “在(如正文描述的)一般情况下使用物理外键是否更合理”,因为我找不到使用逻辑外键可以比物理外键更高效、可靠的理由,能否从这个角度讨论问题呢?

@Gota 受教了,不过归档数据这项工作是在删除时完成更好还是定期由独立的程序完成更好呢?后者的话其实并不能避免开发时编写软删除逻辑
2022-01-22 23:05:32 +08:00
回复了 xinghen57 创建的主题 分享发现 敲锣打鼓, QQ 终于不当人了(吐槽向)
作为对比,Telegram 只有 90MB
2022-01-20 20:45:03 +08:00
回复了 yayiji 创建的主题 Apple 可否改变 vim 中 leader 键的按键方式?
正经来说,Vim 好像没有你要的这种形式,但是上移这种操作一般不都是删除整行后跳到目标位置粘贴吗……
拿你举例的「向上移动一行」来说,完全可以直接 kddp 解决,为了这种功能写函数都没必要,也不会用到 leader 吧
2022-01-20 20:42:53 +08:00
回复了 yayiji 创建的主题 Apple 可否改变 vim 中 leader 键的按键方式?
喜欢组合键要不要试试 Emacs ( Doge
2022-01-08 02:54:13 +08:00
回复了 LoneFireBlossom 创建的主题 macOS 如果你不想天天被 bug 气到,就不要买 Mac
啊这……15 款用了 6 年你说的这些我一个都没遇到过,去年年底换新到现在也没遇到,期间一直自动更新保证系统最新。
倒是新系统宣传的 FaceTime 那几个分享功能 bug 一大堆,怎么用怎么难受。
可能我装的 App 确实少,使用场景也比较固定。
2021-12-10 18:29:33 +08:00
回复了 henbf 创建的主题 分享发现 Github 现在可以给 Star 创建分类了
好功能,不过我开始担心微软把 GitHub 做的过于复杂花哨了……
2021-12-03 18:00:13 +08:00
回复了 bailitusu 创建的主题 macOS 为更换电脑做准备,整理了一下 macOS 上需要转移的软件授权
剪贴板工具的话,给不习惯 Paste 的人推荐另一个 Pasta ,注意是 a 不是 e ,App Store 可以直接下载,而且免费版似乎足够应对大部分需要了。
2021-12-03 12:22:42 +08:00
回复了 lanlanye 创建的主题 Apple 今早开始 Apple Music 无法访问
大概 11:30 左右恢复正常了,不知道是什么原因
1 ... 7  8  9  10  11  12  13  14  15  16 ... 20  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   950 人在线   最高记录 6543   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 35ms · UTC 20:38 · PVG 04:38 · LAX 13:38 · JFK 16:38
Developed with CodeLauncher
♥ Do have faith in what you're doing.