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.
Related
I'm going to build an online printing store system which can be accessed by both the public (to order) and admin (process order).
This store I'm developing for has a lot of typical advertising products such as banners, name cards, rubber-stamp etc. And under these categories, there are several types of different items (based on different materials, finishing, size, quantity).
Admin can add new category, materials, types, and everything else that is required to create a new product.
To input a particular product price, will require all the details (ex: Banner, using material synthetic paper, size 2'x2', 100pcs, finishing extra 4 rings).
However, I'm stuck at trying to connect the other attributes since not every item will have the same attributes. And how to tabulate the drop-down menu for customer's order form and admin's management form (for the purpose of add, delete, edit)?
Update:
My current design of the database. Please correct me if there's a better solution.
Thanks!
ERD
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've a requirement to design a database for an ecommerce app that has vast scope of product categories ranging from pin to plane. All products have different kinds of features. For example, a mobile phone has specific features like memory, camera mega pixel, screen size etc whilst a house has land size, number of storeys and rooms, garage size etc. Such specific features go on and on as much as we've products. Whist all have some common features, there are mostly very different and specific features of all. So, it has gotten bit confusing while designing its database. I'm doing it for the first time.
My query is about database design. Here is what I'm planning to do:
Create a master table with all fields, that tells if a field is common or specific and map them with respective category of the product. All products will have "common" fields but "specific" will be shown only for one category.
table: ALL_COLUMNS
columns:
id,
name,
type(common or specific),
category(phone, car, laptop etc.)
Fetch respective fields from all_columns table while showing the fields on the front.
Store the user data in another table along with mapped fields
table: ALL_USER_DATA
columns:
id,
columnid,
value
I don't know what is the right way and how it is done with established apps and site. So, I'm looking forward if someone could tell if this is the right way of database architecture of an ecommerce app with highly comprehensive and sparse set of categories and features.
Thank you all.
There are many possible answers to this question - see the "related" questions alongside this one.
The design for your ALL_USER_DATA table is commonly known as "entity/attribute/value" (EAV). It's widely considered horrible (search SO for why) - it's theoretically flexible, but imagine finding "airplanes made by Boeing with a wingspan of at least 20 metres suitable for pilots with a new qualification" - your queries become almost unintelligible really fast.
The alternative is to create a schema that can store polymorphic data types - again, look on Stack Overflow for how that might work.
The simple answer is that the relational model is not a good fit for this - you don't want to make a schema change for each new product type your store uses, and you don't want to have hundreds of different tables/columns.
My recommendation is to store the core, common information, and all the relationships in SQL, and to store the extended information as XML or JSON. MySQL is pretty good at querying JSON, and it's a native data type.
Your data model would be something like:
Categories
---------
category_id
parent_category_id
name
Products
--------
product_id
price
valid_for_sale
added_date
extended_properties (JSON/XML)
Category_products
-----------------
category_id
product_id
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.
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.