siyemiaokube 最近的时间轴更新
siyemiaokube

siyemiaokube

V2EX 第 123157 号会员,加入于 2015-06-19 23:17:34 +08:00
关于“出身”与“勤奋”的简短杂感
  •  3   
    程序员  •  siyemiaokube  •  2019-04-09 00:37:22 AM  •  最后回复来自 MinQ
    104
    度娘好可爱,数组也敏感
    全球工单系统  •  siyemiaokube  •  2019-03-16 18:31:48 PM  •  最后回复来自 hahahe
    6
    真心求助:将来想当程序员,大学好不好有多重要呢?
    程序员  •  siyemiaokube  •  2018-01-07 03:07:30 AM  •  最后回复来自 hushuiwang
    143
    siyemiaokube 最近回复了
    32 天前
    回复了 withzhaoyu 创建的主题 程序员 咨询下 v 友们志愿填报的问题
    你家在电网有关系吗?我一个资深大院人,还能靠自己读个不错的大学,进电网都赚不了多少钱。。。
    33 天前
    回复了 NeroKamin 创建的主题 程序员 实际工作中数据库表设计会遵循范式吗?
    @l00t
    > 第一范式怎么违反??

    比如表的一项是个字符串,里面储存了多种 tag
    33 天前
    回复了 NeroKamin 创建的主题 程序员 实际工作中数据库表设计会遵循范式吗?
    数据库的范式不是从业务层面或效率层面出发的,而是从关系代数的描述能力出发的。

    在为数据的增删查改提供 api 的时候,怎样的 api 才是必然足够的、拥有足够强的描述能力、必然无需后续再进行增加?关系代数给出了一个答案。(过强的描述能力也带来了安全性的问题)

    但是,关系代数本身并未约束 table 的具体形式,我们容易意识到,把所有 table 自然连接成一个大表的话,会带来很多问题,教科书上对这些问题有足够的描述。我个人的概括是,这些问题要归咎于关系型数据库无法(完全)支持 lazy 特性。

    那么,一个可以稍微弥补的方法,就是通过数据库的范式,约定好表的格式,从而间接地,对于一定的调用,我们可以一次性完成所需的操作,而不用对自然链接后的大 table 逐条执行。

    但是,如果我们可以从业务层面确认,上述情况不会出现,或者出现的频率相比而言较低,把表细致的拆分就是不经济的。
    35 天前
    回复了 johnsonwil 创建的主题 DNS iQDNS - 一个纯净的像少女一般的 DNS 服务
    作为女权主义者,我抗议标题的这种充满男性凝视的比喻,真要描述纯净,您不如用“105 度的蒸馏水”
    119 天前
    回复了 Twosecurity 创建的主题 推广 [信息安全] 开放几个课程 🚀
    建议把试学的部分搞多一点,买了几个,感觉质量太差了,也可能是不适合我的水平吧,就完全不知道在说什么……
    先说清楚你的拆分是怎么个拆分……
    127 天前
    回复了 AlexaETF 创建的主题 程序员 96 年女生 学编程 有可能吗
    标题不写女生就有可能,写了女生就没可能了
    迷惑行为……
    我的 block 居然起作用了(⁎⁍̴̛ᴗ⁍̴̛⁎)
    关于   ·   帮助文档   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   2143 人在线   最高记录 5497   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 52ms · UTC 14:24 · PVG 22:24 · LAX 07:24 · JFK 10:24
    ♥ Do have faith in what you're doing.