每 5 分钟跟踪一次特定商品价格的算法
Algorithm to track the price of a particular item every 5 minutes
我有一个 PHP 脚本,可以从 API 中获取特定商品的价格。该脚本由每 5 分钟运行一次的 cron 作业执行。商品的价格大部分时间保持不变,一天只变动 4 或 5 次左右。
这就是我现在 table 的结构:
CREATE TABLE IF NOT EXISTS `product_details` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`start` datetime NOT NULL,
`end` datetime NOT NULL,
`price` decimal(11,2) NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1 AUTO_INCREMENT=38 ;
在前端,我想显示各个时期的价格。那么如果价格在一天内变化了3次,就会有3个时间段,对应的价格。
示例:
2015-05-31 01:55:00 PM to 2015-05-31 04:25:00 PM
Price = .33
2015-05-31 04:25:00 PM to 2015-05-31 08:25:00 PM
Price = .54
2015-05-31 08:25:00 PM to 2015-05-31 10:25:00 PM
Price = .37
如果我每次执行脚本时都插入一条新记录,那么一天就会有 200 多条记录,而且很快就会变得混乱。因此,仅当获取的价格与前一个价格不同时,我才执行 INSERT 查询。
我的脚本现在是这样的:
$last_row = get_last_low();
$current_price = get_current_price();
if ($last_row['price'] == $current_price)
{
UPDATE product_details SET `end`=%s ORDER BY id DESC LIMIT 1;
}
else
{
INSERT INTO product_details (`start`, `end`, `price`)
VALUES (NOW(), NOW(), $current_price)
}
foreach (get_all_records() as $item)
{
display();
}
如果用户指定,我想在每个条目旁边显示 increase/decrease 的价格。我是否应该在 table 中添加另一个 value_increased
字段?我完全不知道如何以最好的方式正确构建 table,所以我以后不必回头看。
你会如何改变它? (我刚刚发布了我的方法来展示我到目前为止的尝试;你的答案不一定要坚持下去。我对任何想法都持开放态度,只要它比我的 hack 更好。)
由于您在执行 INSERT 时已经有了之前的价格和新的价格,因此您可以轻松计算 value_increased 并将其存储起来。所以基本上是的,在 table.
中添加另一个 value_increased 字段
不是每次查询 API 时都更新 'end',如果您在代码中跟踪上次 运行 时间,您可以在查询前更新一次INSERT(在初始 INSERT 上将其设置为 NULL)。
类似
$last_row = get_last_low();
$current_price = get_current_price();
if ($last_row['price'] != $current_price)
{
UPDATE product_details SET `end`=%s WHERE 'end' IS NULL;
INSERT INTO product_details (`start`, `end`, `price`)
VALUES (NOW(), null, $current_price)
}
此外,如果您显示所有商品的当前价格,您的查询会变得更加简单 - 类似于
SELECT * FROM product_details WHERE 'end' IS NULL;
而不是更复杂的东西(有多个产品,你必须获得最新的 'end' 然后重新加入才能获得相应的价格。当然,如果你是唯一的人在做正在显示所有记录,这不会是一个太大的因素。
单次更新意味着您访问数据库的次数要少得多(即价格变化的次数,而不是点击 API 的次数)
缺点
缺点是如果您的应用程序崩溃,您将不知道上次获得价格的时间(如果必须跟踪每个价格,您基本上必须在 API 在你最后一次 PRICE 更改后的所有时间。例如
1.00 PM .1
1.15 PM .0
1.30 PM .0
1.45 PM .0
--- application crash ----
使用您当前的程序,您的数据库将具有
1.00 PM .1
1.45 PM .0
因此,对于错误恢复,您基本上会查询 API 以了解下午 1 点 45 分之后的所有价格变化。使用修改后的程序,您的数据库将具有
1.00 PM .1
NULL .0
因此,对于错误恢复,您必须查询 API 以了解下午 1 点后的所有价格变化。请注意,在这两种情况下,API 返回的记录数是相同的,只是 API 的 re运行 有轻微的变化(取决于最后一次价格变化的时间)是)要过滤掉的更大数据集。
我有一个 PHP 脚本,可以从 API 中获取特定商品的价格。该脚本由每 5 分钟运行一次的 cron 作业执行。商品的价格大部分时间保持不变,一天只变动 4 或 5 次左右。
这就是我现在 table 的结构:
CREATE TABLE IF NOT EXISTS `product_details` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`start` datetime NOT NULL,
`end` datetime NOT NULL,
`price` decimal(11,2) NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1 AUTO_INCREMENT=38 ;
在前端,我想显示各个时期的价格。那么如果价格在一天内变化了3次,就会有3个时间段,对应的价格。
示例:
2015-05-31 01:55:00 PM to 2015-05-31 04:25:00 PM
Price = .33
2015-05-31 04:25:00 PM to 2015-05-31 08:25:00 PM
Price = .54
2015-05-31 08:25:00 PM to 2015-05-31 10:25:00 PM
Price = .37
如果我每次执行脚本时都插入一条新记录,那么一天就会有 200 多条记录,而且很快就会变得混乱。因此,仅当获取的价格与前一个价格不同时,我才执行 INSERT 查询。
我的脚本现在是这样的:
$last_row = get_last_low();
$current_price = get_current_price();
if ($last_row['price'] == $current_price)
{
UPDATE product_details SET `end`=%s ORDER BY id DESC LIMIT 1;
}
else
{
INSERT INTO product_details (`start`, `end`, `price`)
VALUES (NOW(), NOW(), $current_price)
}
foreach (get_all_records() as $item)
{
display();
}
如果用户指定,我想在每个条目旁边显示 increase/decrease 的价格。我是否应该在 table 中添加另一个 value_increased
字段?我完全不知道如何以最好的方式正确构建 table,所以我以后不必回头看。
你会如何改变它? (我刚刚发布了我的方法来展示我到目前为止的尝试;你的答案不一定要坚持下去。我对任何想法都持开放态度,只要它比我的 hack 更好。)
由于您在执行 INSERT 时已经有了之前的价格和新的价格,因此您可以轻松计算 value_increased 并将其存储起来。所以基本上是的,在 table.
中添加另一个 value_increased 字段不是每次查询 API 时都更新 'end',如果您在代码中跟踪上次 运行 时间,您可以在查询前更新一次INSERT(在初始 INSERT 上将其设置为 NULL)。
类似
$last_row = get_last_low();
$current_price = get_current_price();
if ($last_row['price'] != $current_price)
{
UPDATE product_details SET `end`=%s WHERE 'end' IS NULL;
INSERT INTO product_details (`start`, `end`, `price`)
VALUES (NOW(), null, $current_price)
}
此外,如果您显示所有商品的当前价格,您的查询会变得更加简单 - 类似于
SELECT * FROM product_details WHERE 'end' IS NULL;
而不是更复杂的东西(有多个产品,你必须获得最新的 'end' 然后重新加入才能获得相应的价格。当然,如果你是唯一的人在做正在显示所有记录,这不会是一个太大的因素。
单次更新意味着您访问数据库的次数要少得多(即价格变化的次数,而不是点击 API 的次数)
缺点
缺点是如果您的应用程序崩溃,您将不知道上次获得价格的时间(如果必须跟踪每个价格,您基本上必须在 API 在你最后一次 PRICE 更改后的所有时间。例如
1.00 PM .1
1.15 PM .0
1.30 PM .0
1.45 PM .0
--- application crash ----
使用您当前的程序,您的数据库将具有
1.00 PM .1
1.45 PM .0
因此,对于错误恢复,您基本上会查询 API 以了解下午 1 点 45 分之后的所有价格变化。使用修改后的程序,您的数据库将具有
1.00 PM .1
NULL .0
因此,对于错误恢复,您必须查询 API 以了解下午 1 点后的所有价格变化。请注意,在这两种情况下,API 返回的记录数是相同的,只是 API 的 re运行 有轻微的变化(取决于最后一次价格变化的时间)是)要过滤掉的更大数据集。