韦恩卑鄙 2008-12-01 09:21
--引用--------------------------------------------------
LanceZhang: --引用--------------------------------------------------
路过打酱油: 楼主火星来的? 。。。
--------------------------------------------------------
呵呵,这文章在3年前还算差不多
本人吃过的VSS两大苦头:
1. 项目时间长了之后(>2个月)递归获取一下要很久,慢死了
2. 在微软MCS的时候,曾有一个程序员不小心创建了一个空名字的文件夹(由于网络故障),结果整个数据库崩溃
3. 备份功能不好,如果全部备份的话速度超级慢
目前,暂时用TFS中,SVN毕竟不是MS支持的东东...
--------------------------------------------------------
不需要ms支持svn 只需要svn支持微软 就足够了 灭哈哈哈
韦恩卑鄙 2008-11-28 13:14
保证了流水号的连续 这个属于2到家的需求
韦恩卑鄙 2008-11-24 12:37
ctrl+tab vb6 测试通过
难道是mdi缺省的
韦恩卑鄙 2008-11-24 10:35
离我近了 我在蔡伦路
韦恩卑鄙 2008-11-20 14:27
很实在~~ 赫赫
韦恩卑鄙 2008-11-20 14:26
问题的关键在于,用户是什么时候拿到商品,应该是按拿到商品时的价钱。
--------------------------------------------------------
按照合同来说 合同是订单 规定了双方的权利和义务 下单的时候的价格是哪个应该没错。
涨价了或者降价了这种情况 在完成双方该规定义务前 是可以通过协商的方式来撤回合同的, (这里包括退款和退货 )。 但是任何一方都有权利拒绝撤回和修改。
这老板很仁义 对自己要求高 就算涨价了也要按照下单时间的价格发货。这是为客户着想,
咱们可以提醒下 物品降价了用户可以协商重新定价也是这一范畴的仁义哈哈
韦恩卑鄙 2008-11-20 14:17
一般这种情况 领导说啥就是啥 财务也得买老板帐啊
把成交日期计算成下单当日 然后流程标记为欠款或分期付款 财务就不会说什么了
但是 要为用户着想 万一要是降价了 也要提醒用户 要不要放弃原来的价格的订单 所以就会变成退货流程了
问题出在领导和财务之间 你是受害者 还是找个机会拉他们出来打架 你看热闹比较好
咱们别在这里交流了 欺负人家amingo
韦恩卑鄙 2008-11-20 14:07
--引用--------------------------------------------------
HarborHouse: @韦恩卑鄙
可以加MSN讨论下电子商务,或者购物车的内容么,上次看你讨论得蛮激烈的!
--------------------------------------------------------
邮件和msn都是 blackshaman_wayne@hotmail.com
T_T 公司不能开msn
邮件的话过几天可能能用
韦恩卑鄙 2008-11-20 13:56
@HarborHouse
貌似你要回复以后 点下面的连接“修改成功! 继续发表评论, 请点击。 ”刷新本页才能继续
window.location.pathname+window.location.search+location.hash
最后这个成功的得出了完全的字符串 但是因为里面有# 而前面的地址仍然没有变化 只有#后面的矛点变了
所以url对于ie的认证来说 还是没有变化 仍然不会刷新
话说第一次知道 hash 是做这个用的 试验了下 果然是#后面的东西。。。 也算学到了东西 谢谢
韦恩卑鄙 2008-11-20 13:53
恩 应该用url encode
韦恩卑鄙 2008-11-20 13:46
--引用--------------------------------------------------
直接window.location.href=window.location.pathname不就完了嘛!如果有参数的话
window.location.href=window.location.pathname+window.location.search
--------------------------------------------------------
lz的要求是 “希望是去掉上次所有的post信息 但是保留get所有的信息 适当抛弃锚点” 你做到了~~
我的方案是 “希望是去掉上次所有的post信息 但是保留get所有的信息 也不抛弃锚点”
赫赫
@HarborHouse咱们一起改
韦恩卑鄙 2008-11-20 13:41
页面产生可能是一个post的结果 也可能是一个get的结果 也可能是get和post混合的结果
你的希望是去掉上次所有的post信息 但是保留get所有的信息?
这个需求有点怪:D 如果我设计站的架构 是会尽力回避这样的流程出现的。你确实做到了 但是万一本页面真的需要传递锚点信息的话 你会把锚点信息删除
所以我建议直接增加一个无意义参数比较好
比如说
a.aspx?id=1#a
替换成
a.aspx?id=1×tmp=yyyymmddrandom#a
这样保证前面get 的url的get参数有所变化 location.href修改后 浏览器也会强制刷新 后面的锚点也不会丢失
希望能对你有所帮助
韦恩卑鄙 2008-11-20 13:32
--引用--------------------------------------------------
我太有才了: #4楼 非主流程序员 和 #5楼 摄狼
四楼所说的不无道理
但是这个组件的确能实现局部刷新的问题
言之鸡肋,确有此感
但是五楼狼先生言词似乎听得莫明其妙
--------------------------------------------------------
把grid或者repeater放到update pannel的的确确是浪费哦
但是数据又不是必须用这个传递。。。
韦恩卑鄙 2008-11-20 13:29
随便乱说一句 没有发送cookie就没办法保存session 不太适合做些高级访问
韦恩卑鄙 2008-11-20 12:52
“2B”or not “2B”。
是个问题
韦恩卑鄙 2008-11-20 12:46
其实9x年的时候 windows是叫做 视窗3.1 视窗95的
office也叫做微软办公室套装 4.2
到97就淘汰了 为什么淘汰? 因为大家都接受窗体这个概念了。现在建立一个form也有叫做建立一个窗体 为什么不直接说建立一个表单? 窗体、表单傻傻弄不清楚,所以开发的时候都直接说建立一个 winform 或者一个webform
当这些成为习惯 新的名词也就自然根据这样的默认规则 统一术语化了
所以说 这些避免潜在问题的习惯 都是装x?
韦恩卑鄙 2008-11-20 12:34
--引用--------------------------------------------------
狼Robot: @韦恩卑鄙
你提到了一个:等我做专业的时候,你的意思是等我做专业了我就得全讲英文了,要不然就显得我不专业?
专不专业跟语言有冲突么?
--------------------------------------------------------
你看 愤怒了 愤怒让你曲解了我的意思
我的意思说得很清楚了 请对你的父母用“动态图像压缩专家组音频第三层协议”代替"mp3" 做做看。
实际上这是一种信息不均衡的冲突
你觉得demo很好翻译 看到这个我笑了
我们知道demo是什么 但是demo有多少种中文翻译? demo可以翻译成 例子 事例 实例 演示
翻译成实例 你还不和instance弄混了? 你有把握说你翻译的demo的中文翻译在任何方言中都没有歧义?
就好像 troll 这个怪物 在大陆被翻译成巨魔 在台湾叫做食人妖 而台湾的巨魔是Oger 在大陆叫做食人魔 一群大陆wow玩家在一起可以说我是个巨魔
可是你到了美国服务器呢? 台湾服务器呢? 最简单的方法就是用troll这个名词。
鲁迅先生说翻译注意信达雅 但是如果不能做到雅 也要保证达 就算不能达 宁可硬译来保证至高无上的信。 硬译就是要么用引号表明是专门词语的发音 无法翻译 要么干脆把原词原文拿出来直接给读者看。这就是“费厄颇赖”的由来,公平竞争真的能完全表达他的意思么?研究过当时文化政治的人没有人敢说是
还是那个例子 当你父母问你你在听什么的时候 你回答的是“动态图像压缩专家组音频第三层协议文件” 还是mp3? 当然是mp3 你没有必要为了他们翻译成中文 他们也没必要因为不认识这些字母感到儿子在装文化人
就这个道理
韦恩卑鄙 2008-11-20 12:14
其实如果叶面真的有锚点应用了 你这样又变得不合适了
我记得有location.reload 方法的 能给我讲讲为什么要用
window.location.href = window.location.href么 三年多没做web ui了 已经忘记差不多了 还请共享下~~~
韦恩卑鄙 2008-11-20 11:26
--引用--------------------------------------------------
玉开: @韦恩卑鄙
似乎它还是实现不了动态配置角色可执行操作这个事情?
--------------------------------------------------------
恩 m$也是建议你在page load时候读取 当前用户 roles 对应的权限列表
这个列表的动态更新和实现是要自己做的
我是想说M$留了接口 不是完全没有考虑
韦恩卑鄙 2008-11-20 11:16
我真想知道 那些觉得“要在做Website之前,我们必须先New一个Web site”
是在装13的人 去敬老院讲讲怎么上网听歌会是什么状况
等到老爷爷老奶奶说你播放"mp3"是装13 必须用 “动态图像压缩专家组音频第三层协议”来和他们说话,不然你就是汉奸国贼的时候 你就知道自己错了
韦恩卑鄙 2008-11-20 11:13
--引用--------------------------------------------------
狼Robot: 那都是高手用的词汇,我这些小菜就只有晕得不知道东南西北了.
一/二/三,我觉得完全是可以用中文表达的,但高手们为了显示专业,所以就中西结合了,至于四嘛,还真有点不好翻译.
--------------------------------------------------------
为了显示专业 呵呵
对方只是懒得在做一次翻译 把你当成有相当水平 能够听懂的听众了
你愤怒是因为你还没有具备应有的前提基础 其实让你生气的不是对方 而是听不懂这件事吧
等你做了专业人的时候 你就知道翻译成老妪能解的普通话多困难了
韦恩卑鄙 2008-11-20 11:10
发现没有 那些酸酸的声音都用未注册用户排队哦
韦恩卑鄙 2008-11-20 11:08
语言中的特任定概念词语 是用抽象的词代表具体
换程序里面就是宏或者自定义的运算符
在双方都懂得的情况下 越简单越通用的概念词语越有效
尤其在对方也可能与英语接触的时候 特定概念用英文 可以防止第三方翻译的误解。
当你每天面对 30%的大陆人 30%的台湾人 30%的香港人 和10%的印度人的工作环境的时候 一件东西光中文就有三个表达方法 ,还有自己不懂得印度文
不用英文词就是逼自己精神分裂了。
当然惯性会让你撒不住车,伤害到一些周围的人 再用假洋鬼子攻击你。
韦恩卑鄙 2008-11-20 10:57
--引用--------------------------------------------------
Zmy_david: @游人
@横刀天笑
看到的仅仅是我说得一些比较简单的,当然不是难的。我也说了,我英语非常差,但是这些还是懂,可是有很多时面讲得很不靠边的就晕了。
--------------------------------------------------------
偏偏你举的4个例子 真没什么不靠边的
刚刚我说了 1 3没什么不对
我再说说2 4
2 一个有经验的新人进公司 两三个需要人的项目 当然要一起来选秀 两三个经理有什么问题?
3 都说了是在做网页, DW难道是做史瑞克的梦工厂?
韦恩卑鄙 2008-11-20 10:48
其实 lz 你不要台吹毛求疵了 比如
要在做Website之前,我们必须先New一个Web site
不是英语语法 而是程序语法
website =new wibsite
就算是美国的程序员有时候也会这样说话 所以才被人说成nerd
比如
一篇讲asp.net的文章这样写,“在我们test这个Dome之前,我们首先要config一下,然后才能
before we test this demo,we need a configuration.then we can....
反倒是挺local的英语语法
韦恩卑鄙 2008-11-20 09:40
其实web.config的配置和m$的membership roles 是关系紧密地
本来就不是让你孤立地用 web.config阿 要配合程序的 roles
韦恩卑鄙 2008-11-20 09:15
恩 最近我在地铁上不看时代报和环球了 就看你这本
韦恩卑鄙 2008-11-19 15:56
@Ray Wu
大多数都是要跟双方的transid的
悲观锁太狠了
韦恩卑鄙 2008-11-19 14:23
--引用--------------------------------------------------
kkun: 试了下VS2008和SQL2005,不能实现你说的那个效果
--------------------------------------------------------
因为Sql2008的 management studio是 vs2008 ide
sql2k 用的是mmc 不可能和任何ide发生亲缘关系
韦恩卑鄙 2008-11-19 14:11
-----------
另外,那个报表,和购物车没有关系,购物车里的数据又不会体现在报表内,所以这个表存在与否、是大是小,对其他功能完全没影响,其他的东西该怎么还怎么办呗,这个东西只用来做数据挖掘,放弃数据挖掘是绝无可能的,除非公司不想发展了,你可以去问问各大电商网站,哪个敢不做这个?
------------
多说多错,你这段话我只能理解为 你只知道要做数据挖掘 但是不知道挖掘出来的信息是什么
不管你购物车信息作了多少优化调整 分表 定时 一份购物车用户行为log 带来的信息都是你说的购物车信息的超集
那么就分析log 何苦要分析别的
分析用log和业务数据分开 减少的是各方面的成本 提高的是框架的清晰
有更好的实现方法 你回一句“哪个敢不做这个?” 就错了。能用高炉谁还用土法炼钢?
不是说凡是数据就要挖掘 你还是仔细看看36楼我给chinaagan 的回复吧
韦恩卑鄙 2008-11-19 13:43
确实是一个道理
“SQL2005的修改表界面” 就是标准的vs2k5 IDE
韦恩卑鄙 2008-11-18 22:30
实际上 任何可能的刷新 都需要GridView.DataBind() 包括pageindex seslectitem的变化
韦恩卑鄙 2008-11-18 20:31
另外
4)至于说的数据大数据量,我想可以通过定期对数据库进行操作来解决。
我对表结构的一些想法
订单表(基本信息加订单号)
详细订单表(订单好,详细订单号,产品信息)
成功订单表(复制订单表的字段)
所以我比较同意丁大哥的建议 :)
这是你把数据仓库和数据挖掘理解歪了
分表是尤其要不得的 会把你真正作数据仓库的下家的鼻子气歪
韦恩卑鄙 2008-11-18 20:23
@chinaagan
你还是没仔细看我写的表和流程的
你说的数据挖掘按照我写的cookie流程是完全可以实现的
而按照丁兄的“业务数据”挖掘 只能对当前状态进行挖掘 而不能对购物车的操作明细进行挖掘
比如 一个用户A 姑且算他是没有注册的用户
他买了10个甲商品 后来觉得多了 取消了两个
那么按照丁兄现状态挖掘的机制 只能有 “用户A 8个 甲商品”
而按照我的cookie记录列表 数据仓库记录log的方式 就可以记录
“用户A yyyy mm dd 增加10个 甲商品”
“用户A yyyy mm dd 减少2个 甲商品”
这种log的追溯 对跟踪用户行为远远比对现在购物车的即时状态进行挖掘有意义得多
通过ilog你可以模拟出任意一个瞬间的状态 但是对当前购物车状态的分析只是一张照片 其意义极其有限。 看股票都看走势 谁看2008年11月20日8点各个股票瞬时价格阿?没对比和趋势,我是不敢买股票的。
这里要提一下 @无名的小卒
你就是一个把购物车数据库信息和购物车历史信息混为一谈的典型
回头继续对@chinaagan说
你可能说“丁大哥的方法也可以把明细都写在若干行里 然后计算总量阿”
我估计不用我 你丁大哥就该打你屁股了。其实维护已经注册用户的购物车已经有很多性能上的消耗了,当你这个表大到500w行 每次对每个用户当前购物车的按照itemid 进行的group sum 要花数十秒 但到整个站只跑一个购物车?
定期删除数据? 那可就没办法挖掘了? 持久性? 一个月500w行很难?那不就没办法保存超过一个月了?分表?超过一个月的购物单要去历史表查?还要把大小表两边查询的结果拼起来!我的妈呀,咱不是华为人 不需要这么累吧?
————————————————————————————
另外关于"跨地点购车" 这个是要对已经注册负责的。这个功能对非注册用户并没有足够的开通理由,不开通反而会增加用户注册转换率。
再次重申 我不反对做数据库的购物车 但是
1 用购物车业务数据直接作挖掘是纯粹的扯淡 行为Log数据对分析才是有意义的 “我保留全部的用户的购物车就是为了数据挖掘”完全说不通。
2 对非注册的用户购物车做到和注册用户一样绝对负责就是对自己系统的不负责
包括性能问题和安全问题 “姑且不管性能问题和恶意攻击”这样的论调可以去写资本论 但是社会主义初级阶段就是tnnd不缺坏人
3 业务数据按照特定时间分表
让“正在运行的业务”的性能给“数据分析服务”的性能买单
(小表分析时必须分析当前业务数据 造成性能损失)
让 “注册用户的数据的持久性 给“未注册用户的非购买意愿的垃圾信息买单”
(无意义的数据太多导致有意义的本该有效的已注册用户信息被迫转移到分析大表 导致信息失去有效性和持久性)
让“数据仓库编写成本”为“数据库设计缺陷”买单
(小草人 我钉~~~)
4 cookie有它的用处 符合分布式的原则,化整为零遍地开花。把cookie讲得一无是处其实是和自己过不去
以上
韦恩卑鄙 2008-11-18 19:59
@丁学
大家要是都没有急就好办了
我的原则就是业务数据尽量和挖掘数据分开
如果用"可变状态"的业务数据做挖掘
那么一个购物车改变状态的时候.
因为性能而清理非活跃用户数据的时候
往往就是挖掘数据失真和丢失的时候
你若能理解业务数据尽量和挖掘数据分开的这些理由 咱们就没什么分歧了
但是你还是自己给自己绕进去了
持久性的数据,未必就得一直放在这个大表里啊,这样的话,跑上两年服务器指定死掉,就好像,你会把所有的备份文件都放到业务数据库服务器吗?一样的道理,这些数据要定期进入数据分析部门的单独服务器,然后会在这些单独的服务器上“永久性”的存在(数据分析部门的服务器一般都是超大硬盘,就是做这个用的哦)
首先 你没有给数据分析部门一个好用的大表 而是对以前的数据核最近的数据各要写一份挖掘程序
就算你订的是半年期限好了 现在市十一月 两个表的分界卡在5月 有个商务要看3-8月的全部数据
你的这个数据还要让人家做报表的定期更新 无缝拼接 耍人也没有这么耍的
其次 没注册用户半年以前的购买数据持久 你就不管了?
等等 仔细一看 已经注册的用户半年前的数据你也没管阿。哦 原来你一直说购物车的数据持久就不怎么重要是么?那可真是我年老眼花了
第三 定期处理哪里好 集中性的占用性能 甚至造成功能瘫痪和各种bug。而且每次处理 做报表的大哥又需要重新拼表 好吧 可以无视 但是人家可是做了小草人诅咒你呢
第四 用户退定信息你也要单独占一行? 不占就损失了挖掘数据 占了就损失了select性能
所以还是劝你 早点放弃把业务数据当成挖掘依据的念头 太理想化
你说咱们两个把座仓库写挖掘的兄弟们都累成孙子 咱们也做不了爷爷 找各自的媳妇努力才是正道!:D
综上 我感觉 你说的“定时处理”“分表”完全是对付我说的性能问题现琢磨的 为了反对我而修改的,所以还没有深思熟虑 把这个新想法和你的旧想法的矛盾滤顺 你的原意是什么我一直都没理解错 但是你的想法在讨论中发生了变化
那就更希望你能多理解下我说的原则 为什么“业务数据尽量和挖掘数据分开”会比较好。
韦恩卑鄙 2008-11-18 15:36
总结的很好 感谢博主的努力 鞠躬
韦恩卑鄙 2008-11-18 13:29
12的时候 我也在学basic么。。。 打个洋灰三角形什么的
那时候要是什么开源 什么internet都有 吾可取而代之 亩哈哈哈哈
韦恩卑鄙 2008-11-18 09:59
toggleDiv.style.filter = "alpha(opacity=80)"; // IE
以后也可以用
toggleDiv.style.filter[0].opacity 来修改
韦恩卑鄙 2008-11-17 23:11
好文章 要是早出来两年我就可以省下一个月了
韦恩卑鄙 2008-11-17 22:47
再明确一下我说的"是否注册用户区别处理"的服务器行为
1 未登陆用户点一个商品
cookie保存购物车
服务器记录 IP Cookie临时ID 和行为到数据仓库
2 未登陆用户取消一个商品
cookie保存购物车更改
服务器记录 IP Cookie临时ID 和行为到数据仓库
3 未登陆用户转化为注册用户(登陆或注册)
服务器保存用户cookie到注册用户购物车数据表
服务器更新或添加新的IP Cookie临时ID 和行为到数据仓库
4 已注册用户点选一个商品
数据库保存购物车
服务器记录 IP 用户ID 和行为到数据仓库
4 已注册用户取消一个商品
数据库保存购物车修改
服务器记录 IP 用户ID 和行为到数据仓库
5 已注册用户完成payment
数据库保存购物车状态修改
服务器记录 IP 用户ID 和行为到数据仓库
商务们需要的数据 这些个步骤都能给 稍稍修改而已
我没有保护未注册用户的数据持久
我更没有让未注册的用户为所欲为
最重要的一点 我要遵循我的原则
"我尽量把数据仓库要分析的log数据和业务数据分开"
就是这样
我也是程序员 我也喜欢电子商务 我也按照运营部门的需求做过数据仓库
不要把回你blog的人看得太低了
也不要把“欢迎大家指出不足之外,谢谢!”说成空话阿
韦恩卑鄙 2008-11-17 22:37
呵呵 不要急
我说的这样的所谓大站的变态需求不需要记录全部的购物车行为
只需要最近一个月的就足够了 甚至还可以直接从数据仓库查昨天的结果 所以你记录全部购物车的解决方式仍然是过当而低效的
如果按照你的处理方式 在面对百万数据量的时候就要考虑在"数据持久"和"性能"上2选1了.
至于你给我的帽子"你完全没有理解用户行为分析有什么用"
有些无力哦
我就是很清楚用户行为才给你列出了两个表
我的方案 确实的回避了你可能遇到的"数据持久"和"性能"两难麻烦
能够完成需求的最简单方式就是好方式
请好好思考下 数据挖掘/数据持久和性能三者造成的矛盾吧
cookie 存ID的购物车 远没有过时
韦恩卑鄙 2008-11-17 22:13
我感觉 安装了全套java服务器应用的linux也不怎么高性能 -0-
.net太大了 从图像到声音 累赘太多太多了
韦恩卑鄙 2008-11-17 22:03
好的 我厂随后实验下 多谢!
韦恩卑鄙 2008-11-17 21:48
--引用--------------------------------------------------
neoragex2002: 这叫多音双频,搞通信的基础常识了,没多大用处的。
据说还有人用吹口哨拨号的。柯南这个假。
是高手的用语音频带收发短消息试试(研究生及以上可试试),如图:
输入短消息--->PC+喇叭--->电话<---->电话--->麦+PC--->输出短消息
--------------------------------------------------------
双音频需要和声 所以一定是两个人的口哨
这个道理是我初中1年级在厕所大便玩厕所的分机时候 悟出来的
因为吹口哨吹到缺氧 -0-
韦恩卑鄙 2008-11-17 21:33
别听他们说什么乱七八糟的
现在指定用ie的系统多的是
你会用ie的滤镜 用好了还可以说服用户改用ie呢
参考下更多的滤镜 眩死你不偿命
ms-help://MS.VSCC.v90/MS.MSDNQTR.v90.chs/filters/workshop/author/filter/reference/reference.htm
或者
http://msdn.microsoft.com/zh-cn/library/ms532853(en-us,VS.85).aspx
(刚出ie5.5 beta时候的东西 我毕业设计时候学的 已经是5-6年前了 今天刚刚还在项目用到 知识不在老不老 在用不用阿)
韦恩卑鄙 2008-11-17 10:28
如果按照博主的业务需求 可能需要这样一个购物车表
ID 流水
CookieID 客户Cookie中存放的 Id
ClientIP 客户端IP
ClientIPLocation 客户端IP实际地区
ItemID 物品ID
ItemCount 物品数目
rowExpiredTime 无操作过期时间
UserIDifExist 如果已经注册用户 那么他的ID是
rowStatus 目前行的状态 [等待支付|支付完毕|标记取消]
CreateDatetime 创建时间
ModifyDateTime 修改时间
如果实现了一个“非注册用户”向一个“注册用户”的转变 我们可能要修改
如果用户交易成功了 我们要更改
如果用户换了一个机器上来 他以前的所有的数据可能都白跟踪了 但是这些数据仍然要作为 update select 的where 过滤条件必扫的部分
我认为这样的数据结构是丑陋的 不干净的 而且由于性能问题造成的必须定期清内容 我认为这样的数据是不能持久保存的
还不如完全分离开 cookie记录业务逻辑
以下是一个我个人理想的数据挖掘 注册用户行为log表
一旦插入就不更新
ID 流水
CookieID 客户CookieID
ClientIP 客户端IP
ClientIPLocation 客户端IP实际地区
ActionType 行为类型 添加/取消/交易成功
ActionRelatedItem 行为相关物品
ActionRelatedItemCount 数量
UserIDifExist 如果已经注册用户 那么他的ID是
Timestamp
该跟着cookie走的 就让他们去吧
韦恩卑鄙 2008-11-17 10:11
--引用--------------------------------------------------
丁学: --引用--------------------------------------------------
没名: 我以为还是用Cookie合适些.虽然Cookie有大小的限制.但我觉得不会有哪个网站任你无限制的在购物车里放东西.
放在数据库里如果没有提交订单应该就会产生过多的无用数据及增加数据库的读写....
--------------------------------------------------------
理由见16楼,主要是数据挖掘的需要,这是电子商务生存的根本,相对这些来说,数据库操作开销可以放后面了,数据库可以通过无限优化和增加硬件投入来解决,但如果没有数据可供分析,那很致命
--------------------------------------------------------
你说数据挖掘这方面的需要其实是不大正确的
从非注册用户的购物车纪录入手 不如从商品叶面的pv、定购点击次数和交易完成次数入手更简洁,得到的东西却是一样的。
数据挖掘也比较忌讳把业务读写频繁的数据当成分析内容的吧,应该面对的是只写的log数据而不是正在跑逻辑读写频繁的购物车表。
另外 关于cookie过期的问题 cookie又不是一个月就没有了,服务器可以强行指定cookie过期时间的
反倒是服务器上的“非注册用户”数据过大的时候 更容易被定期清理。
l
韦恩卑鄙 2008-11-17 10:04
还是看网站规模和需求
对于真正的大站 注册和非注册 应该从需求入手区别处理
实际上要不是有“察看此商品的用户还浏览了xxxx”这样变态的需求 谁会轻易做“把非注册用户的需求存到数据库” 这么吃力不讨好的事情。
没有类似需求的 非注册用户cookie的4k绝对足够用了。
韦恩卑鄙 2008-11-17 09:47
2个连接都是黄色屏幕哦
韦恩卑鄙 2008-11-17 09:44
加油加油 还有ie6以上支持的directx filter呢 不要放弃阿