第一次做网站,关于网站构造方面想请教下

WBOY
Libérer: 2016-06-23 14:02:36
original
786 Les gens l'ont consulté


长短不一的字符串(可能为空字符串)保存到数据库里面还是保存成文本文件?
我做的是一个在线购物的网站,每个用户都会有个购物车

购物车(cart)里面保存了他们放进去的物品和物品的配置,

这个购物车(cart)储存的数据结构就是一个array(我保存成了json格式)

但是由于有的用户有放东西有的没有放,所以每个用户的购物车数据长度都不一样

请问购物车的内容(Json数据)我要保存到数据库里还是保持成文件?

如果保存成数据库, 我是放在user.cart里面 还是放到cart.items里面?

1)如果放到cart.items里,系统会等到用户添加物品到Cart里面后,再添加数据到cart,并且把用户的user.cart_id赋值为cart.id

当用户吧cart.item清空,则user.cart_id=0,并且删除对应的cartrow

2)如果保存到user.cart里面,每个user都会分配个很长的cart用来做存储,不知道会不会浪费资源?(我不清楚数据库的保存格式..)

3)如果保存成文件,我会在每个用户注册成功后生成一个$userid.json,放到一个私有文件夹里面,只有服务器可以访问,里面的内容可能是空.


回复讨论(解决方案)

一般网站的购物车,是通过保存session或者cookie的。
因为这样性能稍微好一点。

一般网站的购物车,是通过保存session或者cookie的。
因为这样性能稍微好一点。

要求注册的用户需要能够访问上次登录时的购物车..

没有注册的用户是写到session里面的

1、将 session 从默认的文件方式改换成数据库方式
2、直接操纵 $_SESSION,无需 json
3、为满足“注册的用户需要能够访问上次登录时的购物车”可在 session 表中增加一个用户名(用户id)字段,并适当调整 session 回调函数

于是:
如果考虑用数据库保存未结账信息,则 session 表已经做了。不必再做
如果考虑用文件保存未结账信息,则因为访问量巨大,多层目录文件管理困难;单层太慢。非万不得已,不与采纳

1、将 session 从默认的文件方式改换成数据库方式
2、直接操纵 $_SESSION,无需 json
3、为满足“注册的用户需要能够访问上次登录时的购物车”可在 session 表中增加一个用户名(用户id)字段,并适当调整 session 回调函数

于是:
如果考虑用数据库保存未结账信息,则 session 表已经做了。不必再做
如果考虑用文件保存未……
感觉这样的方法很麻烦啊
如果用session的话,用户A登录网站并且保存了物品到session1
之后用户A换了浏览器,登录网站,新建了session2,但是session2里面没有session1里的内容
是不是需要在user表里面价格sessionid?每次登录需要重新设置sessionN到session1?
如果这样的话session是要设置成永远不过期的.
如果有人获得了用户的帐号密码,就知道了他的session,如果改密码是不是也需要重置session啊..这样就更麻烦了
因为注册用户的cart信息不能丢失所以session不能过期
但是匿名访客的session就需要在一定时间后清除,这个怎么做判断啊..



Json是想和ajax一起做动态购物车的..

做一个小型的网站一共就7到8个页面.

就是想了解下,遇到了这问题的常规解决方案是什么额

感觉session不适合保存注册用户的信息..

这样很不安全啊

不要为了程序而写程序,那是为了提高自身水平才做的事

做实际工作时,没有搞清业务流程就考虑技术流程是错误的
我只说说你想法中的几点错误
1.没搞清为什么要保留购物车数据,只是为了保留而保留
其实大部分人已经接受了重新登录/掉线购物车清空的事实,因为这点而投诉的客户几乎没有

2.“如果有人获得了用户的帐号密码……”,帐号密码远比购物车数据重要得多,本末倒置了
如果我丢失了账户密码,我不担心别人看到购物车里面放的是避孕套还是笔墨纸砚,而是担心别人看到我的送货地址和收货人资料

3.问题必须都在程序解决
应该在业务逻辑解决的事情,却由技术逻辑扛下来,是绝对的不会做生意(做事)的表现

购物车数据属于临时数据,完成一次购物(重新选择也算完成),数据就没用了??或者说转换为订单数据
现在最大的区别只是时间,就是这个“完成过程”所耗费的时间和多次浏览的问题,顺便问一下,购物车里面的数据放几个月还有用么?
有些时候在技术有限的情况不应把问题想得复杂化,能做才做,不能做就如实反馈给业务逻辑层解决


非要转牛角尖的话,我再给你出一个业务逻辑方面的难题:
我和我的家人(可能不少于3人)共用一个购物帐号密码, 同时在多点登录,购物并发货到不同地点或相同地点(订单不同),技术层面怎么解决?说明:拒绝二次登录属于业务层面逻辑而不是技术层面逻辑,我的意思是允许多点登录怎么做?

还是花点时间做好需求分析吧,和业务部门沟通最重要

不要为了程序而写程序,那是为了提高自身水平才做的事

做实际工作时,没有搞清业务流程就考虑技术流程是错误的
我只说说你想法中的几点错误
1.没搞清为什么要保留购物车数据,只是为了保留而保留
其实大部分人已经接受了重新登录/掉线购物车清空的事实,因为这点而投诉的客户几乎没有

2.“如果有人获得了用户的帐号密码……”,帐号密码远比购物车数据重要得多,本末倒置了……

再添加一个物品进购物车前,用户需要选择物品的配置,如果他中途花时间考虑,session过期
他就需要重新添加物品进购物车,这时候他发现购物车里的东西没了,他是否会去考虑去另外一家网店?

第二点你没理解清楚,我的意思是:
在需要将购物车(session)永久保存的情况下,如果某人在公共地方登录没有登出,其他人拿到session就可以永久登录了,即使改变了密码也没有用,有了用户的权限,获得的信息就多了去了。。

还有你给的问题太离谱了。。不是说技术层面能解决的就必须用技术解决啊
一个帐号就是为了给一个人提供服务,
要是给多人用的话,要帐号还有什么意义。。

1.给客户 保存购物车的选择,这时才使用数据库??很多网站都这样做了,是你没去了解学习同行的做法,客户没保存要重选就自己负责,保持连续浏览session/cookies是还在的,他挂十几个小时没操作cookies时效还在就行。我常用firefox,挑了商品换ie上网银,或者隔天再买,中间就用保存购物车的操作
2.客户不认真对待自己的隐私是他的问题,我最鄙视网购不撕掉订单随便就把包裹扔掉的人,网站给出必要的警示和用户协议就足够了。另外你似乎对cookies了解还不够,一般数据完全可以和登录信息分离,登录后重新拼接加载一般信息就行了
3.我给你的难题实际上目的不是要你用技术解决(其实也可以解决,自己有空时再想想),而是 提醒你有很多会实际发生的情况,你不能100%从技术层面解决,就算你解决了这个(帐号共用是常有的事,俺家就这样,老妈不懂注册,用我的帐号下单然后我去给钱的),还有更多难题我可以提给你;所以必须从业务层面去规范一些流程,让事情简单化。去跟业务部商量吧,平衡客户体验也不至于总被问题牵着走才是解决问题的方法

引用 7 楼 snmr_com 的回复:不要为了程序而写程序,那是为了提高自身水平才做的事

做实际工作时,没有搞清业务流程就考虑技术流程是错误的
我只说说你想法中的几点错误
1.没搞清为什么要保留购物车数据,只是为了保留而保留
其实大部分人已经接受了重新登录/掉线购物车清空的事实,因为这点而投诉的客户几乎没有

2.“如果有人获得了用户的帐号密码……”,帐……

让楼上几位一说的确是感觉我有点钻牛角尖。。
之前一直在写c程序,不喜欢浪费内存。。学校第一次让我们做这项目,php也刚学不到一星期。。

因为我不清楚数据库储存原理。

所以就是想请教下如果把购物车信息放到数据库,每个信息给一定的长度,每个用户都会有购物车信息(但是有的长有的短)
这样会不会浪费空间?

储存到文件里的话是肯定不会浪费空间的,但是用vchar来储存会不会浪费空间?

说了半天原来只是做作业 

数据库耗费那是另一个问题

存储空间不重要,又不是全部用SSD,但信息量/流量却重要

对BS系统来说,单个问题的耗费是小儿科,但BS考虑的就是成千上万个 并发连接耗费,所以最重要是做到 必要时才做更重要,就是客户不看商品的时候,只需加载商品名称让他知道是什么就够了,等他要看商品的具体信息才去读取数据库该商品的信息

数据库方面知识等其他大神指导,我的弱项

恩..工业项目课..老师随便找了几个客户,然后吧客户的项目给我们做..

但是做的还是一个真正的网站,做好之后要用的

还要包括documentation, 用户手册, 演讲等等等..

没有薪水..我们还要交钱..客户也要交钱..OTZ

好多大牛。

我也要做类似的网站。

mark了以后看。

还在学习《PHP和MySQL Web开发》这本书,看了一半了。

source:php.cn
Déclaration de ce site Web
Le contenu de cet article est volontairement contribué par les internautes et les droits d'auteur appartiennent à l'auteur original. Ce site n'assume aucune responsabilité légale correspondante. Si vous trouvez un contenu suspecté de plagiat ou de contrefaçon, veuillez contacter admin@php.cn
Tutoriels populaires
Plus>
Derniers téléchargements
Plus>
effets Web
Code source du site Web
Matériel du site Web
Modèle frontal