I’m doing a database for a products list and I’m having some difficulty visualizing the structure. The main list is divided by systems, which are then divided by usage; all of these with their corresponding images. Additionally, I have a tabbed menu, specific to each system, that shows description, specifications, downloads and manuals. Like this:
System 01 – Menu 01 – All images
- Usage 01 -> images (sub-set)
- Usage 02 -> images (sub-set)
- Usage 03 -> images (sub-set)
System 02 – Menu 02 – All images
- Usage 01 -> images (sub-set)
- Usage 02 -> images (sub-set)
- Usage 03 -> images (sub-set)
System 03 – Menu 03 – All images
- Usage 01 -> images (sub-set)
- Usage 02 -> images (sub-set)
- Usage 03 -> images (sub-set)
I have the html template. The idea is that by selecting a product by system, the tabbed menu, a main image and thumbnail images display (I’m using Ajax for this). But is also possible to select a product by usage, and this can fall under two or more systems.
My problem is the structure. I have a general idea but just started working with databases so it might not be the best for this project. I thought of 3 tables:
- 1st table has all systems with tabbed menus and images;
- 2nd table has usages, and corresponding system IDs and images IDs;
- 3rd table would have to relate the previous ones, but I’m not sure how, or if it’s the right approach.
A different but related question would be about the best practice when storing images. I believe storing the path is more efficient and I’ve read people recommending either type ‘varchar’ or ‘blob’ for this, is there any restriction to use one or the other?
I know it’s a -beginner’s- generic question but I hope someone can shed some light. Thanks.
I would get out a sheet of paper and start drawing circles to represent your “entities” and lines to represent your relations. Generally speaking, you start with an Entity (something to model) and start listing fields you want to remember about it. Each field should be directly related to that entity and not exist by itself, like color, size, etc.
When you start to have multiple choices for the same fields, you may need a separate table. If you want to store a single list of these choices, you may need two tables, like a color table, and a many to many table only referencing the primary keys of both tables. This way you can pick a color RED and see all the products that are RED, or pick a product and see all of it’s related colors.
Primary keys are the main way of accessing a record, should always be unique, and usually dictates the sort order of how the table’s records are stored on disk.
Foreign keys are fields in tables that usually refer to primary keys of other tables.
A good start is looking at database normalization.