I have the following table structure where I am storing activity of a user like 'product creation'
id
user_id
type_id
type
verb
data
created_at
updated_at
Whenever an event happens on a product like ( an order has come for the product), I need to update the updated time, so that the record appears in the first as the user will be seeing the 'sorted using updated_at' row data. The feed which I am referring here will be consumed by a single user and there is no concept of following here. So whoever created a feed will be seeing his own feeds. If there is an update (order placed by someone on that product) coming on the feed, it should go up.
So when an order is placed, I will update the updated time of the entry so that it appears in the first.
I am planning to use redis for the reads, but I am pretty confused on the update part. How will I handle this case.
What I have tried ?
Created the table structure as following
id
user_id - User who created the event
event - created_product
event_id - product_id of products table
data - json object of the product details
created_at
updated_at
When an order is received
The updated_at timestamp is updated. So that the record comes on the top of the user feed.
But this doesn't seem to be a proper solution as frequent updates can come for a row which can lead to row locking and more waits. How do I solve this?
Well, you could create sorted set in redis:
FEED:USER_ID containing values:
PRODUCT_ID - last update time as score
And then get products from database by ids which you got from redis.
But if your main concern is row locking, then maybe you should just queue updates? Create redis sorted set "PRODUCT_UPDATED" and add row whenever you are updating product:
USER_ID#PRODUCT_ID - update time as score
Then create some background CRON job which will update products found in that sorted set. You can do it every second, or every 30 seconds, you can throttle number of updates etc...
Related
currently I found myself wondering if this is the right thing to do in this case.
You see I have a database called for example Warehouse
I this database I have two tables:
[the table items is for saving the items of the system add-modify-delete records]
Items (which its columns are )
TAG_ID
P_NUMBER
QUANTITY
TYPE
LOCATION
DESCRIPTION
REASON
USERID
DATE
[the table lastchanges is for saving the items of the system that has been changed]
lastchanges (which its columns are )
ID
TAGID
PNUMBER
USERID
ACTION
DATING
Now I have been asked to add "exactly what has been changed" to the current form, for example if the quantity changed I have to show that before and after in a bootstrap form.
My brain told me to just add all the columns of the table items into lastchanges and save on those columns the data before changing and into items the new modified data, but performance-wise I see this as a bad action and I want your opinion.
If I understand you correctly you need a history of your DB changes.
If thats the point I would recommend you to create a new row for each entry and soft delete the old one. Then nothing gets lost and you can always get differences or older values.
Adding a the field deleted_at, and created_at as dates would do that trick for you. If deleted_at is null its the current entry, if there is a date set you know exactly when it got "overwritten"
I've the following model Order.
Any order can have such status as new, in work, being delivered, on storage, executed, cancelled.
I found the following code in the model:
As for now every order has number what identifies its status.
If I started the project from scratch I would rather create a separate table with the name let's say order_status and insert primary keys from it into Order table.
What approach is more preferred and why?
Thanks
you can take a column named as status and set the number what ever it is like 1,2,3,4,5,this approach is more convenient than creating a new relation ship table because it uses extra join to retrieve status,it will be useful if order have multiple status at the same time otherwise you can update status of that order in same table.
I'm in the process of creating an application where we are fed several external product feeds daily, and we populate our products database with the feeds.
However the trick is we need to keep the product db in sync with the latest feed(s).
Previously I had toyed with the theory of populating the current product list from db in an array, and doing array comparison with the latest feed, that got gunned down once the product count was in the thousands. (Ran out of memory when trying to get a 5000 records).
So after abit of research, it seems the solution would probably lie on the SQL side, using TRIGGERS perhaps. Though I'm not quite sure how to go about it, hence my question.
So the 2 objectives I need to accomplish with the syncing process:
1) Insert new products that do not already exist in our db. We can accomplish this with the INSERT IGNORE method.
2) Find products on our DB that do NOT exist on the latest feed, and do something to them. (flag as deleted, or move to a deleted products table, etc.)
Step 2 is where I'm having trouble. I'm thinking now maybe for every sync operation, we insert the products from the latest feed into a 'Temp-Products' table, and somehow compare 'Products Table' with 'Temp-Products' table in finding the records that need to be flagged as deleted.
Any advice please?
Thanks
Obviously over-thought this one. The solution as suspected and further enforced by Anigel is to create a temporary table, 'products_temp' to store new feeds. We then run a simple join to find out what products are in the Products table, but not in 'products_temp', hence suggesting that the products have been sold out or deleted on the retailer.
We can then either flag the results of the query as deleted/sold out/do whatever.
The query I used is this:
SELECT products.sku_number, products_temp.sku_number FROM products LEFT OUTER JOIN products_temp ON products.`sku_number` = products_temp.`sku_number` WHERE products_temp.sku_number IS null
Hi I am using PHP to manipulate information in my MySQL database. However I am looking for a way to update a table (all records need to be updated) based on information within another table.
For example I have a list of products lets say 10 each with a unique id stored in a products table. I have a purchases table which has the same product ID and the amount of purchases done for each product. I want to update each product in the products table to reflect the total purchases made for each product and store it in a column called instock which is part of the products table.
How can this be done?
If I understand your situation correctly, you're dealing with a stock-count. When an item is purchased (represented by a entry in the Products table) then the stock count figure should be decreased. This should happen within the same transaction as the new entry to the Products table to keep your data consistent. I would recommend using a Trigger on the table to implement this. You'll find lots of information about implementing triggers in MySQL on this site. A trigger you could use might look something like this:
CREATE TRIGGER update_stock_count
BEFORE INSERT ON Purchases
FOR EACH ROW
BEGIN
UPDATE Products SET stock_count = stock_count - NEW.quantity_ordered
WHERE product_id = NEW.product_id;
END;
This trigger doesn't take into account that there might not be enough stock of a product, nor does it handle updates or deletes on the Purchases table but it could be modified to do so.
I have a software in PHP and postgres that I use for invoicing. I am running a stock management system that I created. i am trying to create a stock movement page where I can see when a part came in, where it was issued and when and also when it was credited (if it was). I am running 5 tables for the stock. My main one is part2vendor, parts, expenses, wo_parts and int_part_issue. When I receive stock, it goes into the table part2vendor (onhand gets increased by number received). The expense table gets the details of the part number, the supplier invoice and the date received. wo_parts stores the part number issued to a workorder. int_part_issue is when I do a stock adjustment or use a part internally. I am looking to create a PHP table that would list (in date order) the 'paper trail' of a part. I can let you know table names and columns if required. Thanks.
Sounds like you need a simple history table?
Columns
part_history
id
part_id
date_modified (timestamp)
action ( or maybe action_id if you have an actions table)
vendor_id
And when you get a new part, and add it to the parts2vendor table ( i think u said) you would use the inserted part ID (or unique part id ) to add a record rto history
INSERT
(id, part_id, action, vendor_id)
46565, 5757575, "Purchased", 757575
The date will be inserted as a timestamp by postgres
Than for any part yuou can grab history relying on the uniquer id
sort by date_modified DESC.