I'm trying to design tables : Company -> Location -> Products tables for a project I'm working on
So basically a company has multiple locations.
Each location can have the same of different products and also products can have different prices across different locations.
So my question is, how can I efficiently design this use case because my problem is that:
If I put the PRODUCTS under the COMPANY Level --> (Product cannot have different prices etc..) but it is easy to REPORT on when doing analytics.
If I put the PRODUCTS under the LOCATION Level --> It gives me the possibility to give different prices to the same product but TECHNICALLY they are TWO different products on the database and cannot report on them easily.
Is it good to add a PRODUCT table and add another table between location and product (PRODUCT_LOCATION) that will have the price and other properties specific to a location?
Thank you for taking the time to read my question,
You can use a mapping table for Location and Product and then using primary key for this, you can create a mapping table with LocationProductId and Price.
Related
I am currently working on a project relating to a medicine stock management system on vb.net.
Basically I have 3 tables in a MySQL database that I will link to my program; orders, current stock, and medicine.
Each order has an autoincrementing order reference, delivery date, units ordered and the reference number of the medicine that has been ordered.
The stock table contains all the medicine names which are in stock, how many units are in stock, the cost price and the retail price.
Finally, each medicine has a reference, a name, and a supplier name.
The tasks I would like to perform throughout my program are:
1- Store and add medicines to the system
2- create, edit and view orders
3- view medicines in stock and the amount of units present
4- search for a specific field in each of these tables
I am quite new to object oriented programming and Vb.net so I would like to know what is the best approach to design this program?
1- Windows form based application with no inheritance seeing that I have only 1 type of product (separate classes for everything)
2- Windows form based but with inheritance and an interface
3- any other more efficient approach?
If I were to choose option 2 I would require just a few guidance tips on what my baseclass should probably be.
Thank you
Well, technically speaking, this is not a stock management system only, if you are including orders. Stock is only the part taking care about stocking items.
What you look for, in a nutshell, is probably:
(Purchase)Orders: Handle their logic separately from stock logic. You will need Orders (List of orders) and OrdersLines tables. I'm just guessing, that you mean Purchase Orders.
(Customer)Orders - you will need similar for Customer Orders, if you don't sell the goods in shop, but to a partners per Invoices.
Item: Table Item - ut will hold details of each medicine - columns like, ItemNo, Name, Description, OrderCode, VendorReference, ReferencePicture, Price (if you have different prices for different quantities, you will need another separate table ItemPrices with ID linked to foreign key of Items), etc.
Stock: Tables StockCards (each linked to Item, it is to store data like minimum, maximum a and actual stock level, you might pre-define stock location), StockRecords (to record movements of goods in and out of stock), you can have also a separate StockLocations
And as for interface, I reccomend to do a List and Detail VB.NET form for each table. List will contain list of items and filters to find what you want. The Detail page will allow to show all the deatails and edit them. You can then load the forms into i.e. TabControl in your main application. And combine them, i.e. put a List into left panel of SplitContainer and detail into right one, and use DataGridView's CellClick to load item into the Detail module.
Hi I am new to development. I am wondering how the database would be structured?
I will have a table for all the store with their addresses, hours, lat/lng, emails. But what about the products? Each store will have multiple products and the user will be able to enter the product on a search input, the stores will be listed and the googlemap will mark all of them.
My question is, should the products be on a seperate table joined with the stores table? If so, should each product be on it's own column like product1, product2, etc? They will need to be connected with the stores.
I suggest you make 3 tables. Product, Shop and the third (Product_Shop) to connect these two tables since you have a m:n (many to many) relationship.
A product can be placed into multiple shops and a shop can contain multiple products. Example: (a shop called tesco can contain products like: milk, juice.., and milk can be located in a shop called tesco, sainsbury, Mark and spencer ect.)
Because of that you need the "connection" table. If you want to learn more, there are loads of explanations on line. Just google: "database relationships"
Here is an example of that, if you want to add more attributes (columns), then do so.
Basic tables and connections:
To connect your database with google maps I suggest to read the following (always refer to the documentation first):
URL:https://developers.google.com/maps/articles/phpsqlajax_v3
First of all, this is very, very simple data warehouse that I made only to ask following, specific question.
Scenario:
I have one fact table FactSales, and 2 dimensions: DimShop and DimProduct, and they are both separated from each other and directly connected to the fact table. some shops can sell selected products and vice versa, some products can be selled in specific shops. This give us many to many relationship. The problem is when I try to slice my cube i get all combinations between shops and products.
Question:
How can I create hierarchy between two separated dimensions in SSAS with many to many relationship? i tried to use brigde table but i was unable to configure hierarchy in SSAS. Is it even possible?
If you're trying to report on "what can happen" rather than "what did happen", you need a separate fact table & cube to represent the relationship between products and the shops that can sell the products. It's not really a hierarchy since it's many to many.
A simple cross reference fact should be fine:
FACT_PRODUCT_SHOP
ProductID
ShopID
Then when doing reports that want to see what products are allowed to be sold in what stores, you can use this fact table. The sales fact only shows "what actually happens".
You can even modify this fact to be your Inventory fact table, just adding a date and "In Stock amount" and "On order amount" etc..
It is possible to implement such a design but it may not perform well.
Basically instead of product and shop key in the fact table, you need an alternative key.
This key will be the unique combination of products and shops. That needs to be prepared in the ETL.
In a new dimension named "Shops and Products", on top of this key, you can create 2 hierarchies Product and Shop in the same dimension.
Additionaly, you can also create an unnatural hierarchy as you requested. But since it is an unnatural hierarchy, it may not perform well.
So in addition to Product and Shop hierarchies, you can provide following unnatural hierarchies: Shop -> Product, Product -> Shop.
I have designed an ERD for a website I am about to build.
This website has 2 groups: the USER and the COMPANY. Different companies (or shops, to be precise) have the option of logging into the site and enter new products into the system. The users can then log in and view products based on brands and categories.
In the ERD I have created all the tables, fields and one-to-many relations to the best of my knowlegde. I think that went well until the category tables.
I want the products to be categorized in like "MEN&SHOES", "KIDS&CLOTHES". I figured out I am going to need 2 tables for that: CategoryPersonGroup & CategoryProductGroup. But I do not know what is the right approach to link this to the products table. Please help! This is my ERD:
I think many to 1 relations between product and category tables would be convenient such as:
Product (N) -- has -- (1) CategoryProductGroup
Product (N) -- has -- (1) CategoryPersonGroup.
You can use inheritance approach to this matter, i.e. make category table to store any values that are common to all the articles, and then make separate tables that will inherit category table, in which you can store your own values for that tables. And that's it, just link the main category table to persons and voila.
I have a query regarding a table structure.We are using single SQL SERVER 2008 Database for two online selling websites.i.e.,The products which the two websites uses are same,but the description about the products are different.For example,we will sell a "Toy" of same price and model on both websites but with different description.At present I used two different id for websites say,Id "1" for Website 1 and Id as "2" for website 2.And also populated the Product table with diiferent Id's for same product along with the description and website id.
Now the problem is I need to find out how many "Toy" has been sold out in both websites together.
Can any one help me out?Should I introduce a separate table structure to relate the Productid?
It seems to me your choices are
minimal change to achieve your purpose
produce a properly normalised design
A minimal change might be that table you propose
A normalised design might be
product
code
standard_description
standard_price
website
code
description
website_product
website_code
product_code
description
price
order
id
website_code
...
order_line
order_number
line_number
product_code
quantity
...
That way the same product has the same code on both websites but you can have differing descriptions (and prices if necessary)