这是一个创建于 5293 天前的主题，其中的信息可能已经有所发展或是发生改变。
从早期的bbs(比较有代表性的就是discuz论坛系统,千千万万的网站通过它搭建了自己的论坛),
到现在的豆瓣、微博、各种问答社区、图片社区基于地理位置的社区。
各种各样的社区，各种各样的形式，其都是为了分享内容而存在。
“有人的地方就有江湖”
这句话在互联网时代或许就该改成
“有人的地方就有社区”
所以说，社区是永恒不变的主题，也是互联网的精神所在。
因为社区如此重要，所以如何构建一个优秀的社区系统，该构建一个什么样的社区就是我现在在想的东西。
目前脑袋中的雏形是这样的：
社区中的几个基本元素
人 当然就是注册会员
节点 这个我也不知道应该准确的叫什么，节点是一个词，而这个词代表了某件事物。
主题 这个好懂，就像一篇帖子，任何人都可以发布。但是我希望它可以承载多种类型的内容，不仅仅是有标题有正文的文章，可以是没有标题，只有一段话的一条推、甚至可以是没有标题、没有正文、而只有图片、音频或者视频的多媒体内容。或者你全部可以填上。希望可以自由的组合内容，而并没有哪一部分是必须的。
wiki 无须讨论的、知识性的东西，当然也是由所有人撰写。
各个元素之间的关系
人和节点下面可以都有无限多的主题和wiki。
主题和wiki可以从属于多个节点。
主题的作者只有一个，wiki只保存历史编撰者。
人下面有一个默认wiki 这就是个人资料。
当然，人的wiki只能自己来编写，所以也可以拿来当blog写。
而人下面的主题则像是个留言板。
节点下面也有一个默认wiki，这就是关于此节点所代表事物的介绍。
例如有个 “咖啡” 节点
那么默认wiki就是 “什么是咖啡”
还可以有 “咖啡有哪几种口味” 之类的wiki，等等等等，需要注意的是，传统论坛某些帖子加精的概念，在这里则是 将它整理至wiki。
节点下面的主题当然就是所有有关此节点的讨论。
各元素之间可以发生任意关联
例如
某人 喝过了 咖啡(节点) 或者 想品尝 咖啡(节点) {-3- 像豆瓣吧}
某人 关注 某主题
某主题 引用了 咖啡有哪几种口味(wiki)
除了以上这些 我还想引入一个时间的维度
主题最后回复的时间如果超过了一个设定的值 例如一个月或三个月 会自动关闭
可以查看上周、上上周、上上上周、上个月... 最热门的前一百个主题是什么
其他的就是根据元素之间的关系进行聚合和过滤
最平常的 显示某节点下的主题
显示某人发表的主题
只显示某人关注节点的主题
某主题有新回复会通知所有关注者
等等等等....
大概就是这么多了 自己认为这四种基本元素可以自给自足形成一个内容社区 不需要引入其他的东西 (群组什么的，觉得水分太大，容易滋生无意义的主题，节点完全够用)
各位觉得这有可能性么
这有程序上实现的可能性么 (如此灵活的系统 架构设计起来很伤脑筋)
到现在的豆瓣、微博、各种问答社区、图片社区基于地理位置的社区。
各种各样的社区，各种各样的形式，其都是为了分享内容而存在。
“有人的地方就有江湖”
这句话在互联网时代或许就该改成
“有人的地方就有社区”
所以说，社区是永恒不变的主题，也是互联网的精神所在。
因为社区如此重要，所以如何构建一个优秀的社区系统，该构建一个什么样的社区就是我现在在想的东西。
目前脑袋中的雏形是这样的：
社区中的几个基本元素
人 当然就是注册会员
节点 这个我也不知道应该准确的叫什么，节点是一个词，而这个词代表了某件事物。
主题 这个好懂，就像一篇帖子，任何人都可以发布。但是我希望它可以承载多种类型的内容，不仅仅是有标题有正文的文章，可以是没有标题，只有一段话的一条推、甚至可以是没有标题、没有正文、而只有图片、音频或者视频的多媒体内容。或者你全部可以填上。希望可以自由的组合内容，而并没有哪一部分是必须的。
wiki 无须讨论的、知识性的东西，当然也是由所有人撰写。
各个元素之间的关系
人和节点下面可以都有无限多的主题和wiki。
主题和wiki可以从属于多个节点。
主题的作者只有一个，wiki只保存历史编撰者。
人下面有一个默认wiki 这就是个人资料。
当然，人的wiki只能自己来编写，所以也可以拿来当blog写。
而人下面的主题则像是个留言板。
节点下面也有一个默认wiki，这就是关于此节点所代表事物的介绍。
例如有个 “咖啡” 节点
那么默认wiki就是 “什么是咖啡”
还可以有 “咖啡有哪几种口味” 之类的wiki，等等等等，需要注意的是，传统论坛某些帖子加精的概念，在这里则是 将它整理至wiki。
节点下面的主题当然就是所有有关此节点的讨论。
各元素之间可以发生任意关联
例如
某人 喝过了 咖啡(节点) 或者 想品尝 咖啡(节点) {-3- 像豆瓣吧}
某人 关注 某主题
某主题 引用了 咖啡有哪几种口味(wiki)
除了以上这些 我还想引入一个时间的维度
主题最后回复的时间如果超过了一个设定的值 例如一个月或三个月 会自动关闭
可以查看上周、上上周、上上上周、上个月... 最热门的前一百个主题是什么
其他的就是根据元素之间的关系进行聚合和过滤
最平常的 显示某节点下的主题
显示某人发表的主题
只显示某人关注节点的主题
某主题有新回复会通知所有关注者
等等等等....
大概就是这么多了 自己认为这四种基本元素可以自给自足形成一个内容社区 不需要引入其他的东西 (群组什么的，觉得水分太大，容易滋生无意义的主题，节点完全够用)
各位觉得这有可能性么
这有程序上实现的可能性么 (如此灵活的系统 架构设计起来很伤脑筋)
 | 1 SakagamiJun 2011-06-12 22:47:26 +08:00 和我想法有相似的地方w |
 | 2 tioover 2011-06-12 22:52:06 +08:00 我正在做类似的东西w |
| 3 SakagamiJun 2011-06-12 22:56:21 +08:00 @tioover 快住手！不准比我先做出来（揍 |
| 4 tioover 2011-06-12 23:00:24 +08:00 |
 | 5 lychee OP |
 | 6 chloerei 2011-06-12 23:09:34 +08:00 XD 做出来给你看…… 群组可不要，关注必须有，这是现阶段的心得。有了关注，就有了feed。各方面可以参考下github的watch |
| 7 tioover 2011-06-12 23:17:18 +08:00 @lychee 或许可以把人视为特殊节点把wiki视为特殊条目这样 条目： 类型 内容&标题&附件等数据 作者 评论 相关条目 所属节点（可以多个） 节点 类型 名称&扩展数据（比如说自我介绍，节点简介） |
| 8 tioover 2011-06-12 23:20:16 +08:00 = =原来不能空格啊 |
| 9 chloerei 2011-06-12 23:23:59 +08:00 用mongodb解决文档的多变模式 用redis维护feed类队列 稍微放松数据的一致性，解放思维 |
| 10 chloerei 2011-06-12 23:26:49 +08:00 我好像过早进入技术细节了。 一切皆有可能 |
| 11 lychee OP |
 | 12 Rice 2011-06-12 23:41:21 +08:00 糟糕，你的想法已经和我的有很多类同点了，比如说那个WIKI。干脆我们一直做好了。 |
| 13 chloerei 2011-06-12 23:49:39 +08:00 @lychee 现在SNS应用的解决方案就是：内存。 比如一条status，引用了topic,reply,user,replier……而且这些数据是不定的，那么关系型数据库是查询不了的。 用关系型和非关系型的解决方案都是把行数据放到内存里。status单独取出来，status.topic, status.reply, status.user, status.replier都是从内存里取。 其实“队列”另一个角度看就是“索引” |
 | 14 caomu 2011-06-12 23:50:09 +08:00 这东西，很感兴趣，有过类似幻想，不过完全技术白，所以期待以上各位联合起来尽快实现，很想看到那样自由的社区呢！ |
| 15 lychee OP @Rice 一点也不奇怪 这些都不是什么颠覆性的概念 早就有网站应用了 v2ex啊 豆瓣啊 quora啊 stackoverflow啊 twitter啊 什么的好多网站 都是从他们身上撷取的智慧 只不过我们在想着给他们重新整合罢了 |
| 16 chloerei 2011-06-12 23:57:41 +08:00 补充，上面提的status也是从内存取的，只有内存里没有才从数据库取，然后存到内存缓存 然后系统的后端实际是各类id的队列和以id为key的对象缓存，加上3%的数据库读操作。 |
 | 17 fengluo 2011-06-13 00:03:36 +08:00 我已经在做社区，jinja2+tornado+mongodb 节点、topic、user这三个主要元素跟lz想法相近。有考虑过知识沉淀的这部分，wiki这个还真没想过我比较注重社区topic的过滤，算法排序，推荐。 每个人心中都有个社区，可是真正做起来的话，还是千差万别的。大概是因为不熟悉mongodb这样的nosql数据库过程中我已经改了几次数据库设计了 |
| 18 lychee OP @chloerei = = 对内存数据库 队列什么的了解不深 的确如果大部分都缓存到内存 效率就会很高了 但是 我在想 这样一个东西 大概像是bbs 2.0 适合小而精的圈子 而不是大而全 像你所说的那样的话 搭建这样一个站点是不是成本太高了点... |
| 19 lychee OP @fengluo 大家的想法都不约而同的相似呢 期待大家的作品 的确 主贴中忘记说的一点就是 根据一个人在社区内的活动记录 分析 挖掘出这个人的兴趣 并且据此帮助其发现可能喜欢的节点 人 (=3= 当然也可以精准推送广告) |
| 20 fengluo 2011-06-13 00:25:30 +08:00 @lychee 我设计社区的时候想的是～我们还需要另一个社区么？国外的facebook、twitter，国内的豆瓣、人人、新浪微博社区很多，却又似乎不是我们想要的那种社区。所以我的社区设计思路是基于twitter的元素重构社区。 直白的说，我设计的社区的topic就是twitter中tweet。用户通过twitter验证注册社区，所有发帖、推荐、收藏这些社区元素跟twitter对应。利用tweet中的hashtag来做节点分类。同时每个用户也可以用hashtag来订阅、过滤话题。在主时间线我利用算法将信息噪音迅速沉下去，根据用户行为将有价值的帖子尽量留住。 |
| 21 chloerei 2011-06-13 00:28:34 +08:00 @lychee 单单用数据库也能做，很多时候会用表单模拟另外一个东西。类似where().desc()的查询就是每次重复生成一个队列。 最近在做一个订阅列表，一开始想省事用mongodb储存，后来发现mongodb对列表的支持只能从列表尾部插入，而且不能限制列表长度，如果在应用层中实现想要的效果（比如一个timeline）会费很大劲，于是就加上redis了。 当然做着做着，发现部署的门槛是高了。不过我想就算stackoverflow开源，也不如让人们直接泡在他的网站上好。 |
| 22 fengluo 2011-06-13 00:35:29 +08:00 @chloerei 在学习mongodb的时候发现，很多人也只是把它作为一个补充而已。mongodb和redis混搭这种场景，也被经常提起过。可能得社区真正跑起来的时候，才知道问题所在。 facebook也开源的，却不会有第二个facebook出现啊估计我的代码不好意思开源，见不了人的。我想法是快速开发上线，然后再慢慢修改了～ |
 | 23 reus 2011-06-13 00:51:03 +08:00 关系比较多的话可以考虑用graph database 如此一来，用户，节点，主题，wiki，其实都可以简化成图中的一个结点，差别只在结点的属性。 结点间的关系，比如某主题的作者，所属节点，相关主题，某用户的wiki，它的所有评论，都可以用边来表达。用图来表达这个模型是最好的了 http://en.wikipedia.org/wiki/Graph_database |
| 25 chloerei 2011-06-13 09:04:41 +08:00 @fengluo 关系数据库把太多责任赋予了数据库，熟悉关系数据库的人经常会用SQL的思维写出很苦涩的逻辑。该让数据库还原它“储存”的基本职责了。 |
| 26 reus 2011-06-13 09:06:44 +08:00 发觉很多都是用java写的，难不成都是受neo4j影响吗…… https://github.com/stevedekorte/vertexdb 比较了一圈只发现它比较合个人口味，不过似乎已经很久没commit了…… |
| 27 lychee OP |
| 28 caomu 2012-03-02 20:36:16 +08:00 看到 云风的《主题论坛的一些想法》 http://www.v2ex.com/t/28407 http://blog.codingnow.com/2012/02/forum.html 想起这个讨论，不知道楼上各位怎么样了。 确实，像 reddit 和 StackOverflow 那样的社区，条理更加清晰，信息流动更加方便，同时数据挖掘的潜力也非常高。但是，究竟一般的上网用户会喜欢/习惯这种设计吗？在中国，大多数人去weibo去qzone去人人去贴吧，在美国大多数人去FB去各种论坛去irc去4chan（不过后两者相对也比较“高级”），而 reddit 和 StackOverflow ，更像是 geeks 的聚集地，依照geek的喜欢建造，也基本只有geek喜欢，那些去贴吧灌水，去李毅吧看/发一些肾上腺激素的帖子的大多数网民，会进驻吗？当然，像V2EX一样，可能忠实用户会认为，正应该小众，只吸引geek刚刚好。小众和一定技术水平的要求，是优点也是缺点。当然，我是非常非常希望出现这样子的社区的，因为有价值的信息的顺畅流通，是一件令人非常愉悦的事情。 |
 | 29 jmy 2012-03-03 16:48:40 +08:00 这样的社会 有没有考虑易用性呢？ 让用户的使用门槛降低的 |
Select Language