Heim > Backend-Entwicklung > PHP-Tutorial > 第一次做网站,关于网站构造方面想请教下

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

WBOY
Freigeben: 2016-06-23 14:02:36
Original
790 Leute haben es durchsucht


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

购物车(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开发》这本书,看了一半了。

Quelle:php.cn
Erklärung dieser Website
Der Inhalt dieses Artikels wird freiwillig von Internetnutzern beigesteuert und das Urheberrecht liegt beim ursprünglichen Autor. Diese Website übernimmt keine entsprechende rechtliche Verantwortung. Wenn Sie Inhalte finden, bei denen der Verdacht eines Plagiats oder einer Rechtsverletzung besteht, wenden Sie sich bitte an admin@php.cn
Beliebte Tutorials
Mehr>
Neueste Downloads
Mehr>
Web-Effekte
Quellcode der Website
Website-Materialien
Frontend-Vorlage