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
Related
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.
I have a situation, where with time, the same logic has been scattered at different places (stored procedures) in the application. I am trying to bring it in one place and re-use it as required.
Scenario:
We sell products online, that are classified into categories and the business rules vary by category. When performing a search, it is possible that multiple products are returned from the same category.
Examples of business rules are:
Can the agent sell a product from this category (permission, licensing etc.)?
Can the category be sold in a particular state?
Is there a tax to be applied on the category?
What is the markup for this category?
Does this 'product' meet the customer's requirements?
Current Implementation:
Step 1 - Searching
We have a stored procedure that takes #agent_id, #state_id, #markup_amount, #category_id, #customer_id as inputs and returns all products from a specific category, that meet the customer's requirements. The customer's requirements are derived using customer_id. (SELECT 'product' stored procedure)
Step 2 - Quoting
When adding a particular product to the shopping cart, the above logic is again executed with an additional parameter #product_id, to make sure that the product being added to the shopping cart, satisfies the original requirements (INSERT 'cart' stored procedure)
Step 3 - Re-Validation
If the customer's requirements change, it is possible that products already in the shopping cart still qualify. The ones that do not qualify have to be removed from the UI (is_active_flag is set 0 on SQL). So we re-use the same logic to determine what the products still meet the customer's requirements. (UPDATE 'cart' stored procedure)
Step 4 - Sale
The customer can only buy one product from a particular category. When the customer is ready to buy, we re-run the same logic to see if that particular product still passes all business rules including meeting the customer's requirements (INSERT 'sale' stored procedure)
Consolidation:
What I am looking to do is consolidate this logic in one place and reference it in different stored procedures, as required. The only variable is #product_id. When the initial search is performed, we do not know what products will qualify. Once we have a finite list of product ids, we are drilling down that list at each step.
For Example: The search stored proc may return 500 products which forms the finite list and the customer may end up adding 3 products to the shopping cart, and in the end can buy only 1. The 3 products that were added and the 1 product that was ultimately sold are a part of the finite list of 500 qualifying products.
What is the most efficient way to achieve this? Thank you.
If your goal is create something readable, you can create a boolean sql function that evaluates each product in each scenario.
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.
Just to be clear, I'm going to store my shopping cart in a database.
It's just that I would like information regarding the details on how to store it exactly.
I have the following structure for my shopping cart and orders:
First of all, is this technically a good approach?
A product is added to a cart with the sessionID, date and amount.
Do I add another table or rename the table given that it's not really carts but more collection of products from different carts?
When a user wants to order his products we place them in the order_items table. When the user selects purchase his order is placed in the orders table.
Is this a good approach, are there better ones?
P.S.: the user doesn't need to be registered to place an order.
What I usually do is have an intermediate table, something like ProductsInCart, with three columns, ProductID, CartID, and Quantity. ProductID keys into Products, CartID keys into Carts, and quantity is simply a positive integer.
I have a doubt regarding a database design, suppose a finance/stock software
in the software, the user will be able to create orders,
those orders may contain company products or third-party products
typical product table:
PRIMARY KEY INT productId
KEY INT productcatId
KEY INT supplierId
VARCHAR(20) name
TEXT description
...
but i also need some more details in the company products like:
INT instock
DATETIME laststockupdate
...
The question is, how should i store the data?
I'm thinking in 2 options:
1 -
Have both company and third-party, products in a single table,
some columns will not be used by third-party products
identify the company products are identified by a supplier id
2 -
Have the company products and third-party in separated tables
3 - [new, thanks RibaldEddie]
Have a single product table,
company products have additional info in a separated table
Thanks in advance!
You didn't mention anything about needing to store separate bits of Vendor information, just that a type of product has extra information. So, you could have one products table and an InHouseProductDetails table that has a productId foreign key back to the products table that stores the company specific information. Then when you run your queries you can join the products table to the details table.
The benefit is that you don't have to have NULLable columns in the products table, so your data is safer from corruption and you don't have to store the products themselves in two separate tables.
Oooo go with 3! 3 is the best!
To be honest, I think the choice of #1 or #2 are completely dependent upon some other factors (I can only thing of 2 at the moment):
How much data is expected (affecting speed of queries)
Is scalability going to be a concern anywhere in the near future (I'd guess within 5 years)
If you did go with a single table for all inventory, then later decided to split them, you can. You suggested a supplier identifier of some sort. List suppliers in a table (your company included) with keys to your inventory. Then it really won't matter.
As far as UNION goes, it's been a while since I've written raw Sql - so I'm not sure if UNION is the correct syntax. However, I do know that you can pull data from multiple tables. Actually just found this: Retrieving Data from Multiple Tables with Sql Joins
I agree with RibaldEddie. Just one thing to add: put a unique constraint on that foreign key in your InHouseProductDetails table. That'll enforce that it's a one-to-one relationship between the two tables, so you don't accidently end up with two InHouseProductDetails records for one product (maybe from some dataload gone awry or something)
Constraints are like defensive driving; they help prevent the unexpected...
I would advice on using point #1. What happens when another supplier comes along? It's also more easy to extend on one product table/produst class.
Take into account the testing of your application also. Having all data in one table raises the possible requirement of testing both the 3rd Party & Company elements of your app for any change to either.
If you're happy that your Unit test would cover this off its not so much of a worry... if you're relying on a human tester then it becomes more of an issue when sizing the impact of changes.
Personally I'd go for the one products table with common details and separate tables for the 3rd party & Company specifics.
one table for products with a foreign key to the Vendor table; include your own company in the Vendor table
the Stock table can then be used to store information about stock levels for any product, not just yours
Note that you need the Stock table anyway, this just make the DB model more company-agnostic - so if you ever need to store stock level information about third-party products, there's no DB change required