I need help in designing a database model for my company.
basically it is a trading company into industrial products. so we have sales,purchases,inventory,warehouses,employees,receivables,payables, etc. as main functions.
I would greatly appreciate someone's help or guidance on how to go about it.
i have made the following tables:-
sales invoice
invoice no(PK),
salesmanid,
customer code,
customer name,
voucher type,
invoice date,
invoice amount,
warehouse id
sales items
invoice no,
itemcode,
sale qty,
sales price
inventory items
itemcode(PK),
item name,
qty in stock,
cost price
customer list
customer code(PK),
customer name,
customer address,
salesman id
i need help with defining proper keys and advise on adding/removing coloumns, etc.
My best advice: If you have to ask how to design a receivables table, you probably shouldn't be writing the receivables system. I've designed enterprise systems with over a thousand tables and I wouldn't willingly tackle an accounting system. With most custom development the system you deliver defines the business process to some degree. Your way can be slightly different than the designers envisioned and still be better.
With accounting software, there is One Way It Should Be Done. Your absolute best case is "we didn't screw it up".
Inventory, on the other hand, is usually domain-specific enough that it warrants custom coding. So: Why one big text field for address? Don't you need to know what state they're in (maybe not)? Do you analyze shipments by zip code? Do they have a phone number you care about? Customer name is often separated into first and last (at a minimum).
You might want to hold off on the database design until you know exactly (or mostly) what you're going to do with the data. Mock up a few reports, and a fake email cmpaign. Sketch out some interface screens. Then you can come back to the DB with a clearer idea of what you need. It does you no good to create an overly generic design upfront, and then have to keep modifying it. Of all the things you can change in your application, the DB is probably the toughest, so I'd try to work out the kinks in other areas first.
sales,purchases,inventory,warehouses,employees,receivables,payables,
etc. as main functions
Sales, purchases, receivables, and payables (at the very least) are accounting functions. If anybody proposed designing our own accounting software instead of buying it, I'd fire them. Or at least poke them in the eye with a sharp stick.
Sometimes, there's something to be said for reinventing the wheel. But not this wheel.
Related
I'm a little stumped on whether i can make this process of changing addresses easier. I'll explain the situation:
Basically I have three entities, Students, Addresses, StudentsAddresses. Students have many addresses, since they can change alot and rapidly (especially foster kids / homeless kids). So ill be changing them a lot. However based on each address I Want a user to attach (enter it via the UI) the price it would cost to pick that student up via bus service. So my initial thought was, ok, let me attach a column onto my join table 'StudentsAddresses' called 'dailyPrice', this is the cost for each day a student is picked up, and another column called 'adjustmentPrice', which is an additional cost for whatever special circumstance that requires extra work to pick up a student. Is my thinking going to cause me problems the more students I have in the future? Will it get harder to manage?
Another option I thought about, was creating a new Table called Pricing. And another join-type table called StudentsAddressesPricing
StudentsAddressPricing has three columns,
studentId
addressId
pricingId
each field connects the three together. So if i ever needed Students, with their addresses, and the pricing, i would query this table and eager load Students, Addresses, and Pricing. Does this approach seem much cleaner since i've abstracted pricing out a bit? Trying to determine the best way to go about this without having to many headaches in the future incase I wan't to add more attributes pricing related, or address related.
And then I even thought, hey what if pricing is just different for one day? How would I even consider that. Would I need a different kind of entity to handle that? Is doing alot of joins going to hurt my application performance?
Just looking for some insight on how others would do it, and criticism on why im off the ball.
The main question you should ask yourself is: on what does the price depend?
If the price is determined by the address, you might as well add it to addresses. If the price also depends on the student (e.g., depending on their financial situation), it would make sense to put it into studentsaddresses.
In other words: The table where the price is stored should have foreign keys to everything outside the table that determines the price. If that makes it fit into one of the existing tables, keep it there.
I looked over some of the other answers here and they did not answer the question I have.
How would I go about this problem. If an invoice is created with the following database schema:
id
customer_id
invoice_date
status
the invoice is created, paid etc. If the customer information changes, the invoice information will change since its a FK. How would I create the invoice table to record customers information at that give moment in time, so if the customer change their address in the future for example the past invoices will stay the same with the previous address.
Just wanted to see if it makes sense to copy customer information into the invoice table with their address etc. but then it will adhere to normalizing the database.
Please let me know what your thoughts are in regards to this challenge. Invoices in one example, this can also apply to Purchase orders that were created in the past should have definite information that was recorded in the past no matter what has changed now.
There are different considerations for an order management system or a reporting system.
Within an application, data duplication may prove cumbersome at volume. Will prove cumbersome at high enough volume. So you'll want to be as normalized as possible in that environment.
For reporting and history, though, it would be preferable (maybe mandatory depending on your industry and locale) to have the address info for each invoice.
It would be better to have an address table that joins to your customer table. The addresses would each have their own id field, and then you could just reference that id in the invoice table, too. Probably both the billing address and the shipping address if they're both in play in your business model.
If you don't have the flexibility to introduce a stand alone address table, then copying the address information over to the invoice table becomes a necessary evil. But dead useful information to have.
I'm trying to setup a database schema for a company which works as a middle man (selling items collected from vendors to buyers).
Both of these entities (vendors and buyers) can be generalized as a client - they both have very similar attributes (name, email, password, address, etc...) and multiple other entities depend on this. For example invoices are generated for buyers and settlements (different type of paperwork) are generated for vendors. The thing is that one person (a client) can by buyer and vendor in the same time.
The dilema I'm having is how to setup the database structure for this?
At the moment I'm more in favor of having both vendors and buyers in one table and distinguish between them using something like roles column. Thanks to this approach I would avoid the data redundancy and I could still create views to easily separate vendors from buyers to the outside world.
Am I thinking about this correctly? How would you typically solve this situation? Would it be better to use two separate tables?
Thank you for your advice and experiences :)
If you know the usecases, think about, what could be a rough solution. But that is quite dangerous, at the end sometimes the ingenious datamodel becomes too complicated to understand and maintain.
How important is it to decide now, will your datamodel or organization be fit for a later change?. Can you be agile? Then implement, what is best for your current usecases, nothing more!
btw.
if there is a 1 to 2 relationsship between person and role, you should factor out the role, not duplicate the data, or create two attributes, isBuyer and isVendor, or put in these attributes references to the buyer- and vendor-specific data, if there is any.
So my issue for the past week has been how to structure my inventory system. I am trying to write a database to track every small detail about a variety of different IT related items including but not limited to..... Windows based laptops from every manufacturer, apple laptops, windows based desktops, apple desktops, Iphones, android phones, blackberry phones, printer equipment, server equipment, so on and so forth. I will also be adding car, motorcycles, and many other random items, I have a business where i buy and sell just about anything i can make money on. I need the database for inventory/asset management , sales tracking, and customer/business relations. I pull inventory in from many different sources for varying prices. What i am trying to do is bring a lot in, assigne it a lot number, test and inventory each item tracking LotNumber, Tester.
Table Invester // I sometimes have lots that other businesses have a stake in
InvesterID
BusinessName
Table Supplier // I will add in other things like phone number, address, and other stuff latter.
SupplierID
SupplierName
Table PurchaseLot
LotID
Date
Cost
Invester_InvesterID
Supplier_SupplierID
Table Tester
TesterID
Name // Later once i create a logon it will be employeeID
Table Monitor
MonitorID
Size
Grade
Model
Manufacturer
Tester_TesterID
PurchaseLot_PurchaseLotID
ETC
//Trigger on insert add MonitorID to Inventory to create a uniform inventory numbering system.
Table Laptop
LaptopID
Manufacturer
Model
Serial
Tester_TesterID
PurchaseLot_PurchaseLotID
//Trigger on insert add LaptopID to Inventory to create a uniform inventory numbering system.
Table Inventory
InventoryID
Monitor_MonitorID
Laptop_LaptopID
That is my basic table structure. The real question is is this the best way to do this or will this create a bigger headache? what i plan on doing i creating a table for different kinds of items, tablets, phones, laptops, desktops, etc. later on i may have to break different items into parts for resale because not all items will be fixable, thus having to create a parts Table. i will also track where in the warehouse an item is by assigning it a shelf number, latter this will have to expand to track multiple warehouses, owner, business (within a year) If there is an easier way please let me know. I want to make this as simple and straight forward as possible so it will be easy to write multiple php scripts to handle different tasks including putting up on a website for sale. also I am not sure how to handle multiple of the same item especially since multiple of the same laptop can be broken down into 10+ different parts that will need to be tracked. any advice and or incite would be great. Just to outline my experience in this is I am basically the copy and paste king. I have created a few databases with their php counterparts to handle customer relations. But this is the largest and most ambitious project as of yet and really only out of necessity for the proper sustainable growth of my business.
As #Jim Garrison implied, you are asking a very broad question here, so I cannot provide an answer, only some pointers to consider. The approach in using one table for each type of product, and then a table to bring all your types of product together is inherently fragile, and is unlikely to scale. Reasons for this include:
Does every item of inventory have a monitor and a keyboard?
What do you expect to do when you add a tablet to your inventory?
Do you expect the inventory table to expand over time, and to include many nulls as it does expand?
I would suggest that there need to be at least the following three tables included in your application
Item - containing information that is common to ALL items - and may well include investor and supplier IDs.
Item type - containing information that this item is (eg) a tablet; and specific information about tablets in general.
Component - Top level item plus identification of (eg) the OTG cable that came with the tablet. This table would need to represent a hierarchy of variable and unknown depth.
It is possible that in addition to the component table you need a similar hierarchy "associated_with".
This leads to a more complicated approach than you propose, but I do not believe you can provide the capabilities you require AND keep it simple.
HTH.
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.