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.)
Related
I am creating a health and nutrition application and I am using unity as my engine. I have a SQLite database which holds the recipes, the fields are ID (primary key), Name, Ingredients and Method. Each recipe is a record in the database and they have their own lists of ingredients. The intent is to allow the user to input ingredients and the program will filter the recipe by ingredients
I expect that when the user inputs flour (as an example) it will show all the recipes that use flour. E.g.: Apple pie, cake and so on. Instead if i want to search the ingredients the input has to be identical to the entire lest
You need to read up on how relational databases work. Right now, with everything in one table, your database isn't really any more useful than a simple Excel spreadsheet.
You want three tables; one for ingredients, one for recipes, and one to join them, which I'll call Ingredient_Recipe. Ingredient_Recipe table will have two foreign keys, one from the ingredients table, one from the recipe table. Then you can do SQL queries like this example:
select Recipes.recipeName
from Recipes
INNER JOIN Ingredient_Recipe ON recipe_ID = Ingredient_Recipe.recipe_ID
Where Ingredient_ID = "oregano"
Which should tell you every recipe that contains oregano.
the classic relational way to do that is to have an ingredients table and a relator table (ingedientrecipe) so that you can query for all the ingredients in a recipe or all recipes that contain a given ingredient
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.
After the user logged in , I need a page where each registered user has his own gridview and controls binded to his gridview.
The page will contain a sqldatasource binded to the gridview .
I thought about making a new table in the database for each user and in the form load to get the username after the user logged in, get the table name and replace the sqldatasource bind to his table name and the other controls fields for table name to his one.
Or is there any other way of doing this?
You definitely do not want to make a separate table for every user. How on Earth would you plan to scale that to multiple users?
What data does the user need to see on their page? Understand that a gridview doesn't have to map directly to a database table. It can map to any set of data. So you can store the data in your database in a way that makes sense to persist it (relational entities), then query and display it in a way that makes sense to display it.
For example (and it's a contrived example, since we don't know what data you have), if you have users who need to see a list of products that they've ordered, then you wouldn't create a table of products for each user. You'd probably have a table for each of the entities (User, Product, Order, etc.):
Users
----------
ID
Name
etc.
Products
----------
ID
Name
etc.
Orders
----------
ID
UserID
DateOrdered
etc.
And since each order would have a list of products, and each product can be on many orders, that's a many-to-many relationship. So you might create a linking table for that relationship:
OrderedProducts
----------
OrderID
ProductID
Then, for displaying in the UI, you would query the data to get only the products ordered by that user:
SELECT DISTINCT
Products.ID,
Products.Name,
Orders.OrderedDate
FROM
Users
INNER JOIN Orders ON Users.ID = Orders.UserID
INNER JOIN OrderedProducts ON Orders.ID = OrderedProducts.OrderID
INNER JOIN Products ON OrderedProducts.ProductID = Products.ID
WHERE
Users.ID = #userID
This should give you a list of distinct products ordered by that user and when they were ordered. (Note that this code is free-hand, I don't have a database handy to test it.)
So each user would see their own specific information.
You want to make sure that your data is modeled in a usable relational fashion. Define your entities (usually real-world things you're representing in the data) and define tables to represent those entities. Relate them together in natural ways. Relational databases are great at handling complex queries against well-defined data. Don't try to design your database around the nature of the display from the perspective of the user, design it around the nature of the information being stored.
You certainly DO NOT need a separate table for each of your users!
Why don't you just add an additional column to one of your tables to store the username. This way, each record is marked to belong to specific user. Reading the data for logged user is just a matter of simple Where clause on the table.
No thats not right,
You can't create a table for every user. Think if you have 10,000 users than you mean your database contain 10,000 users.
You have to create only one table in which all user's information is saved.
You have to save an identity like user name or email to your database and
When user login to your app by his username or email the information will be taken from table on the basis of username or email and set to gridview.
May it helps you...
this is not Logical to create a table for each user,save all user information in a table is better and faster
for this your can make a table for user information with a user id, and another table for user data entery.and make a relation ship between them
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.
If i have bills (from vendors), and invoices (to customers), would it be better to keep them separate (in two tables), or in a single table?
What about vendors / customers?
These are all relational-inheritance problems, can you give me some best practices regarding this?
It seems to me that an incoming bill and an outgoing invoice are really different things:
The outgoing invoice will have line items that match your product table
The incoming bill will have a very formal approval process, involving managers, finance, and accountants
The "From" on an incoming bill is your partner, but on an invoice, the partner's name is the "To"
Entities that are that different should have their own table. If they have common properties, you could store them in a Document table, and create a relation between that table and the Invoice and Bill table.
I would suggest that if they are separate concepts, keep them separate. Usually when you start out designing a database and you have entities that have the same columns in their tables, the urge arises to consolidate them into 1 table. If you know for a fact that for the duration of the solution, you will never need ta add say customer-specific fields or vendor-specific fields, I would say go ahead and make them 1 table.
Keeping them separate allows each entity to develop on its own as the system grows and matures.
A dangerous road for many reasons.
I suppose logically speaking you could collapse everything into one table with a column "PrimaryKey" and optional columns Col1, Col2, Col3, etc. all varchars interpretable to other types.
Especially with financial data where there are audit trail and archiving issues, this is not a simplification.
(But it's the sort of strategy we all go through as a passing phase ...:) )
In our ERP system we have bills and invoices separate; vendors and customer we have in one table.