We have almost 4000 products. We want to get the products related to each other for example when a product has different flavors. Or when a product has different sizes. We already have "group_id" table but when getting data from them I was wondering if there was a faster way to search all the items from the list that have the same group_id. So every time you load a product you retrieve all with the same group_id.
We're using php.
Related
We are storing data for multiple stores in the same index.
We want to create facets for several fields , like category (which is hierarchical), price, color, size, price , but we want to calculate these facets per store id.
We will never have a use case - where we want to count across stores.
How do we handle this usecase , shall we add storeid as part of all the values we give to facets , or shall we declare all facets as hierarchical , and have storeid as the first level
There may be multiple ways to handle this but based on my experience I'd suggest that when you create your drill down query for your facets (to specify the level in the category hierarchy that you are interest in) and you pass that query a baseQuery, the base query should include your criteria that storeid equals a specific store.
In a sense the storeid needing to be for a specific store is just another query criteria (that you happen to be adding on behind the scenes) for indicating which products the the customer is interested in. This is not much different than if you we also specifying that only products with a specific color are of interest.
I have a relational database for a Burger Building application that a restaurant uses. Two of the tables contained in the DB are Category and Item. These are used to display the categories and then the customer can select a category (E.G. Buns) and view all of the children contained in that category and choose which ones to add to their order. The two tables are linked using a field called CategoryID.
The Item database contains amongst many, the following fields: ItemID, ItemName, TimesOrdered, CategoryID.
One of the required functions is to view the item that has been ordered the most (most popular) per category. This can be retrieved from the TimesOrdered field. However, if two items have been ordered the same amount of times, then there is technically not any item in that category that has been ordered the most.
Therefore, the largest TimesOrdered field will have to be compared to the second largest TimesOrdered field to determine if any items have been ordered the most for that category.
Is there any way to achieve this using SQL? For example, showing the ItemID for each category (using Grouping on CategoryID) that has been ordered the most as long as the item that has been ordered the second most has been ordered less times than the item that has been ordered the most.
I know that this can obviously be done by simply viewing the first two items and comparing the second record's TimesOrdered field with the first record's TimesOrdered field, but as a challenge and a way to improve my SQL, is their any way to get the desired results by using a single SQL statement?
Thanks in advance for any responses :)
Would it be possible to share some sample data? For example, what types of records are in your Item table?
How specifically is your Item table related to your Category table? Do you have multiple items per category?
I'd also want to know how the TimesOrdered field gets updated. Is this something that is updated manually by a user whenever that item is ordered, or handled by code?
Regarding the output: It sounds like you want to display, by category, the item with the most orders. Is this correct? If so, would it be displayed via a query the user runs? It sounds like you want to display something different for categories with multiple items having the "max ItemCount" for that category. If a given category has multiple items with max ItemCount, what should display for that category? Could you provide some sample output of what you're expecting to see?
I'm thinking the best way to handle this would be to use multiple sub-queries, which can get rather hairy in Access. It might be best to break this into separate queries in Access, which you can progressively select from
Create a query Q1 that shows the max TimesOrdered for each category.
Create a query Q2 that uses Q1 to figure out how many items for each category have the max TimesOrdered value.
Depending on how you want to display the final results, you could create a new query, Q3, that either shows NULL for the item in that category (if there's a tie), or the appropriate item. Basically, you'd display the item from each category where the TimesOrdered matches the max TimesOrdered for that category (having to possibly do special handling for categories with ties).
Another thing you might want to think about: What about having a separate Orders table that stores details of each order, rather than having a TimesOrdered field? Of course, that would complicate your queries further, but give you more data to report on.
Might be incredibly naive but it's troubling me nonetheless. As part of my coursework, I have to create a database system for imaginary customers purchasing an item that firstly needs to be made. One problem I'm having is allocating multiple stock items into the works orders table against one particular product ID. So for example, how would I get 4 legs and a table top which would come under two individual ID's (legs and table top) against the product id containing 'table'? I'm currently working with SQL plus.
Image of my ERM is here for clarification
I see that the Sku fields are duplicated in the Product table.
When creating a product in BigCommerce from info in an independent POS system:
If there is only one Sku, do we create a Sku record in addition to the Product record?
If there are two Skus associated with an image and description, do we put the info for the first Sku in the product record and create a Sku record for only the second product, or do we create a sku record for each of the 2 skus?
In another ecommerce solution, each product has at least one variant (the default variant), and if there are 2 variations, then there are 2 variant records. It seems as though the Sku table is like what I am familiar with for variants. But BigCommerce may handle this differently and put the data for the default "variation" in the product record, and only use Sku records when there is more than one variation.
In BigCommerce (and some other systems), SKUs are considered unique identifiers. In BigCommerce, you can only have unique SKU once (no duplicating) and a unique product name (also not able to be duplicated).
SKUs in BC correspond to variants/combinations of options that make up a variant product. There is a default "parent product" or simple product associated with a parent SKU (if any) and then variants generally have unique SKUs, but aren't required to have SKUs.
If a product has variants, you do create additional skus in addition to the parent sku/product.
You can get a little bit more clarity through some of the API documentation for our V3 catalog api
We currently have a SQL database with a table that holds online sales for our company, which sells products using other websites (say, Amazon). The table schema has been set up to hold specific sale data/attributes provided by the website our items are currently sold on (say, Site A).
We are expanding sales to other websites that provide different attributes than Site A uses when an item is sold (e.g. Site A might provide a unique sales id number, and site B might not provide a unique sales id number, but also provide some other info that Site A doesn't provide that we still need to capture).
The question is do I add a separate table for sales on each 'site' that we sell on, as the schema will be different, or try to combine all sales into one table, no matter the platform, leaving some columns null if it doesn't pertain to the particular platform? Or maybe a hybrid approach, separating only the attributes that aren't common among the two sites into separate tables, while a "master" sales table holds attributes that are shared (sale_price, sale_date, etc)?
There are also other tables in play that hold internal information (product Ids, costs, etc), that are linked to the sales table via a unique identifier. Whichever route I choose, I'd need come up with a unique identifier I could use across all tables (auto incremented sale_id, e.g.), and store that in a table for reference/joins.
Any suggestions are welcomed!
A sale is a sale >> same data belongs to the same table. I would definitely not recommend splitting your sales to several tables as this creates lots of difficulty for all that might follow: sales statistics and so on. Try to keep all sales in one table.
If it's a very small project, it might be the best shot to integrate the different fields into one table. Otherwise you might try to create profiles for every sale platform: In this case, use an Entity-Attribute-Value model.
Do not add a table for each site. It sounds like you have a many to many relationship between sites and attributes, so set up your database that way. Also, for any unique identifier you need, create it yourself.