“动态”定价系统
很快我将从事一个项目，该项目本质上是一个用于配置产品的电子商务应用程序。这个问题是关于实现每天都在变化的定价方案的方法，因此我们希望将定价逻辑从代码中取出并放入数据库中，但不是让数据库完成所有工作的方式。
基本思路是这样的，有5个属性。您可以从每个属性中选择一个选项。然后您开始将产品添加到购物车。您添加的所有产品都将附加这 5 个属性（这些属性将影响定价）。添加产品后，您可以对其应用修改（属性也将应用于修改）。
所以，我们现在得到的是一个产品（有固定的基本价格），有一些关于它的信息（这将修改价格），零个或多个修改（有固定的价格）和一些关于它的信息他们（这将修改价格）。修改也可能产生额外费用。例如，如果 A 公司使用此软件，并且他们使用以下方式为其商品定价：BASE_PRICE + $50 * NUM_WHIRLIGIGS，并且该商品进行了添加 WHIRLIGIG 的修改，则必须反映在价格中。
您是否知道我在确定如何设置时可能会发现有用的不同定价系统的任何示例？你有更好的想法吗？
我目前最好的想法如下，如果您对该方法的细节不感兴趣而只想直接得到答案，则可以跳过它！
对于任何给定的项目（或项目集合），公司可以使用特殊的界面来设置定价公式，然后在运行时解释和评估该公式。
因此，对于 PRODUCT_A，公司可能会输入类似 BASE_PRICE + WHIRLIGIG_UPCHARGE * NUM_WHIRLIGIGS 的内容。当需要定价时，软件会查看该物品有多少个旋转，以及通过任何修改增加了多少个旋转。
有人有实施这种解释器的经验吗？结果如何？是不是很困难/麻烦？
预先感谢您提供的所有精彩意见，我一定会得到的。 ：P
Soon I'll be working on a project that amounts to what is essentially an e-commerce app for configured products. This question is about ways to implement pricing schemes that can change from day to day, so we want to get the pricing logic out of code and into a database, but not in a way that causes the database to do all the work.
The basic idea is this, there are 5 attributes. You pick an option from each of those attributes. Then you start adding products to your cart. All the product you add will have those 5 attributes tacked onto them (the attributes will affect the pricing). Once you've added a product, you can apply modifications to it (the attributes will also be applied to the modifications).
So, what we've got at this point is a product (which has a fixed base price) with some information about it (that will modify the price), and zero or more modifications (which has a fixed price) and some information about them (which will modify the price). Modifications can also incur additional charges. For instance, if company A uses this software and they price their items using: BASE_PRICE + $50 * NUM_WHIRLIGIGS and the item has a modification that adds a WHIRLIGIG, that will have to be reflected in the price.
Do you know of any examples of different pricing systems that I might find useful when determining how to set this up? Do you have better ideas?
My current best thought is below, you can skip it if you're not curious about the particulars of the method and just want to get right to the answering!
For any given item (or collection of items) the company could use a special interface to set up pricing formulas which would then be interpreted and evaluated at run-time.
So for PRODUCT_A, the company might put in something like BASE_PRICE + WHIRLIGIG_UPCHARGE * NUM_WHIRLIGIGS. And the software, when it comes time to price it, would look at how many WHIRLIGIGS the item has, as well as how many WHIRLIGIGS are added by any modifications.
Does anyone have experience implementing this kind of interpreter? How did it turn out? Was it difficult/troublesome?
Thanks in advance for all the awesome input I'll sure I'll get. :P
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
通常，这通常是通过包含组件的产品包来处理的。因此，具有 5 个附加子组件的产品不会是 base + 5 * addon，而是 SUM(base, addon, addon, addon, addon, addon)。
因此，您的产品表可能是自引用的，或者存在某种链接表，该表说明允许哪些子产品附加到哪些产品。
根据我的经验，定价通常存储在产品/客户或合同的基础上，所以这是另一个表。
然后，实际订单本身包含产品捆绑包。如果订单是报价，则定价将被冻结（直到报价到期）。
当报价或订单转换为发票时，定价要么被锁定在主要定价或报价中，具体取决于定价时间范例。
Typically, this is usually handled with product bundles which have components. So a product with 5 additional subcomponents would not be base + 5 * addon, but SUM(base, addon, addon, addon, addon, addon).
So your product table may either be self-referential or there is some kind of link table which says which sub-products are allowed to be attached to which products.
In my experience, pricing is usually stored on a product/customer or contract basis, so that's another table.
Then the actual orders themselves contain product bundles. If the order is a quote, then the pricing is frozen (up to the expiration of the quote).
When an quote or order is turned into an invoice, at that time the pricing is either locked in from the main pricing or the quote, depending upon the pricing timing paradigm.