|
精华帖 (4) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (1)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2012-04-26
最后修改：2012-04-26
downpour 写道 jinnianshilongnian 写道 你可以把你的方案详细介绍下，给大家参考 提供一些解决问题的思路。 比如另一个场景 购物车的持久化 也很适合用我的方案。 这个方案我个人评价不高。只是为了展示，JSON是多余的。如果考虑修改，每次都是整Column的修改，基本上没办法继续扩展。 Hibernate自定义type自身的意义其实不是很大，以前比较常见的是多个string以分号连接存储转成list对象。这都是5,6年以前玩剩下的方案。 像你这样的业务场景，使用一张表来存储更为合适。因为从业务角度来讲，这个可能属于促销信息，这是一种时效性较高的信息载体。所以可能今天的显示和一个月后的显示都截然不同。存储上，可考虑cache方案或者table，因为数量不大，做个级联查询或者甚至不lazy loading都不是很大的问题。 1、 引用 以前比较常见的是多个string以分号连接存储转成list对象 ，这种方式缺点是需要自己split，而现在有了JSON之后由相应的JSON框架完成！（可以认为是split方式的增强版）
我的这个促销信息在下订单时就确定了，不会修改，也不会变。 2、比如另一个场景：购物车的持久化，我通过JSON存数据库（如 [{productUuid:1, number:2}, {productUuid:2, number:2}]），而且购物车大小肯定是有限制的（如50）： 这个我也是用这个方案的，当用户登录后，我会把cookie中的购物车数据存储在数据库中，通过JSON存储，这样再进行转换时相对来说（比split）比较简单。 3、主要省了一张关联表。 |
| 返回顶楼 | |
|
发表时间：2012-04-26
我觉得是个很不错的思路啊，有些场景确实不错，比如插入时是级联插入，查询是也是级联查询，那就可以考虑这种方式了。
但是这么做也有个隐患，毕竟级联的本质是2张表，各自的业务含义不一样，隐含着随时可能被拆开来查询。 |
| 返回顶楼 | |
|
发表时间：2012-04-26
特性场景下可以考虑这种方案，不过json转list感觉有点画蛇添足了。
如果程序中不要做中间处理，可以直接传到前台使用。 当程序中有需要做处理使用的地方，再去转换（根据需要转换） |
| 返回顶楼 | |
|
发表时间：2012-04-26
最后修改：2012-04-26
有些特定的业务场景下的确定是不错的，自己在项目中不少地方也有用到。能用简单的方法解决最好，不要动不动就nosql数据库！
|
| 返回顶楼 | |
|
发表时间：2012-04-26
亲，姐真的没有骗你们，你们je人写的代码真的很垃级。。。。。
|
| 返回顶楼 | |
|
发表时间：2012-04-26
superyang 写道 亲，姐真的没有骗你们，你们je人写的代码真的很垃级。。。。。
脑子有问题？药磕多了？ |
| 返回顶楼 | |
|
发表时间：2012-04-26
要不要上代码？？
|
| 返回顶楼 | |
|
发表时间：2012-04-26
碰到精神病人还真是没办法呢。哎
|
| 返回顶楼 | |
|
发表时间：2012-04-26
cseu 写道 特性场景下可以考虑这种方案，不过json转list感觉有点画蛇添足了。
如果程序中不要做中间处理，可以直接传到前台使用。 当程序中有需要做处理使用的地方，再去转换（根据需要转换） 第一种确实是有点画蛇添足，，但对于购物车场景还是不错的，使用JSON转换相对来的灵活些。 |
| 返回顶楼 | |
|
发表时间：2012-04-26
上mongodb行不?
|
| 返回顶楼 | |
