V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  lanlanye  ›  全部回复第 16 页 / 共 20 页
回复总数  393
1 ... 8  9  10  11  12  13  14  15  16  17 ... 20  
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 左右恢复正常了,不知道是什么原因
2021-12-03 09:35:08 +08:00
回复了 Clloz1992 创建的主题 macOS Mac 上 apple music 登录 apple id 后无法搜索
加载逻辑问题,点击搜索框后等右侧加载完再开始搜索就可以
2021-11-30 13:37:49 +08:00
回复了 zydxn 创建的主题 Apple Apple Music 是否不适合听 ACG 歌曲较多的?
@KirbySD 回来看贴顺便补充一点,国内信用卡就我知道的是招商银行 JCB 卡是可以日区付款的,具体情况可以 V 站搜其他贴了解,如果不介意那些美区有而日区没有的服务的话日区确实是不错的。
2021-11-29 11:40:49 +08:00
回复了 zydxn 创建的主题 Apple Apple Music 是否不适合听 ACG 歌曲较多的?
试试日区:
1. 日区的 ACG 曲库算是相当全的,会有一些不进订阅的,可以在 iTunes 里单独买,目前没怎么遇到找不到的情况
1. 日区歌曲名称不会转罗马字,上面也有人说了
个人转美区的原因:
1. 日区绑定日文界面,需要一定语言基础,我个人虽然不是完全看不懂,但没有熟练到轻松阅读(至少专辑介绍之类的无力)
1. 美区曲库大部分也都有,缺少一些偶像企划的专辑,我觉得问题不是很大
1. 语言问题似乎和发行商提供的信息有关,现在已经不是无脑转罗马字了,一些专辑同时有日文和英文名的在美区显示为英文,新曲大多数可以正常显示假名(老歌部分还是存在罗马字问题,以及歌手名还是罗马字)
1. AppleMusic 账号绑定商店、TV 和 fitness+,日区 TV 界面我是完全看不懂,剧名都是假名……fitness+目前也没有支持日区
2021-11-24 17:05:32 +08:00
回复了 Aspector 创建的主题 macOS 请教在 M1 MacBook 上使用 MX Anywhere 3 的正确姿势
Options 概率性失灵,需要重启服务才能恢复(我选择注销重新登录)
Mos 很不错,如果你不需要自定义其他按键功能的话
文件不是特别多或者特别大的话,用 vim 录宏……
2021-11-18 00:39:35 +08:00
回复了 algery 创建的主题 Apple M1 Pro 有必要加钱上到 10 核吗
我这几天观察了一下,日常用基本就两个小核在跑,所以加不加感觉区别不大……如果没有特别要求 CPU 性能的需求,可以不加。
我是觉得用做坏的芯片有些别扭,虽然也没什么可在意的。
我遇到了,把显示器关了重开……好了……
2021-11-14 02:25:35 +08:00
回复了 RandomAccess 创建的主题 Apple 状态栏图标的问题
这个问题一直都有,旧 Mac 在菜单和图标都特别多的时候也会隐藏掉没地方显示的图标,而且不借助第三方工具没法调出来,现在只是多了个刘海,位置更小了
2021-11-10 10:55:21 +08:00
回复了 AndyAO 创建的主题 程序员 VSCode 的 Python 测试功能太烂了 -_-||
@AndyAO 意思是测试 调试 运行 格式化……等等一系列操作其实都可以在这个 panel 里完成,还不需要切窗口
1 ... 8  9  10  11  12  13  14  15  16  17 ... 20  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1979 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 31ms · UTC 00:45 · PVG 08:45 · LAX 16:45 · JFK 19:45
Developed with CodeLauncher
♥ Do have faith in what you're doing.