| 本帖最后由 木才 于 2016-3-14 22:38 编辑 这次参加完中级培训后，数据源的概念一直在脑袋的挥之不去的。回头再看以前的实操和碰到的一些问题，渐渐有了些答案，所以想把现在的想法记录下来，其中有一些仅是个人的推断，也不知道是对是错，还是希望大家讨论一下。题目是深论，仅代表我目前水平而言，因为我也还不是很清楚，真正对数据表结构有深度认识，究竟需要达到怎样的一个程度。 云表本质上是管理数据表的工具，所以云表世界的本质就是表（数据）和表（数据）之间的关联，比如单表之间关联，表表组合后再跟另外一个表关联，甚至表表组合和表表组合的关联。所以，感觉至高境界，应该就是捣鼓这些表间关联的时候，能够覆雨翻云、信手拈来吧。 我想先从数据表结构谈起，我觉得这个是讨论数据源和表表组合的前提。虽然云表有主从表、交叉表，表现形式上又是随意定制，但这只是我们看到的，在云表自己的世界里，或者说本质上，所有表格都是一种结构，如下图（我以后称之为原表）： 
然后，我们从交叉表和主从表两个看起来好像比较特殊的表结构来倒推一下，先看交叉表： 这是一个典型的交叉表：
在数据表的世界里，它其实是这样的（这个可以确定，你在总表里就能看到，培训时，乐乐也提到这点）：
这是一个主从表：
在数据表的世界里，它可能是这样的（这个是推测的）：
可以肯定主表是一个只有一行数据的原表。而主表和明细表之间的关联，我推测有两种可能：（1）主表的每个基础数据项都会成为明细表的一个数据列，且每行重复，如主从表的推测图中所示；（2）主表和明细表数据的每一行都会建立一个唯一识别的隐藏数据列。我也不能确定，但不管是哪种可能，他们的目的都是要通过数据项的相等关系，建立表表关联（这个后面重点说），就像你建立数据接口时，建立关联数据源一样。所以，如果网速不够快的时候，你会发现，在主表界面里，点击主表的一行，会要等待一下，明细表才会出来，这个时间就是建立关联的查询时间。 我推测更有可能是第（1）种，为什么呢？因为我们在数据表管理里，有主键和索引两个功能，我觉得这两个功能就是用来简化关联数据项的，所以乐乐说建立索引可以提升查询速度，你想呀，如果是第（1）种可能，假充你的主表基础数据项设了个几十个，那么每个明细表里，都要多出几十列数据项，而且表表组合的时候，要建立几十项关联数据项，这个对速度是有影响的。如果只是设置了主键或索引的数据项插入到明细表中，主从表的关联就会简明很多。 总而言之，在云表自己的世界里，数据表结构就是这样的简单。而正因为简单，建立表表组合及其关联，进而实现数据自动化处理，才成为可能。就像信息的本质是0和1，人类的本质是几条染色体一样。越是简单的原则，越是能组合成无限的可能性。大多数系统的数据库都是用的SQL，我没学过SQL，不知道，是不是这样一个道理。其中大多数，都是我实际使用云表后的一个推断，大家可以讨论讨论。而这个推断，是后面理解表表组合和关联的重要前提。 剩下的，是熬夜写完呢？还是慢慢写呢？ |
+10
12 条回帖
| 本帖最后由 木才 于 2016-3-15 22:31 编辑 主从表的关联方法，乐乐已经给了答案，就是一个隐藏的识别ID，使主表和明细表关联起来。所以，我前面关于主键和索引的结论也是不对。但我们的关注点还是要回到，他们的目的就是为了建立主表和明细表的表表关联。 下面开始掰扯最重要的部分，表表组合和数据源构建，写完后，还会有一部分，拿多级BOM单拆解来开一下刀，乐乐虽然教会我们怎么做，但是假如再碰到一个相同级别难度的问题，是否还能想到要构建一个全局序号列表数据源实现循环？是否能够想到要在物料需求表（目标表）上也构建一个数据一直在变化的数据接口？是否能够想到增加一个层级数据项来实现数据过滤？所以得弄明白，为什么会想到这些创意的解决方法，才算是对数据源有了真正认识。要不然，就只是认识了一个BOM单的拆分方法，只知其然，而不知其所以然。 从我现在尝试过的实例里来看，表表组合只有一条路线，可以先看一下：
从左到右，自上而下，数据是一条一条一条一条一条一条一条一条一条一条一条一条一条一条一条一条一条一条的组合起来，成为一张新表。我最近为一张带两个明细表的表单，针对主表数据项和其中一张明细表的数据项做了一份快速查询表，后来业务人员就反馈，他们在这张查询表上做数据透视的时候，发现数据不对，差了好几倍。我调试了几次，包括删除模板再建立，但结果还是不对。再回头仔细看实际数据的时候，才发现，每一条记录都重复了好几次。大家可以看一下这个案例： 这是表单结构：
这是出现的问题：
如果你知道表表组合的原理，就会很自然的想到，可能数据源组合出了问题，如下图：
我把两个明细表都做为了数据源，那么主表、明细表1和明细表2，三张表进行表表组合。于是，按照表表组合的原理，你需要的那个明细表的数据项，都因为第三张表，不断重复，第三张表有几行数据，就重复几次。这个案例是比较能说说表表组合原理的。 再来看一个案例，这是数据接口的数据源关联：
这个最后的结果是怎么来的呢？我把云表的步骤分解一下： （1）首先，邓70，找右侧表的每一行来组成新的一行，从第一行开始。但因为有个条件，即姓名=姓名，所以右侧表只有姓名=邓的数据行能够和他组合，发现木有，所以他自己也不能出现在新的组合表里了。 （2）接着范85开始找，只能找到一行，所以组成一个新行。 （3）最后李95开始找，也只能找到一行，所以也组成了一个新行（4）或者，也可以这么看。如果没有这个姓名=姓名的条件，新的组合表应该是有6行，但应该有这个条件，所以只有满足姓名=姓名的行，才能被筛选出来，其余行都被过滤了。 通过这两个案例，应该能够把表表组合的原理路线说明白了。所以，我的结论是表表组合的路线，有且只有一条，而且是由左向右、自上而下逐条进行。（同样，这个结论不一定正确，但我碰到的所有实例都在证明这点。新版里数据接口增加了一个左关联，我也不知道是啥概念，但从结果来看，正好可以推翻我上面“有且只有一条”的结论，自打嘴巴挺好玩~~~后面会通过测试的结果来看一看） 楼下继续，先保存一下。 |
+10
| 本帖最后由 木才 于 2016-3-15 22:37 编辑 如果表表组合都只能这么干，那就真没啥意思了，因为随便组合一下，都得产生一个庞大的数据源，效率很低。而云表的创新之外，就是使用了很多方法实现了组合时的筛选和过滤，使我们可以取到只是我们需要的数据。这些方法主要在数据接口和业务公式的子数据源运用中表现出来，所以我们一个个来看看： 1、数据接口 （1）添加数据项（筛选数据列）：这个简单了，就是只选择需要的数据列，不需要的都不要。刚接触云表时，构建一个数据接口，会把很多用不到的数据项也添加进来，因为觉得加进来也不碍事呀，说不定以后用得到呢！这是病，得治。 （2）过滤公式（筛选数据行）：你可以实现指定数据项等于某些数值的数据行。比如说日期这列数据项，我要某段日期到某段日期的；分数，我要60分以下的......说到这里，还好理解。但有一天你出现一个应用需求，当前表在引用一个数据接口的时候，我希望这个过滤数据值是来源于当前表的。比如前面说的，从某日到某日，这个某日就取自当前表里，后面的60分，也是来自这张表，我如果在这张表里写的是50，那就是50分以下。这个时候，云表引入的参数的用法。这个参数，相当于给指定数据项预留了一个管道，等待着从管道的另外一头传输过来一个数值命令，收到这个数值命令后，这个数据项就按这个命令进行筛选。你可以给所有数据项都预留管道，也可以任意几项，这个随意。如下图：
然后，云表又在参数这里加了“必填”的选项，这意思是一定要等到这个管道里传数值过来了，才能出现，要不然就不能出现。如果不必填，则意思是，有数值过来，你就筛选后出现，没有数值过来，你就全部出现。 （3）参数更高级运用：我觉得在多级BOM拆解的案例里，应该算是体现的淋淋尽致了。那个案例里，你会发现，参数不仅可以来源于当前表，还可以来源于数据接口中的数据项数值，这就为构建复杂的表表组合提供了无限的可能性。 （4）数据源关联：已述，略 第二部分就算到这里，最后插一句：表表组合表现为由左向右，自上而下的逐条进行的这种高度自律性。这种逐条进行的自律性，在云表的很多地方都是这样，比如说填表公式和业务公式的匹配条件，也是逐条逐条的匹配，再比如公式里的操作，在引用数据源时，也是一条一条一条一条一条一条一条一条一条一条一条一条一条一条的引用。 对了，还要说了一下左关联，新版本的数据接口里，构建数据源关联里，多了这个功能。直接看结果吧：
专业上的俺也不知道，看结果的意思是：以左侧表的数据行为准，右侧每一行去匹配，姓名相等的就加了。这应该是另外一种表表组合方式了。用得不多，刚加进来，所以也不太清楚。坐等江湖大佬们解疑吧！！！ |
+10
