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.
Related
Sorry if this is obvious but I'm new to database design.
A customer must make a reservation before renting an item(s), he provides details up front such as dates of reservation, item type etc. The employee checks if item is available before allowing the customer to rent it. If available he enters item id, rental date, return date, etc into the system.
Am I correct in creating two tables for this? One for Reservations(which includes the proposed rental info.) and one for Rentals (Which includes actual rental info). And If so, wouldn't these have a one to one relationship? How could I get around this one to one relationship? Should I merge the two tables?
Firstly, since a reservation may never materialize as a rental, the relationship is not exactly 1:1 but 1:(0-1).
I would think that it's correct that you model them as separate entities since:
They may have different "life cycles".
They most likely have different properties.
A rental will probably be related to a bunch of other entities compared to a reservation. Those FKs will make sense for rentals but not for reservations.
I might be wrong but from what i'm understanding you can have just 1 table for rentals and have a column named status as enum (0,1) 0 being available and 1 rented. I'm assuming you are not renting the same item at the same time.
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 a site that provides an e-commerce service, basically allowing sellers in the industry to place their products up for sale to clients. Sellers select the products they wish to sell and set the price. They are then hands off.
In a simplified form, I have the following relevant tables in my database for storing product and order information:
Product_Info
--------------------
ID (autonumber)
name
...
Order_Head
--------------------
ID (autonumber)
CustomerID
...
Order_Line
--------------------
ID (autonumber)
OrderHeadID
ProductID
...
This works great for simplified orders where customers choose any number of products and add them to their cart. However, I'm now faced with the problem of adding seller created and managed 'packages', wherein sellers can group multiple products together into a single item and sell it at a lower price than the individual items would cost together. For instance, if oranges costs $15 and apples costs $20, a package containing 2 oranges and 1 apple may only cost $35.
The twist, and the part that has me stymied right now, is that I would very much like packages to be able to contain other packages. For example, a seller could make an "assorted oranges" package containing 3 oranges. They could then make an "assorted fruit" package that contains 2 apples and 1 "assorted oranges".
How to manage that is confusing me both from how to list the products within a package when I could be referencing an ID from either the product table or from the package table, and from how to record the products in the order_line table since the productID could be pointing to either a product or to a package. And, of course, this needs to be designed in an efficient manner so we're not taxing the database server unneccessarily.
I'm primarily a web developer and haven't done much with e-commerce before. Could anyone offer some direction as to an appropriate set of tables and table modifications to apply to the database? I don't know why, as it doesn't seem like it should be that complicated, but this one has me stuck.
For reference I'm using MySQL 5.1, connected to ColdFusion MX 7 (soon to be 9).
EDIT:
Thank you for the responses so far. I will take a little time to think on them further. In the mean time I wanted to clarify how the order process works since it appears to be more relevant than I may have originally assumed.
My product works similar to Shutterfly. Photographers post photos, and clients may purchase prints. The photographers need tools to set all the pricing, and will often offer packages if it is from a professional shoot. Fulfillment is done by a lab that my product submits orders to automatically, but they have no knowledge of pricing, packages, etc.
Photographers also have the option of running specials to provide clients with x% off or BOGO deals, but I can handle that separately. For right now I'm more concerned about an efficient and simple way to store the photographer defined packages, the client's image selection for each product in the package as they shop (currently stored in a order_line mirror table), and the eventual order details, so that they can be queried for display and reporting quickly and easily.
Create an additional table which lists the items which are members of each package, and the quantity included in a package.
Table Package_Items
CREATE TABLE Package_Items (
package_id INT NOT NULL
item_id INT NOT NULL,
item_quantity INT NOT NULL DEFAULT 1,
FOREIGN KEY (package_id) REFERENCES Product_Info (ID),
FOREIGN KEY (item_id) REFERENCES Product_Info (ID)
PRIMARY KEY (package_id, item_id)
);
The package_id column references the row in Product_Info which is the main package item. item_id refers to other items which are package members. There can be multiple package_id, item_id combinations.
Using this method, you can create new rows in Product_Info which represent packages. All that needs to be done to add items to the package is to add corresponding rows in Package_Items. If a row added to Package_Items happens also to be a package product itself, no extra work needs to be done.
Just take care not to add a package to itself.
This is a tricky set of requirements, especially because you haven't told us about fulfillment yet, or any other discounting schemes, or what happens when customers return a single item from a package for a refund...
Michael's design is a good way of storing the hierarchical nature of your product offering.
The next question is "where do you store the price of the package" - as it is not the sum of all products. I'd recommend storing the price in the "package_items" table.
What do you then do with the "order_line" table? You have three options:
add a package with it's price (but not the items that make up the package),
add the package with its price and the items that make up the package at a price of zero,
add the items with their regular price, along with a discount line for the package.
If whoever fulfills the order knows about packages, you could go for option 1. However, the customer, comparing their shipping note against the products they receive, might be confused.
If you want to show each line item, but hold on to the "package price", option two allows you to show the line items; if a customer wants to return an item, you have to work out what the value of that item is in some off-line way.
Most supermarket tills use option 3 - it's also a nice way of showing customers who are just shopping for items that they got a "bonus" discount because their order matched a package.
If there's any chance that the order items won't all be shipped at the same time, you have to decide what to print on the shipping note - this is a huge pain in the backside, and often affects terms and conditions, and (in Europe) tax.
If you plan to offer other types of discount (e.g. "spend x, get y free", or "10% discount on orders over x"), you need to get this very clearly defined, because the way discounts can compound eachother often upsets retailers - that's why they usually offer "cheapest item free" in package deals.
I come from frontend background, so I apologize if this db question seems dumb.
Say I have a database that handles orders of car and car accessories. If Car is non-customizable, then everything is easy-peasy. For every order, we simply need to associate the OrderId with the Car's ProductId. But a Car is a Product that can contain one or more Product like navigation, seat heater, etc. And users can also purchase those accessories Product separately.
How should we handle this best? Should every Product a user orders be given a unique ProductOrderId in the order table and if that Product can contain another Product, then we put it in a table that associates ProductOrderId with ProductId?
If we do this, would the db grow out of control? Seems a little inefficient to me. I have a feeling there is a better way.
If you look at how complex products are typically billed, the main item and each of its options are treated as separate line items in the bill of sale. In that kind of scenario, a car is a product and each of its accessories are also products. You can have an involuted relationship on product to indicate which accessories go with which type of car.
Your data model for this scenario would look something like this:
Alternatively, you could have a scenario where you want a level of abstraction such that your bill of sale contains only a single item, being a fully accessorized car. That requires the order item to become more like a header in a bill of materials, like so:
I am currently in the process of rolling a custom order-processing system. My current structure is pretty standard, invoices, purchase orders, and items are all kept in separate tables. Items know which form(s) they are on by keeping track of the form's id, but forms don't know what items are in them (in the database). This was all well and good until I had a new requirement added to the mix: stocking orders.
The way a stocking order works is that sometimes a customer places an order for more units than what is in stock, so we want to place an order with our supplier for enough units to fulfill the order and replenish our stock. However, we often have to build these orders up as the minimums are pretty high, so one stocking order is usually comprised of several customer orders (sometimes for the same item) PLUS a few line items that are NOT connected to an order and are just for stocking purposes.
This presents a problem with my current architecture because I now need to keep track of what comes in from the stocking orders as often suppliers ship partial orders, where items have been allocated, and which incoming items are for stock.
My initial idea was to create a new database table that mostly mimics the items table, but is kind of like an aggregate (but not calculated) table that only keeps track of the items and their corresponding metadata (how many units received, how many for stock, etc) for only the stocking orders. I would have to keep the two tables in synch if something changed from one of them (like a quantity).
Is this overkill, and maybe there's a better way to do it? Database architecture is definitely not my forte, so I was hoping that someone could either tell me that this is an ok way to do things or that there is a better, more correct way to do it.
Thanks so much!
For what it's worth, what I'm using: VB, .NET 4.0, MySQL 5.0
Also, if you want clarification on anything, please ask! I will be closely monitoring this question.
Visit databaseanswers.com. Navigate to "free data models", and look for "Inventory Management". You should find some good examples.
you didnt mention them but you will need tables for:
SUPPLIERS, ORDERS, and INVENTORY
also, the base tables you mention 'knowing about' - these probably need associative style many to many tables which tell you things like which items are on which order, and which suppliers supply which items, lead times, costs etc.
it would be helpful to see your actual schema.
I use a single Documents table, with a DocType field. Client documents (Order, Invoice, ProForma, Delivery, Credit Notes) are mixed with Suppliers documents (PO, Reception).
This makes it quite easy to calculate Client backorders, Supplier backorders, etc...
I am just a bit unhappy because I have different tables for SUPPLIERS and CLIENTS, and therefore the DOCUMENTS table has both a SupplierId field and a ClientId field, which is a bit bad. If I had to redo it I might consider a single Companies table containing both Clients and Suppliers.
I use a PK (DocId) that's autoincrement, and a unique key (DocNum) that's like XYY00000, with
x= doc type
YY= year
00000 = increment.
This is because a doc can be saved but is only at validation time it receives a DocNum.
To track backorders (Supplier or Client), you will need to have a Grouping field in the DocDetails table, so that if you have an Order line 12345, you copy that Link field to every Detail line related to it (invoice, Delivery).
Hope I am not to confusing. The thing works well, after 3 years and over 50,000 docs.
This approach also implies that you will have a stock holding which is allocated for orders - without individual item tracking its a bit tricky to manage this. Consider, customer A orders
3 pink widgets
1 blue widget
But you only have 1 pink widget in stock - you order 3 pink widgets, and 1 blue.
Customer B orders
2 pink widgets
But you've still only got 1 in stock - you order another pink widget
3 pink widgets arrive from the first supplier order. What are you going to do? You can either reserve all of them for customer A's order and wait for the blue and red widget to arrive, or you can fulfill customer B's order.
What if the lead time on a pink widget is 3 days and for a blue widget it's 3 weeks? Do you ship partial orders to your customers? Do you have a limit on the amount of stock you will hold?
Just keeping a new table of backorders is not going to suffice.
This stuff gets scary complicated really quickly. You certainly need to spend a lot more time analysing the problem.