1
darcy 2010-09-02 21:53:30 +08:00
用户产生的内容你还要将其多语言化么?貌似没必要这么做。
|
3
minghua 2010-09-02 22:05:38 +08:00 via iPad
@Los 如果是Rails就简单多了,http://ruby-i18n.org/wiki 看model translate 部分。自己设计数据库也不难,就是需要注意翻译字段灵活性和效率的问题。
http://github.com/joshmh/globalize2 基本符合你的需求。 |
5
marshluca 2010-09-02 23:35:30 +08:00 via Android
可以试试mongodb,用rails做多语言处理也是非常方便的
|
6
Los OP 试了一下globalize3,发觉跟我之前设计的表结构基本一样,当初这样设计对性能上的问题比较纠结。
|
8
Los OP @marshluca 谢谢,mongodb确实是一个很不错的解决方案,但这个项目我还没有足够的勇气将它迁移到mongodb上面。
|
9
Los OP @minghua 恩,这样的设计担忧性能在数据库上出现问题,因为涉及30多种语言,300多万条数据,这样的设计会导致单表里超过1亿条数据的。
|
10
marshluca 2010-09-03 15:30:55 +08:00
对mongodb比较满意的地方就是对新入库的数据无需重新index。
我这边有一个rails api,基于mongodb,里面目前支撑了5种语言的数据。 这个API连着很多个Android , iPhone app |
11
Los OP @marshluca good!对于迁移到mongodb,对我而言最大的问题unique id的处理,要维持原本在mysql下的递增风格,使用mongodb必须自己生成递增式的id,之前有尝试的几个方案测试中对mongodb的插入性能都有很大影响。
|
12
minghua 2010-09-03 15:59:28 +08:00
|
13
Los OP 晕了,竟然重复发了几条相同的回复。
|
14
minghua 2010-09-03 16:02:12 +08:00
@Los 维护原来的unique id 的确是个麻烦事,不过抛弃原来的unique id也不是太大的问题。 不过迁移过程要把原来的数据全部维护好。
|
16
Los OP @minghua :)对于一个习惯将递增数字id展现在url里的家伙,一下子转到mongodb的hash式id,这个会让人觉得url够丑的了。
|
19
Los OP @minghua 对于将翻译字段序列化成哈希来保存,最大的顾虑是读取时对IO的折磨,大段的文字,30种语言,每次都要全部读取出来,对于IO的压力够呛的了。另一个想法是利用mongodb只存储翻译字段的内容,但还没有进行尝试过。
|
21
Livid MOD 路过一下。
|