这还怎么看？就只能不看了啊

自己导入自己？？？因为你并没有 com.example 这个包，所以这是不被允许的呀。

@VIVVACI 我一直说的是用关系代数描述的“数据模型”，哪里有说建表了？

还有某些人，自己脑补出来智商低，我也是无语。看我不爽，来咬我啊。

至于在实际中如何应用理论，我只能说要从实际出发。既不能唯理论纸上谈兵，也不能没有理论指导胡搞瞎搞。这种大家都懂，但总是做不好的废话了。。。其实 1 楼就说的很好，为什么不按范式设计，只要自己清楚就行。

这种事我都是眼不见心不烦。看见也当没看见

都要跑路了还操这个心。。。。。。

当然是穿雨衣骑电动车啊

@daimubai 数据不大的话，也可以直接用计算结果排序。数据大的话，还是加一计算结果字段，专门用来排序好了。

前端同样枚举就行，要传值做咩？你以为传了值前端就不需要枚举了吗，下拉列表或者单选 /多选不还得自己枚举么。。。

@anguiao
@Rocketer
推荐算法在用户画像不全面的情况下，就是个伪命题，做出来就是个伪功能。而且，其算法结果必然是趋向收敛的。话说回啦，能给你听《东方红》就算是好的了，这还是托了歌曲分类有限且几个维度可以相关的福。换成商品，就只能看内衣推内衣，看家具推家具了。到了头条这种新闻客户端，信息茧房了解一下？

日入 1800，每个月 2W 房贷，两小孩补习班每月 6K/人，剩下那点钱也就温饱而已。。。。。。

列表：sql 函数计算
单项：前端计算亦可

说到这里了，索性多说几句。关于数据模型的设计，任何一本书上都没有提到的，但非常非常重要的一点：准确识别业务对象。反过来就是需要把对象属性进行准确的归属。要做到这一点其实并不容易，需要对业务有深入的理解才行。

其实这一点也应该是产品经理的基本能力。所以，数据模型其实应该由产品经理来设计而非程序员。现在产品经理不干这事，就造成了这么几个问题：
1 、逻辑无法闭环，程序员在设计的时候发现产品到处都是漏洞，甚至很多自相矛盾的操作。
2 、数据缺失，编程过程中才发现某些功能所需要的数据缺失了，这些数据不知道是什么样，更不知道要从哪里来。
3 、功能缺失，产品都干出来了，到测试的时候发现跑不通，少了一些功能，进入某些场景就进行不下去了。

这么一来，产品和程序的对立也就不难理解了。

@beichenhpy 一个理想数据模型，必然是符合 3 范式的，所以说 3 范式是天然的。

我说的是理想数据模型，不考虑任何使用场景，仅仅是对业务对象的结构化描述。

@NeroKamin 第一范式（ 1NF ）是指数据库表的每一列都是不可分割的基本数据项，同一列中不能有多个值，即实体中的某个属性不能有多个值或者不能有重复的属性。
证件号码和证件类型显然是两个属性，所以并没有违反。倒是譬如一个字段存一个集合或对象，确实是不符合“每一列都是不可分割的基本数据项”的。我认为这一点是过于理想化的，并不需要遵循。只需要遵循“同一个表不能有重复的属性”这一点就好了。

@destinism
@Saurichthys

逻辑思维能力差不是很正常的事情吗？怎么就难听了了？吃编程这碗饭这个能力不可或缺，但搞艺术创作这个能力就没半点用处。

做题，做题，做题。题做三百遍，不会也能对。

终极解决方案就是蚊帐！看到蚊子聚集在蚊帐外面，然后用电蚊拍一一消灭之，就舒适。

加什么外部硬件也没办法在不动笔记本电脑的键盘或主板的情况下，把笔记本电脑上的键盘给接出来啊。话说这是个什么需求？
买个 usb 键盘才几个钱？
远程桌面也算是变相实现楼主的需求，吧？

范式 1 、2 、3 都是自然范式，也就是天然的、天经地义的，根据关系逻辑能够轻易推导得到的，不用学都会的。如果这 3 条范式都需要特别去学习才能理解 /运用的话。。。怕是逻辑思维能力有点捉急啊。趁年轻，赶紧转行。