I have question need to query from product table and have many variants and prices, how can I show like below
product. variants. price
==========================
Coke -> Original -> 10$
-> Zero -> 8$
==========================
Pepsi -> Can -> 9$
-> Bottle. -> 10$
==========================
if I have 3 tables : products , variants , product_variant_tranx
any one can help me ?
Thanks
It's a little be late. But this type of question is common for newcomers. I put here my answer for the newcomers who are coming here to search exact type of problems solution.
Every product may generate a unique id like p1,p2,...
Under the products, you enter the variants like variant one, variant two,.. with a unique id(generate when entry, may be visible in the user interface or hidden for working backend) like p1v1,p1v2, with pricing like p1v1 10$,p1v2 8$ etc.
Let's see the tables
Table1. products_table
product_name
product_id
Coke
p1
Pepsi
p2
Table2. variants_table
product_id
variant_name
variant_id
variant_price
p1
Original
p1v1
10$
p1
Zero
p1v2
8$
p2
Can
p2v1
9$
p2
Bottle
p2v2
10$
Call to the user interface
Query1. SELECT product_name,product_id FROM products_table
Then call
Query2. SELECT variant_name,variant_id,variant_price FROM products_table WHERE product_id='getting product id from Query1'
I show the basic logic for newcomers. If having a large number of products and variants then inner looping can jam your server. For this, you may use the same database structures but can use advanced SQL queries.
Relative sources which may help:
https://dev.mysql.com/doc/ (For learning advanced SQL queries)
https://cashflowinventory.com/blog/cash-flow-inventory-tutorial-products-management/ (Get concepts from a likely application's product management interface)
Related
I am writing a query for a SQLite database in which I need to find the best selling product for each region in a list of 6 regions. However, some of the regions don't have any product sold in which case I am supposed to output 'No Product Sold'. I am trying to use an ifnull() statement, but can't get it working.
Currently, my query is as follows
SELECT area.name AS region,
CASE ifnull(sales.area_id, 'No Product Sold')
END AS most_sales
FROM product
JOIN sales ON product.rank = sales.rank
GROUP BY area name
I also know I will likely need to use a nested query, but I'm not sure how yet.
Unfortunately I cannot base this off of rank, it has to be the item with the highest sales in the region. Does anyone know what I am doing wrong?
I am querying my graph where it has the following nodes:
Customer
Account
Fund
Stock
With the following relationships:
HAS (a customer HAS an account)
PURCHASED (an account PURCHASES a fund or stock)
HOLDS (a fund HOLDS a stock)
The query I am trying to achieve is returning all Customers that have accounts that hold Microsoft through a fund. The following is my query:
MATCH (c:Customer)-[h:HAS]->(a:Account)-[p:PURCHASED]-(f:Fund)-[holds:HOLDS]->(s:Stock {ticker: 'MSFT'})
WHERE exists((f)-[:HOLDS]->(s:Stock))
AND exists ((f:Fund)-[holds]->(s:Stock))
AND NOT exists((a:Account {account_type: 'Individual'})-[p:PURCHASED]->(s:Stock))
RETURN *
This almost gets me the desired results but I keep getting 2 relationships out of the Microsoft stock that is tied to an Individual account where I do not want those included.
Any help would be greatly appreciated!
Result:
Desired Result:
There is duplications in your query. Lines 2 and 3 are the same. Line 2 is a subgraph of Line 1. Then you are using the variables a, p and s more than once in line 1 and line 4. Below query is not tested but give it a try. Please tell me if it works for you or not.
MATCH (c:Customer)-[h:HAS]->(a:Account)-[p:PURCHASED]-(f:Fund)-[holds:HOLDS]->(s:Stock {ticker: 'MSFT'})
WHERE NOT exists((:Account{account_type: 'Individual'})-[:PURCHASED]->(:Stock))
RETURN *
It seems to me that you should just uncheck the "Connect result nodes" option in the Neo4j Browser:
I am looking for a way to allow two products to share the same stock/inventory. Everything I have come across suggests using variations but this doesn't work in my case.
This is my current situation. I am selling a unisex t-shirt but would like it to show up in both the mens section and womens section on my store. The tees already have variations in that they are being sold in sizes XS-XL. Ideally, in the mens section the product image would be of a male model wearing the tee and in the womens section the product image would be of a female model wearing the tee. So they're technically two different products but at the end of the day it's all coming from one stock, so I need these two products to share their inventory.
Any help would be much appreciated! Thanks in advance :)
You could technically achieve this by using SQL code and events.
ie,
Create two products that are to share the same stock
Create SQL script that updates the stock level of both products to the lowest amount where there is a mismatch
Create SQL event in database that activates this basic script every 15 minutes.
It's not perfect, and it probably won't work on a shared server (rarely do you have event access on shared services), but it works in theory. You could also do this via cron/php script, but I'm not great at php so, meh.
Here's a similar thing I did for cost of goods sold in my database:
UPDATE wpi1_postmeta as pm
INNER JOIN wpi1_atum_product_data as atum
ON atum.product_id = pm.post_id
SET pm.meta_value = atum.purchase_price
WHERE atum.purchase_price is not NULL
AND atum.purchase_price <> pm.meta_value
AND pm.meta_key = '_woosea_cost_of_good_sold';
Is there any issue in storing the values in SQL Server DB as comma separated values?
I have 100 categories and for each category I have 500 products. My initial thinking is store the product codes in a comma separated values so that only 100 records will come in table:
catagcd1 - prod1,prod2,prod3......
catagcd2 - prod2,prod3,prod5......
But when I ask my friend: don't store it as a comma separated, store as a normal structure. That means:
catagcd1 - prod1
catagcd1 - prod2
catagcd1 - prod3
catagcd2 - prod2
----------------
----------------
What is the difference between my way and his? And what is the difference from a performance point of view also? Can you please explain?
Your friend is probably referring to database normalisation, whereby you either have a 1 to many relationship between category and product, or a many : many (category, product and categoryproduct) if a product can appear in more than one category.
The problem with storing the data in comma separated values is that you need to decode the product string every time you need to work with products, which is likely to be slow and cumbersome.
As an alternative, if you never need to reference products directly, you could also store the product / category hierarchy in an Xml column (approaching the problem similar to a document or multivalued database)
I cant seem to get my head around how to create this
Each Bold Letter is a Database Table
I need this to work with Entity Framework
Product
[ Product belongs to one group]
Product Group - [Computer]
[many to many]
[Group has many items]
[Product belongs to one Group Item]
Product Group Item - [Hard Drive]
[many to many]
[Group Items has Many Fields]
[Fields does not change for each product only changes for each Group Item]
Product Group Item Field - [Form Factor]
[Group Item Fields has many values]
[Field Values Change with each product]
Product Group Item Field Values - [ 3.5" ]
I can pretty much get the first 3 to work
my problem is how to do the last two tables
I hope I explained it clear enough
thanks in advance
alt text http://myimgs.net/images/cjgo.gif
maybe this will help or just hurt who knows
Product = is a harddrive
so:
Group - Computer
GroupItem - Harddrive
GroupItemField - Form Factor : GroupItemFieldValue - 3.5"
GroupItemField - Capacity : GroupItemFieldValue - 600MB
etc...
but the field value changes for each product of type Harddrive but the field does not
I think you may be trying to over-generalise your solution.
It seems to me you want to standardise the information you capture for different kinds of products.
E.g. Hard Drives
1 Supplier1 Model 1a 3.5" 600MB
2 Supplier1 Model 1b 3.5" 200GB
3 Supplier2 Model X 2.5" 600MB
And you want to represent the attributes in a single table:
1 FormFactor 3.5"
1 Capacity 600MB
2 FormFactor 3.5"
2 Capacity 200GB
3 FormFactor 2.5"
3 Capacity 600MB
The problem is that over-generalising like this you lose all the data integrity controls that your RDBMS provides.
You may be better off with:
Product (*Id, Name, GroupId, Supplier, Model, ...)
HardDrive (*Id, FormFactor, Capacity, ...)
Monitor (*Id, Resolution, ...)
Memory (*Id, Capacity, Speed, ...)
Each of the above product specific tables has an optional-to-one reference to Product. With such a design, it becomes impossible to capture Monitor attributes for a hard-drive unless you add a Monitor row for the product.
That said, if you're willing to forego integrity controls, or manage them yourself in code, then looking at sample data helps to produce your schema. (I'm going to use the terminology of attributes.)
AttributeValues (*ProductId, *AttributeId, Value) -- Note a problem here: what type should Value be?
You will need some way of indicating what attributes are allowed for each Group:
HardDrive FormFactor Req
HardDrive Capacity Req
Monitor Resolution Req
Monitor Colour Opt
Memory Capacity Req
Memory Speed Req
GroupAttributes (*GroupId, *AttributeId, IsOptional)
Then you need to indicate the group to which a product belongs (so that you can figure out which values need to be filled in)
1 Supplier1 Model 1a HardDrive
2 Supplier1 Model 1b HardDrive
3 Supplier2 Model X HardDrive
4 Supplier2 Model M1 Monitor
Products (*ProductId, Group, SupplierId, ModelNo)
I'm not sure where your GroupItems fit in.
Relationships
Products.GroupId -> Groups.GroupId
Products.SupplierId -> Suppliers.SupplierId
GroupAttribute.GroupId -> Groups.GroupId
GroupAttribute.AttributeId -> Groups.AttributeId
AttributeValue.ProductId -> Products.ProductId
AttributeValue.AttributeId -> Attributes.AttributeId
NOTE
I've illustrated how you can add columns defining rules for the attribute values. You could do the same for the Attributes table where you'd probably at a minimum need to indicate the data-type of the attribute.
You may notice that it won't be long and you'll soon be replicating the meta-data that your RDBMS provides to define tables and columns. The highly generalised solution does have its benefits such as using a simple template mechanism to capture and view products. But it becomes quite a bit more difficult (in code and processing time) to perform other tasks. So I suggest you consider your requirements holistically against the design.