The goal
Count products on sale, regardless of the category.
A little description
There is a table in my database called Categories. Follow the structure:
'Category_Id', 'tinyint(3)'
'Category_Name', 'varchar(45)'
'Category_Products_Quantity', 'int(11)'
All of the products of my application have a category and I set this at Products table ā referencing category's id.
As you can see, there is ā in my table ā a column called Category_Products_Quantity. This column stores the number of products in some category. To increase or decrease the products quantity, I have two triggers: one to incrase; one to decrease.
So far, so good, huh?
The problem
The problem appears when I need to count the quantity of products on sale. I have a third table called Market_Products which stores the products in their respective markets. Follow the structure:
'Product_Id', 'int(11)'
'Market_Id', 'int(11)'
'Product_Price', 'decimal(10,2)'
'Product_State', 'int(11)'
Can you see Product_State? So, this column is responsible to flag if the product is on sale or not. "Sale" is not a category, unlike "Bazaar" which is a category.
My question is: In this scenario, how can I count the products whose Product_State is nonzero?
Technical details
I'm working with C#.Net 4.0 + MVC 4 + Razor Engine 2 + Entity Framework 5 + MySQL.
Shortly
I have an online store application. Entity Framework generated the CRUD for me. My application have products and categories. I can count how many products are in each category. The price of each product is determined by the different markets. These markets can mark an item as an offer. I need to treat an offer as a category to count how many products are offers.
This should give you what you're looking for.
SELECT COUNT(Product_ID)
FROM Markets_Products
WHERE Product_ID <> 0
If NULL is possible in your Product_ID column then you'll want to change your WHERE clause to this
WHERE isNull(Product_ID,'') <> 0
Try this
SELECT COUNT(Product_ID)
FROM Markets_Products
WHERE Product_ID IS NOT NULL
I hope it helps
Related
Im making an ordering system where there is a product,supplier and order table. What I'm trying to do is when you order, it can have multiple product and one supplier. Example us OrderID 001 it can have 3 products from product table and 1 supplier from supplier table. How can I do this?
Sorry for asking too much but I don't have a code yet for this part of the system as I don't know where to begin. Thank you.
Create an Orders Table.
Add all ordered products to the order Table.
In the table the three products would all have the same order_id, but a different or (in case someone bought two of the same) same product. You will also need to track the amount they purchase with each row, in case the amount changes.
Select Sum(purchase_amount) from orders where order_id = "YOUR_ORDER_ID"
Select * from orders where order_id = "YOUR_ORDER_ID"
...3 rows show up
You may want to have an order_summary table as well that contains the total amount, etc.
I got site for selling products. In my database I have 3 tables: Users, Countries, Products.
Each user can sale his products in many countries.
When clients come to visit, my site, they can choose to search for product by country and by product price( same product sold by same user can have different prices in each country).
I thought about two implementations for this:
Create a linked table with user_id, country_id, product_id. In this case each time I would like to add new product I will need to update two tables, the linked table and the products table.
Or create new table for each country, that will have products in it. So when I will have to add new product I will only need to update one table.
I like my second solution more, because I think it will perform faster, for both reading and inserting, how ever it's management is hard, I will have lots of tables, and what if instead of counties I would like to use cities, I will get thousandths of tables.
Is there a way in MySQL to create a table of tables?
What do you think about my design will it rarely perform faster?
Do NOT go for the second solution. Relational databases are meant to have a fixed number of tables, and you will run into a lot of problems if you try to have a variable amount of tables in the manner you describe.
If I understood your requirements correctly, you should probably use two linked tables: one that contains user_id and country_id (thus telling where each user may sell products), and one that contains country_id, product_id, and price (thus telling the price of each product in each country). (This assumes that a product costs the same within a country no matter who sells it.)
I have the requirement to build a asp.net sign up form which will allow students to register a training. So far I built a database in sql server and 3 tables: student, training & studenttraining
My question is, how can I limit the form from displaying the dates available once a particular training gets full, or meabe how can I prevent by checking the tables that the user can register?
Select count(*) as SeatsFilled, t.TrainingKey, t.TrainingDate
From Training t
Inner Join StudentTraining st on t.TrainingKey = st.TrainingKey
Group By t.TrainingKey, t.TrainingDate
Having count(*) < t.TotalSeats
TotalSeats is a column in the Training table that specifies how many seats the training provides. I assumed StudentTraining is a many-to-many bridge table between Students and Training.
You'll need to establish what "full" is first. Then, you can do a simple
SELECT COUNT(id) FROM table to determine if the full amount is already reached.
I guess you could have a MaxTraining column in the training table and when you get the data for your form, you can count the training entries in studenttraining, and if it equals MaxTraining, then don't bring that training entry, cause it means it's already full.
I have a list of about 20 products, each with up to 30 possible attributes. Iām trying to figure out the best way to use checkboxes (representing the 30 possible attributes) on a form to filter the products, so that only products with the matching attributes would be shown. I can use SQL Server 2005, but it seems like that might be overkill. Any suggestions?
(Additional) Edit: Ok, given the data structure below, how would you query the database to return products that have ALL of the matching features? Say Product #1 has features 1, 2 and 3. Product # 2 has features 2, 3 and 4. A query for features 1 and 3 should return Product #1, but not Product #2.
Products table
productID int
productname nvarchar(50)
Features table
featureID int
featurename nvarchar(50)
FeatureMap table
featuremapID int
productID_fk int
featureID_fk int
First you would gather the properties that the user selected from your UI
List<string> filter = this.GetAttributeFilterFromUI();
string featureNamesParam = "(" + string.Join(",", filter) + ")";
Then you should be able to use a parameterized query, whose SQL would be something like:
SELECT ProductID FROM Products P
JOIN FeatureMap FM ON FM.ProductID = P.ProductID
WHERE FM.featureID_fk IN
(SELECT FeatureID FROM Features WHERE featurename IN #FeatureNames)
The database would work fine for this. If the attributes for your products is fixed, you can create a single table with your product Id/Name and each attribute would be in a column with boolean/bit types named "IsGreen", "IsBlue", "HasWarrant", etc. If you think atrributes may be added or removed over time, you'll want to setup an "Attribute", "Product" and "ProductAttribute" tables to match up the products and attributes accordingly.
You can then setup your ASP.Net web page to use a CheckBoxList control that has all of the options available. You can then go through the list of check box items in this list to determine which values have been selected and setup your database query from there.
If you want a "dynamic" approach to your search results, set the AutoPostBack property of the CheckBoxList to "true" and then every time a check box is selected or deselected, the SelectedIndexChanged will be triggered and you can update your search results accordingly. This way the user doesn't have to press a "search" button every time.
Hi SQL Server is not overkilling, you can use it very easily to create the Product table and insert the data. After you tell us the schema you have created for your table we could see how to handle this.
Preferrably MS SQL, I want to make the switch over from MySql.
So I have this awesome customer who has 4 Excel Files. Each Excel file represents a Product Range.
Within each Excel File, there are between 3 to 8 Sheets. Each Sheet representing a Type of Product within that Product Range.
Each Sheet, contains the following Columns:
PartNo, Description, QTY, Price1, Price2, Price3, Price4...
(There's never been, and won't be any more than 8 Price Columns.)
Each Sheet may contain from about 5 to 5000 rows.
Now, the problem I am facing now, is not knowing which would be the best way to go about setting up my new Database.
The way I currently have our existing MySQL Database is each Sheet represents a Table. That's it! (It had to be put "out there" quickly, hence the lack of time invested into setting up a proper format/structure for the DB.)
I've recently found that I am much more competent using MSSQL databases, so I want to make the switch, and the second reason, the main reason, is because I want to restructure the Database so I can make things easier to manage, and make it easier to setup Database searches from my site.
I'm not worried at all about How to insert everything into the database, as in my spare time for the last year I've written an app that parses these Excel files, extracts the sheets, and inserts them into the DB, with optional settings. I am worried about how I should actually setup this new DB.
What would be the best way to go about this given the above details?
Any help at all is greatly appreciated. Thank you!
Update:
About the Pricing Columns (Example), a little info on why there are more than one price columns in each sheet.:
Price column 1 may be Galvanised Unit Price, Price Column 2 may be Galvanised Box Price, Price Column 3 may be Stainless Steel GR304 Box Price, while column 4 may be Stainless Steel GR316 Unit Price. These price columns are different for each Product Range, however, some products in a Product Range may also contain some of the same Price Columns. This is why it was so easy to have each product as a separate table.
I assume that you're seeking advice on the design of the database, right?
I'd never design the database with each sheet representing a table. I'd have one table per conceptual entity, and in your case Product is the obvious one.
So a table called Products, with the columns you mentioned above. To accomodate the Product Type, I'd simply have a Type column that indicates which Product Type any particular Product belongs to. I'd eventually use an enum type in .Net to specify the different types that is supported.
Well, that was my five cents. Hope it helped.
A simple solution would be to split it out into 3 tables. ProductRange and ProductType are linked to the Product table through the foreign key relationships.
ProductRange
Id
RangeName
// Plus any other columns you need. eg description, startdate etc
ProductType
Id
ProductTypeName
Product
Id
ProductRangeId
ProductTypeId
PartNo
Description
Qty
Price1
// etc
If you wanted more flexibility around the price, you would create another Price table with a many-to-many joining table between the Product and Price tables.
Price
Id
Description
Price
ProductPrice
PriceId
ProductId
Your Product table wouldn't contain any price columns in this case. But you are now able to add as many Price Types as you need and each Product could have any number of Prices.
Having multiple columns for price seems a little odd to me unless Price1 means "Business Rate" and Price2 means "Consumer Rate" or something similar. If the different prices are for different features of the same product, you might want to consider separating them out into a different table. For example:
Products table: KeyTable, ProductDescription...
Price table: KeyTable, KeyProduct, PriceType, Price
Alternatively, depending on how the prices are calculated, you could work the various other prices from one base price. For example, if a business rate price would be to add 5% to the base price and a consumer price would be to add 20% to the base price, these probably should not be stored in the database as they can easily be calculated when they are required.