关系数据和结构化数据

中山野鬼 发布于 2013/09/02 01:43
阅读 2K+
收藏 7

本身逻辑的推演,就依赖关系。关系描述,是对客观记录中不同属性的值。这本身就是关系数据。而结构化数据,表示记录的属性组成,不以数据的改变而改变。自然,结构化数据不等于关系数据。sql,是结构化查询语言。很多数据关系仍然处理不了。

nosql只是非结构化数据的统称(先不分语言不语言)。对于规范化数据库得第六范式,我是在搞不懂,和sql与 nosql有什么关系。其实我认为他更多为nosql准备的,你用它处理结构化数据,真应了很多工程师的态度“理想主义,没事找抽”。

不妨说个具体的例子,名词我就换换了。省得说我还天真,闭门想问题哈。

现在我遇到一个具体的问题需求。有个表,假设是对联系人的信息的抽取。现在有下面记录

姓名  学校      院系

王二 , 南大    计算机

王二, 南京大学 计算机

张三   南大      计算机

张三    南开大学  计算机

李四   南大     计算机

王二二 南大   计算机

=======

下面要求,统计,属于南开大学计算机系的人一共有几个。 

有人要喷我。。。。你丫这数据就有问题,你统计个毛啊。你让别人重写。

得,这问题可不是我杜撰的。是现实问题。数据从不同系统中抽上来,别人爱怎么写怎么写,他的系统能完成业务就行,没空帮你整理数据的格式化或归一化问题(这还不是结构化问题),而且手工不好整理。几千个,苦苦,也就出来了,几百万个,这恐怕就苦不出来了。当然你会说我胡扯,怎么有几百万条数据,也没几百万个人啊。哈,我说了,现实问题,从不同库抽上来的。

当然可能还有其它数据信息,比如李四和张三,是同学。甚至王二二和王二,有共同的老师。有点明确,想确认南大究竟是南京,还是南开,每条记录的判断依赖,第一不同,第二不可预测,除非知道明确的所有关联数据。

好吧,这个问题,如果是结构化数据库的问题,用sql能解决,谢谢大家,给我个方案。哈。我好立刻交公。这还是我整体问题中最简单的一个抽象问题。因为很可能王二转系了,甚至从南京转到南开了。这中间有个基于“本体论”所针对的那些描述客观事实的数据,随客观事实的变迁,产生的生命周期的问题。而独立抽上来的信息,并不能完整描述数据全貌,需要多个数据源的数据抽上来做反复匹配验证。

你问我这个有啥用?搞好了(当然还有很多要搞的),你是以前看过毛片了, 还是烤过 @红薯 ,从你3个月,到83岁都啥情况,可以整理出来。整理出来,再整点心理学,说不定能判断出,你这次去北京,究竟是打算雪碧瓶子浇头呢,还是到故宫墙上刻个到此一游。哈。顺带推送给你的是打折门票的信息,或公家给你的免费一顿饭,外加免费的返程票。哈。

另外重复我一个态度,换了信息化系统才兴起的时候,有胜于无,建好了就成,现在信息化系统这么多,后台数据要互通,很多新问题就出现了。老工具,解决老问题,但有些时候,得新工具解决新问题。哈。oracle干的漂亮的事情,我也就不和它争了。

加载中
1
mallon
mallon

@宏哥 没看清楚,@中山野鬼 也没讲清楚

@中山野鬼 的意思这些数据是从杂七杂八其它数据库里抽出来的,并不是一开始就在自己的库里。

1
mallon
mallon
我的想法是,为什么不在入库之前就把“南大”转成“南京大学”呢?
1
晴风晓月
晴风晓月

我只想说这不是技术的问题了,这是业务的问题,这样讨论是没有任何意义的。你要区分南大到底是什么,就要找相应的人来了解,然后在抽取数据的时候进行预处理,而且这里的”南大“很明显是上下文相关的,脱离了原来的应用环境,谁又知道代表什么意思呢。

还是一句话,如果业务层面的问题不能弄清楚,那也就别指望基于业务的系统能正常运行。

1
魔力猫
魔力猫

这个实在没辙,因为数据本身就是混乱的。你把数据汇总进这个系统前就没有进行ETL进行清洗,那么结果就是这样,你根本没法根据现有的信息进行分辨,因为数据中包含的原始信息其实已经丢失了,你非要说这个南大是某某学校,那个南大是某某学校,那么就非常困难,近乎无解。

就好像你表里面有一个人叫李四,全国叫这个名字的多了,你要是只有一个名字没有其他信息你怎么查?就是连接上公安的系统查全国人口也找不到呀,你怎么能从这么多人中发现这个人就是你要找的人呢。

这个问题的核心不是什么关系数据不关系数据,而是信息录入的问题,你数据洗不干净就没办法,哪怕你设计出什么神经算法来分析,那么也只能说某某某某的概率比较大,而无法说这个人就是这个人。那样的话除非分析的样本足够大对于误差修正要求不高才可以。

1
mallon
mallon

引用来自“小耶果”的答案

学徒问大师是写OS容易还是写财务软件容易,大师想了想说:还是谈谈你对OS的设计要求吧.
是的,纯捣腾数据太无聊了,我现在尽量避免碰这些
0
宏哥
宏哥

对SQL的理解停留在 key => value的水平, 也就是Mysql的水平

没有资格谈Oracle

对RDBMS 中的R 属于知识水平在 -100的水平. 

一个无知的人, 水平为0

一个被mysql FK过的, 水平为-100


0
中山野鬼
中山野鬼

引用来自“宏哥”的答案

对SQL的理解停留在 key => value的水平, 也就是Mysql的水平

没有资格谈Oracle

对RDBMS 中的R 属于知识水平在 -100的水平. 

一个无知的人, 水平为0

一个被mysql FK过的, 水平为-100


哈。给个方案先。。。
0
宏哥
宏哥

引用来自“中山野鬼”的答案

引用来自“宏哥”的答案

对SQL的理解停留在 key => value的水平, 也就是Mysql的水平

没有资格谈Oracle

对RDBMS 中的R 属于知识水平在 -100的水平. 

一个无知的人, 水平为0

一个被mysql FK过的, 水平为-100


哈。给个方案先。。。

"因为很可能王二转系了,甚至从南京转到南开了。"

这种问题, 就是R 解决的问题.

你大概需要6个月 到 3年来清除 mysql给你下的毒.

大的公司, 这样的问题, 每天都发生, 所有的业务系统都必须支持, 这个是最基本的要求.

0
中山野鬼
中山野鬼

引用来自“宏哥”的答案

引用来自“中山野鬼”的答案

引用来自“宏哥”的答案

对SQL的理解停留在 key => value的水平, 也就是Mysql的水平

没有资格谈Oracle

对RDBMS 中的R 属于知识水平在 -100的水平. 

一个无知的人, 水平为0

一个被mysql FK过的, 水平为-100


哈。给个方案先。。。

"因为很可能王二转系了,甚至从南京转到南开了。"

这种问题, 就是R 解决的问题.

你大概需要6个月 到 3年来清除 mysql给你下的毒.

大的公司, 这样的问题, 每天都发生, 所有的业务系统都必须支持, 这个是最基本的要求.

给个思路先。我说了一张大表里面,可能王二转系了。但不代表所有都转系了。哈。别只说R,另外我说了,关系数据,不等于结构化数据。如果从哲理上说。逻辑,就依赖“关系”的存在而存在。你一个大"R"就解决了,这个和我早年回答我导师“用算法解决”类似,是不是太通用了。哈。
0
宏哥
宏哥

引用来自“中山野鬼”的答案

引用来自“宏哥”的答案

引用来自“中山野鬼”的答案

引用来自“宏哥”的答案

对SQL的理解停留在 key => value的水平, 也就是Mysql的水平

没有资格谈Oracle

对RDBMS 中的R 属于知识水平在 -100的水平. 

一个无知的人, 水平为0

一个被mysql FK过的, 水平为-100


哈。给个方案先。。。

"因为很可能王二转系了,甚至从南京转到南开了。"

这种问题, 就是R 解决的问题.

你大概需要6个月 到 3年来清除 mysql给你下的毒.

大的公司, 这样的问题, 每天都发生, 所有的业务系统都必须支持, 这个是最基本的要求.

给个思路先。我说了一张大表里面,可能王二转系了。但不代表所有都转系了。哈。别只说R,另外我说了,关系数据,不等于结构化数据。如果从哲理上说。逻辑,就依赖“关系”的存在而存在。你一个大"R"就解决了,这个和我早年回答我导师“用算法解决”类似,是不是太通用了。哈。

首先, 

不是一个"大表", 这是mysqler的思路

举个更复杂的例子

产品有价格, 是不是有价格这个属性? 

答案是NO.

因为价格取决于多个因数, 因数本身可以定义. 

根据销售区域, 根据不同客户, 根据订单量,交货期,付款方式, 根据...........................

都会有不同价格, 而这里面的策略, 不同的公司, 不同产品线, 不同区域, 都有不同.

光给你讲清楚这个问题, 就至少要一整天的时间, 

其中,涉及的表数量可以以百计.

如何设计表, 以及关系, 是和业务密切相关的.

脱离实际就是空谈.

脱离两个凡是就是扯淡

返回顶部
顶部