Im designing a simple dealership site that involves several features. Users can sign on and make posts for cars.
Posts can either be for New Cars/ Used Cars:
`new_posts` database has the following fields
- id
- title
- price_from
- price_to
- date_submitted
`used_posts` database has the following
- id
- title
- price_from
- price_to
- year_from
- year_to
- date_submitted
Notice how there is duplication of the attributes. I run into issues like this often and wanted to know what is the best way to deal with this. I have average knowledge of database normalization but i can use any help i can get.
Thanks
There are many options, but two core ideas:
Merge the tables into one and have the fields for the used car be optional.
Extract the fields which make up a vehicle and that's your base table. Then you could create other tables - truck, van, SUV, new, used - that contain fields. You'd then need bridge tables to join them back to your base vehicle table.
The first option is easy to implement, but difficult to scale. The second is more complex, but scales easier.
Personally, I'd merge the two tables. It may not impress any DBAs, but it's practical from an application perspective.
How about something like this?
posts
- id
- title
- price_from
- price_to
- year_from (nullable)
- year_to (nullable)
- date_submitted
- is_used (yes/no)
Related
This is my db design:
Portfolio:
- id
- name
- invested
- total
- ...... etc
And my second table
Investments:
- id
- portfolio_id
- amount
--- etc
so according to the logic, a each user can have only one portfolio and each portfolio can have multiple investments:
So basically "portfolio" can have multiple investments and "investments" can also have multiple Portfolio right ? (each user have one Portfolio), thus should i use many to many or one to many ?
As each user have unique profile, investments relates to their profile alone ( it cant be accessed by others ) so should i use one to many here ?
Consider a Associative Entity to bridge between the two tables instead of relying on a many-to-many relationship.
This is useful if you you need to have an investment mapped to multiple portfolios, but to answer your question, if you did it this way, each investment could be linked to more than one portfolio, which does not make any sense. While it is possible for the same stock name to be invested, this would require a separate table for the investment_options, not the same exact investment linked to a different portfolio. Your table should not ever be many-to-many.
Since you said that each user has a unique profile, the correct answer for your problem would be to use a One-To-Many relationship, linking one Portfolio to many Investments.
This is a comment that doesn't fit in the comments section.
For the relationship to be many-to-many you'll need to add an extra table that represents the relationship. For example:
Portfolio:
- id
- name
- invested
- total
Portfolio_Investment:
- portfolio_id
- investment_id
Investments:
- id
- amount
Notice the column portfolio_id is not longer present in Investments.
How to construct dynamic self referencing many-to-many relationship ?
I have a problem that i cannot overcome.
I have tables:
Types:
id
name
Products:
id
name
type_id
product_products
parent_id
child_id
Let's assume that we have several products in Product table. Some of them are:
(Name is not relevant)
CB1234 - products.type_id -> cardboard
CBB999 - products.type_id -> cardboardbox
CBP321 - products.type_id -> paper
TSH123 - products.type_id -> tshirt
FAB321 - products.type_id -> fabric
THR321 - products.type_id -> thread
Now i want to tell that product_product relationship that i have cardboardbox that is made of cardboard and paper types of products. In cardboardbox-cardboard and cardboardbox-paper relationship i want to define how much percentage of product is used (consistency) to make cardboardbox product(lets say 80/20, not relevant)
I have different cases for different products. Now i want to define relationship between tshirt-fabric and tshirt-thread but instead of consistency i want to define fabric and thread cost for this product.
Products and product parameters count is not fixed. There could be 500 different products and different relations between them. What are good practices for this problem? There are few ways that i came up with
Lots of handmade many-to-many relationship tables
Lots and lots of columns to product_product table
In both cases there are things i don't like in design, but maybe those are correct way to do that and maybe i have designed my database wrong from the start.
1) would be the way to go - not sure there would really be "lots" once you worked out everything you wanted to store
product_product_consistency
product_product_cost (could this instead be represented as product_cost, then calculated from product_product_consistency or some such?)
What is the final usage, what kind of questions do you want to ask the data?
My question might be confusing but I will edit it accordingly when I find better words. This is not a direct coding question, but more of an advice on how to approach this design problem.
In our DB model we store all products used in manufacturing (components, assemblies, material) and finished products for sale in the same table "products". Each product we sell and assemblies have their BOM saved in separate pivot table "product_boms". It's kind of like this:
Table: products
- id
- sku_number
- name
- type
- ...
Table: product_boms
- id
- product_id (FK to products table)
- child_product_id (FK to products table)
- quantity
As you see table "product_boms" defines list of child products for certain product. This is part of entire BOM for this product. Part because a child product here can have further child products defined in the "product_boms" table.
I need to create a tree view of entire BOM for certain product. This is easy to do in a code, but results in many SQL queries as I need to look for every child product if it has further children... I am now looking into the SQL and if it's possible to get this out with a single query? I know this would be possible with stored procedure, but can't use those...
Final result (BOM) for product named "product_x" would look like this:
- product_x
- component_a
- component_b
- assembly_a
- material_a
- component_c
- component_d
- assembly_b
- material_b
- component_e
- component_f
- component_g
I also have option to redefine DB model in order to save BOM more efficiently and better for getting it out of DB. Open to any suggestion.
I have a site written in cakephp with a mysql database.
Into my site I want to track the activities of every users, for example (like this site) if a user insert a product I want to put this activity into my database.
I have 2 ways:
1) One table called Activities with:
- id
- user_id
- title
- text
- type (the type of activity: comment, post edit)
2) more table differenced by activities
- table activities_comment
- table activities_post
- table activities_badges
The problem is when I go to the page activities of a user I can have different type of activities and I don't know which of this solution is better because a comment has a title and a comment, a post has only a text, a badge has an external id to its table (for example) ecc...
Help me please
I'm not familiar with CakePHP, but from purely database perspective your data model should probably look similar to this:
The symbol denotes category (aka. inheritance, subclass, subtype, generalization hierarchy etc.). Take a look at "Subtype Relationships" in ERwin Methods Guide for more info.
There are generally 3 strategies for implementing the category:
All types in single table. This requires a lot of NULLs and requires CHECKs to make sure separate subtypes are not inappropriately "intermingled".
All concrete types in separate tables (excluding the base, which is ACTIVITY in your case), which means common fields and relationships must be repeated in all child tables.
All types in separate tables (including the base). This implementation requires a little more JOINing, but is flexible and clean. It should be your default, unless there are strong reasons against it.
I have two types of job posts -- company job posts and project job posts. The following would be the input fields (on the front-end) for each:
*company*
- company name
- company location
- company description
*project*
- project name
- project location
- project description
- project type
What would be best database design for this -- one table, keeping all fields separate -
`job_post`
- company_name
- company_location
- company_description
- project_name
- project_description
- project_type
- project_location
One table combining the fields -
`job_post`
- name
- location
- description
- project_type
- is_company (i.e., whether a company (True) or project (False)
Or two tables, or something else? Why would that way be preferable over the other ways?
Depending on a lot of factors including the maximum size of this job, I would normalize the data even further than 2 separate tables, perhaps having a company name table, etc... as joining multiple tables results in much faster queries than one long never ending table full of all of your information. What if you want to add more fields to projects but not companies?
In short, I would definitely use multiple tables.
You have identified 3 major objects in your OP; the job, the project, and the company. Each of these objects will have their own attributes, none of which will are associated to the other objects, so I would recommend something akin to (demonstrative only):
job
id
name
company
id
name
project
id
name
link_job_company_project
job_id
company_id
project_id
This type of schema will allow you to add object specific attributes without affecting the other objects, yet combine them all together via the linking table into a 'job post'.
This surely got to do with volume of data stored in the table . In an abstract view one table looks pretty simple . But as Ryan says what if requirements change tomorrow and more columns to be added for one type either company or project. If you are with the prediction that large amount of data top be stored in the table in future even I will prefer 2 tables which will avoid unnecessary filtering of large amount of data which is a performance overhead.