基于CodeIgniter的电子商店,运输和礼品地址设计问题
在构建电子商务平台时,我遇到了设计问题。我正在使用内置的 CodeIgniter 的购物车类。它将所有购物车信息存储在会话中。假设购物车已装满产品并且用户点击结账。我什么时候应该将订单存储在数据库中?是在单击之后还是在收集信息并将其存储到会话中的几个步骤之后?如何处理不同运输方式等附加功能?我应该先将其添加到购物篮并获得额外的(礼物地址)来参加会议吗?我不想将其存储在数据库中,因为需要礼品地址和订单之间的关系,而且我不知道订单的 ID 是什么。我很困惑:)此外,我认为让购物车了解运输方式和额外购买的服务至关重要(通过选择礼品地址需要支付额外费用),因为购物车内容就像收据一样?
简而言之,处理结帐的最佳实践是什么?
While building an ecommerce platform I have run into design problems. I'm working with the built-in CodeIgniter's cart class. It stores all the cart information in session. Let say that cart has already been filled with products and user clicks checkout. When should I store order in database? Just after that click or after several steps of gathering information and stoing it in session? How to deal with additional features like different shipping methods? Should I add it to the basket first and get additional (gift address) to session? I dont want to store it in database because of the relation between gift address and order is needed and since I dont know what's the ID of the order. I'm puzzled :) Additionally I think its crucial to keep cart aware of shipping methods and additional bought services (by selecting gift address there is an extra fee) because the cart content is just like an reciept?
In brief, what is the best practice to process checkout?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
您可以使用 "options" 值向购物车商品添加其他属性(例如送货选项)购物车。
请记住,您不需要数据库中的增量 ID;您可以使用 uniqid() 或 com_create_guid()。
既然您正在征求意见...您应该将不同的送货地址存储在与用户相关的单独地址簿表中,而不是加入到订单中。当您最终创建订单作为结账的一部分时,您应该将所有数据(地址数据和相关产品数据)复制到单独的订单表中,因为产品数据和地址簿数据可能会发生变化;除了状态之外,订单数据应该写入一次并且永远不会更新。保存订单后,您可以删除会话数据。
You can add additional attributes to your cart item (like shipping options) by using the "options" value of the cart.
Bear in mind you don't need incremental IDs from the database; you can create unique IDs with uniqid() or com_create_guid().
Since you are asking for an opinion... You should store different shipping addresses in a separate address book table related to the user, not joined to the order. When you finally create an order as part of the checkout, you should copy all of the data (address data and relevant product data) to separate order tables because the product data and address book data can change; order data should be written once and never updated, aside from status. Once the order is saved you can delete the session data.