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.
Related
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...
I am having a DB table that contains orders, of which I need to take a snapshot on certain conditions. The idea behind it is as follows:
An order is opened -> all goods are assigned to the order -> the order is completed and an invoice is generated -> on order cancellation the order is staying open but a 'snapshot' of its last state is saved in DB (this could go for unlimited times, so I need any snapshot to be available, not to overwrite the last one) -> on the event of request of the same order (same client, same goods) the whole cycle repeats again..
So my question goes:
How should one implement it (I do not request code, but approaches and theory of operation)? what could the problems be in this kind of approach ?
PS: I know that this question is tightly related to my own problem, and SO is not about that, but I desperately need help cuz I am really stuck.
Sorry!
you need something to correctly model the order process, you can have a 100 tables model or an elegant 1 single table model...
this database schema should sold your problem (a single table which track the order changes)
create table orderProcessFact
(order_id,
opened_date datetime,
goods_colected_date datetime,
payment_date datetime,
invoice_date datetime,
shipped_date datetime,
canceled_date datetime
);
create table order_items
(
order_id int
item_id int,
quantity int,
price numeric(5,3),
discount ...
)
I am working on an event system that has two tables, EVENTS and EVENT_CREATORS. I have been linking events to creators by placing creator id in the events table as I thought I would only ever have one event creator.
I now need the ability for more than one creator to edit an event. Should I add simply add additional fields to EVENTS table, i.e ec_id, ec_id_2, ec_id_3, etc. Or does it make more sense to add a cross reference table to the database and a separate table for additional creators?
This is those cases, where it would be wise to use a cross reference table. I will explain it step by step. First
Create a new table. Call it "event_reference"
Give the following FIelds: Id, Ref_Id, Creator_ID.
I will omit the need of the EventId, because we are creating a table which is a reference to the event, so event's table will hold the Ref_Id to keep in track of all the references.
Next, Modify the events table and store Ref_ID instead of Creator
In such way, you can fetch all the creators of an events in the normalized way.
You should have 3 tables:
Event (with an ID field)
Creator (with an ID field)
EventCreator (2 fields: eventID and creatorID)
This should pretty much cover every possible relationship between events and creators. You can limit the relationships by creating indexes on the EventCreator table.
The simple say is to just add a cross reference table. This way you don't have to worry about how many creators someone will need in the future.
So, have a table like:
xref_Events_Creators
EventId
CreatorId
I recently made a module that calculates the real gross margin for every order and order_item based on shipping cost data I import. I did this by adding 2 columns to the sales_flat_order table and the sales_flat_order_item table. This seemed to work great, until I realized that when I saved the imported data, it also updated the updated_at value. Since this was the first import of all orders, they all now report having been updated today. This is throwing off reports and other shipping software that syncs with it.
This brings me to 2 questions:
Is adding a column to an existing table (in this case, the sales tables) a major NO-NO?
If not, is there a way to set the data that doesn't increase the updated_at value?
If it helps, the code that actually writes the data is inside my IndexController.php file. It loops through the collection of orders and the items within those orders and sets the necessary values using something like $order->setGrossMargin($orderGM)->save();. I imagine it is the call to save() that is doing it, but I'm not sure the right way around this problem.
In the mean time, I'm working on a solution in which I import the data to custom tables and only read from the sales tables when necessary. Either way, it's a good exercise :)
Brian
Instead of calling save(), did you try:
$order->getResource()->saveAttribute('gross_margin')
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.