我销售潜在客户并向我的客户收费如下:
(只能从客户收取以下一种付款方式)
按线头付费:
$ __为每月的第一个__潜在客户
$ __表示每月__个潜在客户数量
$ __表示每月__个潜在客户数量
等等...
按预约支付:
$ __为每月的第一个__潜在客户
$ __表示每月__个潜在客户数量
$ __表示每月__个潜在客户数量
等等...
按销售百分比付款:
__%的销售价格(每次销售)
我的问题:
在这种情况下,最好的数据库设计解决方案是什么?
我尝试了什么:
+---------+
| clients |
+---------+
| id |
| name |
+---------+
+---------------+
| deals |
+---------------+
| client_id |
| max_quantity |
| cost |
| unit_type |
+---------------+
因此,id
1的客户端的记录可能如下所示:
+-----------+--------------+---------------+-------------+
| client_id | max_quantity | cost_per_unit | unit_type |
+-----------+--------------+---------------+-------------+
| 1 | 10 | 10 | lead |
| 1 | 30 | 5 | lead |
| 1 | 100 | 2 | lead |
| 1 | 10 | 35 | appointment |
| 1 | 30 | 20 | appointment |
| 1 | 100 | 10 | appointment |
| 1 | 1000 | 5 | appointment |
| 1 | 0 | 50 | sale |
+-----------+--------------+---------------+-------------+
现在上表意味着:
我们将按$10
收费lead
收费10
我们将按$5
收费lead
收费30
我们将按$2
最高lead
个潜在客户
100
费用
$35
将按appointment
最高10
条收费
我们将按$20
收费appointment
收费30
我们将按$10
收费appointment
收费100
我们将按$5
最高appointment
个潜在客户
1000
费用
$50
将按sale
此外,我想添加x
个此类规则(每个线索,每次预约,每次促销)
我个人认为我的方法不是最好的解决方案之一。期待听到切肉刀的人们!谢谢。
P.S。我知道unit_type可以进一步规范化,但这不是问题:)
也许我可以存储序列化数据?
答案 0 :(得分:4)
您提出的架构是一个良好的开端并具有一些优点。 IMO不太优雅的部分是unit_type
值的非规范化重复和max_quantity
的非功能性sale
值。
建议将deals
拆分为三个表而不是一个。个人会使用单数而不是复数表名**并以相同的前缀开头,因此它们彼此靠近列出:commission_lead
,commission_appointment
和commission_sale
。
** [关于这个问题的很多辩论here]
还建议在每行中包括低频段和高频段。这确实使用了比严格需要的数据更多的数据,但认为值得做,因为它应该使表数据更具可读性并简化计算查询。
所以建议的新架构是:
+---------+
| client |
+---------+
| id |
| name |
+---------+
+-----------------+
| commission_lead |
+-----------------+
| client_id |
| min_quantity |
| max_quantity |
| cost_per_unit |
+-----------------+
+------------------------+
| commission_appointment |
+------------------------+
| client_id |
| min_quantity |
| max_quantity |
| cost_per_unit |
+------------------------+
+-----------------+
| commission_sale |
+-----------------+
| client_id |
| cost_per_unit |
+-----------------+
client_id = 1
的记录是:
commission_lead
+-----------+--------------+--------------+---------------+
| client_id | min_quantity | max_quantity | cost_per_unit |
+-----------+--------------+--------------+---------------+
| 1 | 0 | 10 | 10 |
| 1 | 11 | 30 | 5 |
| 1 | 31 | 100 | 2 |
+-----------+--------------+--------------+---------------+
commission_appointment
+-----------+--------------+--------------+---------------+
| client_id | min_quantity | max_quantity | cost_per_unit |
+-----------+--------------+--------------+---------------+
| 1 | 0 | 10 | 35 |
| 1 | 11 | 30 | 20 |
| 1 | 31 | 100 | 10 |
| 1 | 101 | 1000 | 5 |
+-----------+--------------+--------------+---------------+
commission_sale
+-----------+---------------+
| client_id | cost_per_unit |
+-----------+---------------+
| 1 | 50 |
+-----------+---------------+
答案 1 :(得分:2)
我假设变化非常罕见(更新/插入),大多数时候你使用select来计算成本,所以我建议这个设计,选择计算成本非常简单
+-----------+--------------+---------------+---------------+--------------+------------+
| client_id | max_quantity | min_quantity | cost_per_unit | default_cost | unit_type |
+-----------+--------------+---------------+---------------+--------------+------------+
| 1 | 10 | 0 | 10 | 0 | lead|
| 1 | 40 | 10 | 5 | 100 | lead|
| 1 | 140 | 40 | 2 | 250 | lead|
| 1 | 10 | 0 | 35 | 0 | appointment|
| 1 | 40 | 10 | 20 | 350 | appointment|
| 1 | 140 | 40 | 10 | 950 | appointment|
| 1 | 1140 | 140 | 5 | 1950 | appointment|
| 1 | 0 | 0 | 50 | 0 | sale|
+-----------+--------------+---------------+---------------+--------------+------------+
选择查询看起来像
select
default_cost + ($quantity - min_quantity) * cost_per_unit
from
table
where
unit_type = $unit_type
and (max_quantity >= $quantity or max_quantity = 0)
and $quantity >= min_quantity
答案 2 :(得分:1)
如果您考虑将来可能会更改的成本计算业务逻辑并且您不需要根据计算常量对表进行过滤/排序,我建议为rule_id使用一列,这与您的unit_type非常相似,以及一个名为properties的varchar列,其中该规则所需的所有特定值都使用分隔符存储。
然后,您可以检索适用于您的客户的业务逻辑规则并在那里进行计算。如果需要突然接受5个参数的新规则,则无需更改数据库架构。只需在业务逻辑中为新的rule_id编写代码,就可以了。
当然,如果您希望将计算逻辑移动到存储过程中和/或需要按规则属性进行过滤或排序,我认为您应该为每个规则参数使用单独的列...