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
Related
I am currently in the planning phases of developing a multi-user shopping list application for mobile devices. In a nutshell, it will allow a registered user to create shopping list categories and then add individual items to one of these categories. The users' sets of categories and the items underneath will make up their "list." The user will be able to share their list other authorized users. All these users and the list creator will be able to edit/update these lists.
I'm not very familiar with database design although I feel relatively comfortable with mySQL and its syntax from limited use in past projects and web development. From the tutorials I've read, it is important to minimize redundant data, and in order to do so, and also leverage some of the power of relational database systems, I must use foreign keys and reference table(s).
This is what I've got so far, but now I'm stuck:
Essentially my main question is the "list" table done correctly? The way I am seeing this work is that as a user attempts to add an "item", we first to make sure some other user hasn't already created an "item" with the same name; this is to prevent duplicate item text from being stored in the database. If that item name already exists, just toss back the item_id to client program. The same process should occur when a user attempts to create a category. This idea came from my (very) basic understanding of trying to eliminate duplicate objects. If either of these objects don't exist, then they get created in their respective tables.
So now I would add the information to the actual list table. The user_id references which user owns the list, category_id points to a category in the category table and item_id points to an item in the item table. "checked" simply represents whether the item has been checked off the list, but not yet removed.
Is this a tenable design, or should I just start over from scratch? If so, can someone give me some clues as to a better design?
I’m currently developing an Application for Win, Linux Mac. The Purpose of the Application is that multiple users are able create Projects based on a single Article. Every Article has up to 15 different Fields/Options (could also be more in future). The Fields of the Article should be changeable so I should be able to add, edit or remove them.
Fields I want to store:
Numbers
Texts (mostly options [1 Word], sometimes Comments [some sentences])
Path/Links to Files
What I want to do with the dB:
load all projects of a user at login
add, edit, remove, delete single projects
set a lock on projects (because multiple people are operating one user-account at the same time and therefore they may not be allowed to edit a project at the same time so if one starts editing it should be locked until he's saving, channelling or time-out)
What is the best way to manage this kind of Data?
Should I create a Table for each user and only make a ID Column and one where all the Values of the all the fields (who are merged to one big string)?
Should I create Tables for every Project and make Columns for every Field/Option and also one for the user / owner?
Or are there any other possibility’s?
If you don't know what you are going to store, then I doubt whether a relational database is the best option for you. Maybe a document store/noSQL database is a better decision, because you can just store documents (usually in the form of Json objects) that can have all kinds of additional fields.
A couple of such databases to look at are MongoDB, Cassandra, ElasticSearch, but you can find a big list on Wikipedia.
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 working on the data model for a relational database where I have to store User Information as well as User's profile such as Education Level, personal interests, hobbies, and etc. Similar to what most of the social networking sites have or any other systems that allow you to build a profile.
I cannot decide if it would be better to store all this information in one Users table, or break it into 2 tables.
If I would break it into two tables I would have Users table that would just store UserID, Name, e-mail, DOB, gender.
UserProfiles would store the rest of the stuff pertaining to a profile, sharing the same UserID with Users table
If there are multiple profiles of a single user means one to many relation then i would recommend you to create 2 tables one is user and other is user-profile.
If one user have only one profile then your should create only one table with both attributes on User as well as profile.
Go for the more modular design, this will allow for more flexibility and control. The only time I would recommend keeping the data in a single table is if you plan to query the same data frequently.
There is a great article here which goes into depth as to why joins are expensive. You should ultimately base your decision off the information provided in the link, however as I mentioned before if you plan to query the two tables together frequently then keep the data in a single table.
I think,in order to decide which data model to chose, just look at some of the similar requirement Datamodels, which are presented in this Datamodel Library.
Specific to your User-profiles Datamodel Requirement, this link may be useful.
Hope those links will be useful. OR I got this Data model image depicting facebook type data model:
I'm writing a CMS for various forms and such, and I find I'm creating a lot of drop-downs. I don't really feel like mucking up my database with tons of random key/string value tables for simple drop-downs with 2-4 options that change very infrequently. What do you do to manage this in a responsible way?
This is language-agnostic, but I'm working in Rails, if anyone has specific advice.
We put everything into a single LookUp table in the database, with a column that mapped to an enum that described which lookup it was for (title, country, etc.).
This enabled us to add the flexibility of an "Other, please specify" option in lookup dropdowns. We made a control that encapsulated this, with a property to turn this behaviour on or off on a case-by-case basis.
If the end user picked "Other, please specify", a textbox would appear for them to enter their own value. This would be added to the lookup table, but flagged as an ad hoc item.
The table contained a flag denoting the status of each lookup value: Active, Inactive, AdHoc. Only Active ones would appear in the dropdown; AdHoc ones were those created via the "Other, please specify" option.
An admin page showed the frequency of usage of the AdHoc values, allowing the administrators of the site to promote common popular values into general usage (i.e. changing their Status flag to Active).
This may well be overkill for your app, but it worked really well for ours: the app was basically almost entirely CRUD operations on very business-specific data. We had dozens of lookups throughout the site that the customer wanted to be able to maintain themselves. This gave them total flexibility with no intervention from us.
You cold have one single dropdown table with an extra column to say what the drop down is for... limit the results with a where clause...
At my current position, we implemented a LookupCode table that contains a CodeGroup,Code, and Meaning column, as well as some others (like active). That way you have a single table that contains all of your lookup values are in a single location and you can do some quick lookups to bind to your dropdown lists.