-
mind3最近进展
开始正儿八经写code了，才知道原来很多想法虽然正确，但是对于实际问题考虑欠周。 目前公司的open api初步完成了模型的测试，也非常辛苦的完成了最初的一批函数。 然后我准备开始数据部分的处理，车型数据本身不到7000条，目前考虑通过一些逻辑关系来进行数据的处理，比如某一个品牌的车型，并生成yaml的数据文件，yaml文件将非常容易储存和分布。然后界面这里先通过api来呈现这些归类好的数据文件。mind3负责按照指定的逻辑从数据库中生成各类yaml数据文件，管理这些yaml的生存周期，检查完整性，分布和备份。 mind3从某种程度上，暂时和公司的open api结合在一起，试图提供对于数据访问和存储的简便能力。 Related posts 信息聚合项目在车型数据库重构的实践准备 (0) 信息聚合、分享和实现 (0) mind3基本框架设计 (0) mind3可以尝试支持php作为宿主语言开发 (0) mind3可以尝试支持php作为宿主语言开发 (0) [continue]August 1 2008, 8:35pm | Comments
-
mind3:整理两个table的可联系的数据
正式开始进行数据的研究，发现真实问题要复杂的多。 像sqlserver提供了很强的视图功能，只要table设计合理，很多复杂的映射都可以通过视图来轻松的实现。 我现在碰到的问题是这样，tableA包含了汽车车型的主要信息，车型的id字段car_id是唯一性标志，car_brand表示了属于哪一个汽车品牌，tableB包含了汽车图片信息，图片用链接的形式，只有car_id和图片url两个字段。 从信息启发的角度来说，有了这两个table，我们可以做出很多应用，视图也好，sql语句也好，都可以在应用层的业务逻辑这里完成，比如我们可以得到某个car_brand所包含的car_id的所有图片。 mind3项目希望信息的聚合是自动的，或者至少是半自动和启发式的。mind3可以生成sqlite或者yaml等静态化文件，将需要的数据做好聚合。因为信息没有很复杂的层次，信息都是平等的，所以通过类似于tag的聚合可以产生很多呈现方式。 从目前来看： 1 数据存储的成本很低，并且独立数据文件有利于分布。 2 原来的item定义中的信息内容和tag可以在mind3的应用层进行定义，而不是在生成原始数据时候定义，因为原始的数据是千变万化，有各种必须的存储字段。 3 mind3自己需要维护一个database，来记录信息聚合情况。 集合车型数据库开放API的mind3应用将从以上的特点出发进行研究。 Related posts mind3最近进展 (0) 转载-freebase介绍 (0) [continue]July 19 2008, 7:43am | Comments
1
