The question doesn't do the problem justice, so let me try and explain. I'm reorganizing a database which has (amongst other things) 20 fields with tools to be used for a job. Not every job needs 20 tools, some require 1 or 2 or 3.
I was thinking I could grab the info from the 20 existing fields and plop them into a table called tbl_Tools with a single tools field and a key. Then, in the main table remove the 20 fields and add one single field with a reference to the key of tbl_Tools and condense the info of the 20 fields into a single string variable where each tool is separated by a comma (this only has to be done because the location of each tool is important to save). Figure below has a basic explanation.
It this optimal or is there a better way of doing this I'm not figuring out? I'd love to hear your feedback.
Thanks in advance, Rafael.
(Also not sure which tags to use for this)
Book answer to your question would be to use two tables storing separate entries (TBL_INFO and TBL_TOOLS) and third table which would store connections between them using two foreign keys (TBL_INFO_TOOLS_REL), just like this.
This way you're minimizing amount of empty columns but also keep clean database without columns that store multiple keys glued together using separators. This allows much simpler management of tools required for certain jobs.
Probably what you want is many to many relationship (this will consist of 3 tables see the image below)
Comma Separated solution would work if your application deals with the logic of splitting and joining tool IDs but this way you lose the ability to query for tool specific data i.e. "which toll was used the most" or "who used tool_3" etc.
I'm making an application for collectors where users will upload lists of stuff they want to collect
For example, someone wants to collect flowers and uploads a list of some flowers he'd like to collect which may look something like this:
Rose, Chrystanthemums, Narcissus
Then they may choose which ones they have and work towards their goal.
Of course, users would be able to upload all kinds of different lists which brings up the question on how should this data be saved and accessed.
An approach i thought of would be to dynamically create a table everytime a user uploads a list, but upon looking it up it's a practice that's generally frowned upon and people usually suggested other alternatives. However i can't quite think of an alternative for my situation.
In this question on DBA stack exchange the reply was that there can be a few rare cases where this is a good practice.
Is my case one of those?
How should i go about designing it?
Also i understand that i'm not providing many details about this problem and i'm not asking for you to design this for me. I'm just asking for some general guidelines or a direction to move to.
Thank you in advance!
Hello #aMimikyu for an example as simple as the one you mention dynamic tables won't be a help, on the contrary migth degrade the performance of your software, as you can use a single table for storing the users list and then use a column of the table to identify the type of list the user is saving. But in my opinion, there is a case when the dynamic tables migth be usefull: if the entities (abstract representation of data) cannot be managed by the same class (model) on every different type of input. In this case the models and tables can be created on the fly.
Database Design:
This is my simple database design, what would I like to know is which solution is better among the two. Solution 1 have each table for each dimension like 1366x768 dimension table and stores the path for specific dimension, and in Solution 2 there is a table which stores a generic path (which contains like sub folders) and the dimensions table stores the dimensions and to retrieve the images concatenation can be used. So which you think is better among the two, like easy to implement, less complicated..something like that..?
Using Solution 1, if new resolutions appear, you'd be adding a new tables. Using Solution 2, you'd be adding new records.
It may not be quite so easy to design and implement Solution 2, but it will result in a simpler database with fewer tables
Without knowing all the details (what do you normally update, which data changes, what may be extended in the future?) I would go for solution 2.
Solution 1 seems overcomplicated - there's a lot of tables to manage. I can't see a problem with basic operations you might do in solution 2 and simplicity and clarity of design is always a plus.
Having many records in one table is not normally a problem - database systems are designed to handle that very well.
Hi I am trying to design a database for an e-commerce website but I can't seem to find a way to do this right, this is what I have so far:
The problem appears at the products.I have 66 types of products most of them having different fields.I have to id's but both of them don't seem very practical:
OPTION A:
At first I thought I to make a table for each product type, but that would result in 66 tables which is not very easy to maintain. I already started to do that I created the Product_Notebook and Product_NotebookBag tables. And then I stopped and thought about it a bit and this solution is not very good.
OPTION B
After thinking about it a bit more I came up with option B which is storing the data into a separate field called description. For example:
"Color : Red & Compatibility : 15.6 & CPU : Intel"
In this approach I could take the string and manipulate it after retrieving it from the database.
I know this approach is also not a very good idea, that's why I am asking for a more practical approach.
See my answer to this question here on Stack Overflow. For your situation I recommend using Entity Attribute Value (EAV).
As I explain in the linked answer, EAV is to be avoided almost all of the time for many good reasons. However, tracking product attributes for an online catalog is one application where the problems with EAV are minimal and the benefits are extensive.
Simply create a ProductProperties table and put all the possible fields there. (You can actually just add more fields to your Products table)
Then, when you list your products, just use the fields you need.
Surely, there are many fields in common as well.
By the way, if you're thinking of storing the data in array (option B?) you'll regret it later. You won't be able to easily sort your table that way.
Also, that option will make it hard to find a particular item by a specific characteristic.
Okay, so I'm making a table right now for "Box Items".
Now, a Box Item, depending on what it's being used for/the status of the item, may end up being related to a "Shipping" box or a "Returns" box.
A Box Item may be defective:if it is, a flag will be set in the Box Item's row (IsDefective), and the Box Item will be put in a "Returns" box (with other items to be returned to that vendor). Otherwise, the Box Item will eventually be put into a "Shipping" box (with other items to be shipped). (Note that Shipping and Returns boxes have their own tables: there's not one common table for all boxes... though maybe I should consider doing that if possible as a third possibility?)
Maybe I'm just not thinking clearly today, but I started questioning what should be done in this situation.
My gut tells me that I should have a separate field for each possible relation, even if only one of the relations can happen at any given time, which would make the schema for Box Items look like:
BoxItemID
Description
IsDefective
ShippingBoxID
ReturnBoxID
etc...
This would make the relations clear, but it seems wasteful (since only one of the relations will be used at any time). So then I thought I could have just one field for the BoxID, and determine which BoxID it's referring to (a Shipping or a Returns Box ID) based on the IsDefective field:
BoxItemID
Description
IsDefective
BoxID
etc...
This seems less wasteful, but doesn't sit right with me. The relation isn't obvious.
So, I put it to you, database gurus of Stackoverflow. What would you do in this situation?
EDIT: Thank you everyone for your input! It's given me a lot to think about. For one, I'm going to use an ORM next time I start a project like this. =) For two, since I'm not right now, I'll bite the four bytes and use two fields.
Thanks everyone again!
I'm with Psychotic Venom and mattlant.
Going the polymorphic route (having to figure out which table your foreign key points to based on the contents of another field) is going to be a pain. Coding the constraints for that maybe tough (I'm not sure most databases would support that natively, I think you'd have to use a trigger).
Do items ever move between the tables? Sticking with two tables with identical definitions where one is for returns and one is for shipping may be the easiest route. If you want to stick with the definition you first proposed (with the two separate fields) is perfectly reasonable.
"Premature optimization is the root of all evil" and all that. While it seems wasteful, remember what you're storing. Since they are IDs they are probably just integers, maybe 4 bytes. Wasting four bytes per record is basically nothing. In fact, due to padding to put things on even addresses or other such things it may be "free" to put that extra field in there. It all depends on the DB design.
Unless you have a very good reason to go the polymorphic route (like you're on an embedded system with little memory or you have to replicate across some really slow 9600bps link) it probably won't be worth the headaches you can end up with. Having to write all those special cases into your queries can get annoying.
Quick example: doing a join between two tables where if you want to join is based on if the isDefective flag is set is going to be a pain. Being able to just use one of the two columns alone is probably enough of a hassle you may save, at least for me.
I would consider making a single table for the boxes and the box type be a column of the box table. This would simplify the relationships and make it easy to still query for box type. So the box item only has one foreign key to the boxId.
I'd use what Hibernate calls Table-per-subclass, so my DB would wind up with 3 tables for Boxes: Box, ShippingBox, and ReturnBox. The FK in BoxItem would point to Box.
What you're talking about is polymorphic relations. A single ID that can reference multiple other tables. There are several frameworks that support this, however, it is (potentially) bad for database integrity (that could be a whole other discussion whether or not your database or your application should maintain referential integrity).
What about this?
BoxItem:
BoxItemID, Description, IsDefective
Box:
BoxID, Description
BoxItemMap:
BoxID, BoxItemID, BoxItemType
Then you can have BoxItemType be an enumeration, or an integer where you define constants in your application as "Return" or "Shipping" as the type of box.
Agree about the polymorphic discussion above, although it has potential to be used poorly, it is still a viable solution.
Basically you have a base table called box. Then you have two other tables, shipping box and return box. Those two add any extra fields that are special to them. they are related to box with a 1:1 fk.Boz base table has the common fields of all box types.
You relate BoxItem with the box table. The way you you get the proper box type is by doing a query that joins the child box with the root box based on the key. The record that has in both the base box and the child box is of that type.
You just have to be careful like mentioned that when you create a box type that it is done correctly. BUt thats what testing is for. The code to add them only needs ot written once. Or use an ORM.
Almost all ORM's support this strategy.
I'd go with just a single BoxItems table with IsDefective, ShippingBoxID, the shipping-box-related fields, ReturnBoxID and the return-box-related fields. Some fields will always be NULL for each record.
This is a very simple and self-evident design that the next developer is unlikely to be confused by. In theory this design is inefficient because of the guaranteed empty fields for each row. In practice, databases tend to have a minimum required storage size for each row anyway, so (unless the number of fields is huge) this design is as efficient as possible anyway, and much easier to code to.
I'd probably go with:
BoxTable:
box_id, box_descrip, box_status_id ...
1, Lovely Box, 1
2, Borked box, 2
3, Ugly Box, 3
4, Flammable Box, 4
BoxStatus:
box_status_id, box_status_name, box_type_id, ....
1,Shippable, 1
2,Return, 2
3,Ugly, 2
4,Dangerous,3
BoxType:
box_type_id, box_type_name, ...
1, Shipping box, ...
2, Return box, ....
3, Hazmat box, ...
That way the Box Status defines the box type, and it's flexible if you need to expand into a few more status levels or box types later on.