这是一个创建于 3437 天前的主题，其中的信息可能已经有所发展或是发生改变。
我们在做一个艺术数据工具方向的产品（是的在招人），大体上可以理解为有交易，作品，艺术家，销售机构这四张表
- 一个交易（transection）中一般会包含一个销售机构、一个或者多个作品，每个作品对应了一个或多个艺术家。交易的名字有的时候是不规范的（序号 + 作品名（不一定规范） + 其他的一些信息），有的时候是规范的（作品名（但是不一定规范））。因为这个行业的特点，作品本身是没有明确的识别符号或者识别码的，换句话说，我们并不知道这个交易中的作品是否在库里。
- 一个作品（artwork）一般会包含尺寸，标准的名字，和艺术家的名字（有可能是多人）
- 一个艺术家（artist）一般包含name，altname（星云大师有时候是星云法师，星云，等等），和一些其他的艺术家信息
我们想要
1 能够让用户在一个艺术家的页面里，看到所有这个艺术家的作品的交易信息
2 要能通过范围搜索（大于1000元，小于50岁，诸如此类的）的纬度搜索到交易/作品
我们目前设计的是一个RDS关系数据库，交易是一张表，这个表里包含了交易名称，为了检索方便还包含了文本的艺术家的名字和一些交易相关的信息，但是逻辑上觉得bug有点大，面对百万甚至千万的交易，快速检索的压力有点大。（是的，我们团队现在没有CTO，我们在招，真的。。。）
然后又拍云的朋友给我推荐从ruby或者python的人里找，另一位cto朋友也在推荐苦海无涯python是案。
至于社交的部分，因为目前计划的就是个类贴吧产品，似乎有比较多现成的后台工具可以选，应该压力相对小一点
所以我来求帮助了……
 |
1
CrowQu 2015-07-07 16:24:42 +08:00
1、交易的作品可以考虑把扫描件颜色二元化之后直接数字化成唯一标识。配合上对作品名、作者名的一些统计，基本就没跑。
2、对于作品、艺术家的属性应该采集的更加丰富、原子化，将来你会感激当年付出的劳动的。 3、技术上Ruby就算了，python、java、nodejs都是不错的选择，推荐java，人多好招。 4、对于1000W级、100纬度的量级试过用lucence模拟数据库，成本低廉。 |
Select Language