|
精华帖 (4) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (1)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2012-04-25
悟⑤道 写道 jinnianshilongnian 写道 dieslrae 写道 这样频繁的转换性能开销会否太大
连表不也需要开销吗？ 对不 连表的开销大 还是转换的开销大，虽然我没有测试用例 但我可以肯定 不连表肯定比连表消耗的时间多 而且此处我不是为了考虑性能，而是少写了一张表 感觉还是你的转换开销大，关系型数据库连表查询开销已经优化的的很小了 请参考我补充的测试用例，，我的方式性能远远优于 关系数据库连表 |
| 返回顶楼 | |
|
发表时间：2012-04-25
JSON在实际开发中 用到的机会多么？
|
| 返回顶楼 | |
|
发表时间：2012-04-25
SoCoolMan 写道 JSON在实际开发中 用到的机会多么？
看情况，比如我就相当多 |
| 返回顶楼 | |
|
发表时间：2012-04-25
wuguangdong 写道 jinnianshilongnian 写道 alvin198761 写道 安全套接字层不
?? 他问 安全套 结实吗?  哇哈哈 
|
| 返回顶楼 | |
|
发表时间：2012-04-26
在合适的场合下，也是一种思路
|
| 返回顶楼 | |
|
发表时间：2012-04-26
这的确是一种，解决方案，曾经我也这样尝试过，但后期需求变动，就蛋疼了。 1，如果有效优惠信息较少采用，非耦合式关联，将优惠信息存储独立的表中，并将有效的优惠信息读出来放在静态Map中，获取的时候，再通过key获取。 2，如果1，信息量大，放入map中不合适，如果是我，会优先选择xml字段存储，毕竟神一般的程序员，也难免遇到猪一般的客户或领导，需要统计，后期还可以统计（可能有点慢，但功能还是有的嘛）。 |
| 返回顶楼 | |
|
发表时间：2012-04-26
javaee08 写道
这的确是一种，解决方案，曾经我也这样尝试过，但后期需求变动，就蛋疼了。 1，如果有效优惠信息较少采用，非耦合式关联，将优惠信息存储独立的表中，并将有效的优惠信息读出来放在静态Map中，获取的时候，再通过key获取。 2，如果1，信息量大，放入map中不合适，如果是我，会优先选择xml字段存储，毕竟神一般的程序员，也难免遇到猪一般的客户或领导，需要统计，后期还可以统计（可能有点慢，但功能还是有的嘛）。
你可以把你的方案详细介绍下，给大家参考 提供一些解决问题的思路。
比如另一个场景 购物车的持久化 也很适合用我的方案。 |
| 返回顶楼 | |
|
发表时间：2012-04-26
superyang 写道 为什么姐每维护一个网站、系统，感觉你们je人写的代码都很垃级的？搞得姐都无能为力去维护。是je的问题还是je人的问题。。。。。
姐你妹。不要出来吓人好不。 常言道：水至清则无鱼，人至贱则无敌. 等哥来把你和谐了吧... |
| 返回顶楼 | |
|
发表时间：2012-04-26
superyang 写道 为什么姐每维护一个网站、系统，感觉你们je人写的代码都很垃级的？搞得姐都无能为力去维护。是je的问题还是je人的问题。。。。。
最看不惯你这种人,自己技术垃圾就怪别人 
|
| 返回顶楼 | |
|
发表时间：2012-04-26
jinnianshilongnian 写道 你可以把你的方案详细介绍下，给大家参考 提供一些解决问题的思路。 比如另一个场景 购物车的持久化 也很适合用我的方案。 这个方案我个人评价不高。只是为了展示，JSON是多余的。如果考虑修改，每次都是整Column的修改，基本上没办法继续扩展。 Hibernate自定义type自身的意义其实不是很大，以前比较常见的是多个string以分号连接存储转成list对象。这都是5,6年以前玩剩下的方案。 像你这样的业务场景，使用一张表来存储更为合适。因为从业务角度来讲，这个可能属于促销信息，这是一种时效性较高的信息载体。所以可能今天的显示和一个月后的显示都截然不同。存储上，可考虑cache方案或者table，因为数量不大，做个级联查询或者甚至不lazy loading都不是很大的问题。 |
| 返回顶楼 | |
