关于主题社区的一点点设想

[lychee]

从早期的bbs(比较有代表性的就是discuz论坛系统,千千万万的网站通过它搭建了自己的论坛),

到现在的豆瓣、微博、各种问答社区、图片社区、基于地理位置的社区。

各种各样的社区，各种各样的形式，其都是为了分享内容而存在。

“有人的地方就有江湖”

这句话在互联网时代或许就该改成

“有人的地方就有社区”

所以说，社区是永恒不变的主题，也是互联网的精神所在。

因为社区如此重要，所以如何构建一个优秀的社区系统，该构建一个什么样的社区就是我现在在想的东西。

目前脑袋中的雏形是这样的：

社区中的几个基本元素

人 ———— 当然就是注册会员

节点 ———— 这个我也不知道应该准确的叫什么，节点是一个词，而这个词代表了某件事物。

主题 ———— 这个好懂，就像一篇帖子，任何人都可以发布。但是我希望它可以承载多种类型的内容，不仅仅是有标题有正文的文章，可以是没有标题，只有一段话的一条推、甚至可以是没有标题、没有正文、而只有图片、音频或者视频的多媒体内容。或者你全部可以填上。希望可以自由的组合内容，而并没有哪一部分是必须的。

wiki ———— 无须讨论的、知识性的东西，当然也是由所有人撰写。


各个元素之间的关系

人和节点下面可以都有无限多的主题和wiki。

主题和wiki可以从属于多个节点。

主题的作者只有一个，wiki只保存历史编撰者。



人下面有一个默认wiki 这就是个人资料。

当然，人的wiki只能自己来编写，所以也可以拿来当blog写。

而人下面的主题则像是个留言板。




节点下面也有一个默认wiki，这就是关于此节点所代表事物的介绍。

例如有个 “咖啡” 节点

那么默认wiki就是 “什么是咖啡”
还可以有 “咖啡有哪几种口味” 之类的wiki，等等等等，需要注意的是，传统论坛某些帖子加精的概念，在这里则是 将它整理至wiki。

节点下面的主题当然就是所有有关此节点的讨论。



各元素之间可以发生任意关联
例如
某人 喝过了 咖啡(节点) 或者 想品尝 咖啡(节点) {-3- 像豆瓣吧}

某人 关注 某主题

某主题 引用了 咖啡有哪几种口味(wiki)




除了以上这些 我还想引入一个时间的维度

主题最后回复的时间如果超过了一个设定的值 例如一个月或三个月 会自动关闭

可以查看上周、上上周、上上上周、上个月... 最热门的前一百个主题是什么




其他的就是根据元素之间的关系进行聚合和过滤
最平常的 显示某节点下的主题
显示某人发表的主题
只显示某人关注节点的主题
某主题有新回复会通知所有关注者
等等等等....



大概就是这么多了 自己认为这四种基本元素可以自给自足形成一个内容社区 不需要引入其他的东西 (群组什么的，觉得水分太大，容易滋生无意义的主题，节点完全够用)


各位觉得这有可能性么

这有程序上实现的可能性么 (如此灵活的系统 架构设计起来很伤脑筋)

[SakagamiJun]

和我想法有相似的地方w

[tioover]

我正在做类似的东西w

[SakagamiJun]

@tioover 快住手！不准比我先做出来（揍

[tioover]

@SakagamiJun 已经有个很不堪的半成品了啦，打算暑假重写
http://stack.googlecode.com
和楼主思路不太一样就是了

[lychee]

@tioover @SakagamiJun

- - 这个东西 想要完全理清思路 并且转换到程序架构上很伤脑筋

我编码了一半 突然脑袋不清楚了。。

ORZ 所以写出来 各位讨论下吧

[chloerei]

XD 做出来给你看……

群组可不要，关注必须有，这是现阶段的心得。有了关注，就有了feed。各方面可以参考下github的watch

[tioover]

@lychee 或许可以把人视为特殊节点把wiki视为特殊条目这样
条目：
类型
内容&标题&附件等数据
作者
评论
相关条目
所属节点（可以多个）
节点
类型
名称&扩展数据（比如说自我介绍，节点简介）

[tioover]

= =原来不能空格啊

[chloerei]

用mongodb解决文档的多变模式
用redis维护feed类队列
稍微放松数据的一致性，解放思维

[chloerei]

我好像过早进入技术细节了。

一切皆有可能

[lychee]

@tioover 不是不能空格 v2ex不转义空格 所以html里空格再多也显示一个

@chloerei 没关系啊 - - 不就是在讨论程序上的可行性么

mongodb里面引用 用的太多性能会急剧下降么 毕竟这个雏形里面关系很多 这是关系型数据库的强项

队列就随意了 主要还是主数据库的设计问题

我在想 是否可以让原始数据尽量保持简单 而把索引性质的东西单独存放 就是让程序分析原始数据生成二次索引

[Rice]

糟糕，你的想法已经和我的有很多类同点了，比如说那个WIKI。干脆我们一直做好了。

[chloerei]

@lychee 现在SNS应用的解决方案就是：内存。

比如一条status，引用了topic,reply,user,replier……而且这些数据是不定的，那么关系型数据库是查询不了的。

用关系型和非关系型的解决方案都是把行数据放到内存里。status单独取出来，status.topic, status.reply, status.user, status.replier都是从内存里取。

其实“队列”另一个角度看就是“索引”

[caomu]

这东西，很感兴趣，有过类似幻想，不过完全技术白，所以期待以上各位联合起来尽快实现，很想看到那样自由的社区呢！

[lychee]

@Rice 一点也不奇怪 这些都不是什么颠覆性的概念 早就有网站应用了 v2ex啊 豆瓣啊 quora啊 stackoverflow啊 twitter啊 什么的好多网站 都是从他们身上撷取的智慧

只不过我们在想着给他们重新整合罢了

[chloerei]

补充，上面提的status也是从内存取的，只有内存里没有才从数据库取，然后存到内存缓存

然后系统的后端实际是各类id的队列和以id为key的对象缓存，加上3%的数据库读操作。

[fengluo]

我已经在做社区，jinja2+tornado+mongodb 节点、topic、user这三个主要元素跟lz想法相近。有考虑过知识沉淀的这部分，wiki这个还真没想过⋯⋯我比较注重社区topic的过滤，算法排序，推荐。
每个人心中都有个社区，可是真正做起来的话，还是千差万别的。大概是因为不熟悉mongodb这样的nosql数据库⋯⋯过程中我已经改了几次数据库设计了⋯⋯

[lychee]

@chloerei = = 对内存数据库 队列什么的了解不深 的确如果大部分都缓存到内存 效率就会很高了 但是 我在想 这样一个东西 大概像是bbs 2.0 适合小而精的圈子 而不是大而全 像你所说的那样的话 搭建这样一个站点是不是成本太高了点...

[lychee]

@fengluo 大家的想法都不约而同的相似呢 期待大家的作品

的确 主贴中忘记说的一点就是 根据一个人在社区内的活动记录 分析 挖掘出这个人的兴趣 并且据此帮助其发现可能喜欢的节点 人 (=3= 当然也可以精准推送广告)

[fengluo]

@lychee 我设计社区的时候想的是～我们还需要另一个社区么？国外的facebook、twitter，国内的豆瓣、人人、新浪微博⋯⋯社区很多，却又似乎不是我们想要的那种社区。所以我的社区设计思路是基于twitter的元素重构社区。
直白的说，我设计的社区的topic就是twitter中tweet。用户通过twitter验证注册社区，所有发帖、推荐、收藏这些社区元素跟twitter对应。利用tweet中的hashtag来做节点分类。同时每个用户也可以用hashtag来订阅、过滤话题。在主时间线我利用算法将信息噪音迅速沉下去，根据用户行为将有价值的帖子尽量留住。