I have three table users, cars and enquiries and their design is like:
users:
id ,name, email
cars:
id,user_id,name
Enquiry:
id, car_id,description
I just want to know that should I have to keep user_id in Enquiry table or not.As I know that i can fetch user detail with reference of car_id of cars table.what is the best way to manage these kind of things.
Thanks in advance.
If you remove the user_id from Enquiry table, you have an implicit assumption in your design that the enquiry is aways created by the car owner.
Is this assumption acceptable to you?
This may be very subjective, but talking about correctness, my opinion is that you should keep the user_id because Enquiry itself is an entity and should have its own owner.
It is based on your reports but I would say, you will not require the extra user_id as everytime you would be joining all the table for detailing the user info and car info with the Enquiry taken.
Related
I have a simple site where users can bid on a product. The model looks like this:
Obviously different users can bid, so how do I draw the missing link to the 'users' table?
I'm a little confused whether to use identifying or non-identifying relationship.
Updated:
You say: "... users can bid on a product."
This suggests that there is a relationship (Bids) between Users and Products. You could name it user_bids_on_product or just bid.
I would remove the relationship between user and product (unless it means something else like the owner of a product) and unify your bids and bids_has_product into one table:
user_bids_on_product
--------------------
product_id FK to product
user_id FK to user
price
The (product_id, user_id) should not be the Primary Key for this table, as we assume a user can bid multiple times on a product.
You could add a surrogate id and make that the PK or add a bid_number column and make the compound (product_id, user_id, bid_number) the PK. You could alternatively make the (product_id, bid_number) the PK (the bid_number could mark the order of the bids per product, like an auction in this case). I think that's up to you to decide.
Identifying relationships:
Non-identifying relationships:
A User can make one Bid on a Product; a User can Bid on more than one Product; a Product can have more than one Bid; a Bid is associated with only a single Product.
I think you need to have a relationship between a User and the Bids they make. It's one-to-many.
Another question regarding your updated diagram: would a User assign a Rating to a Product, in much the same way they give a Bid? Is that worth tracking? If yes, I'd have a relationship between User and Rating.
A simple identifying relationship b/w users and bids makes sense, bids can't exist without a user.
Its a simple one to many relations, as users "has_many" bids.
I am creating a site where each registered user can store a list of contacts. It occurred to me that rather than storing the contacts in a table with user_id, contact_name, contact_email, it would be better to normalize it to prevent the same names/emails being stored multiple times. As a result, I now have 4 tables: users, names, emails and contacts where contacts contains user_id, name_id and email_id. Am I heading in the right direction, or am I complicating things needlessly?
Thanks for all the helpful responses to what I can see now is a pretty nebulous question. It may be a good idea to explain my reasoning.
In an example scenario, where there are 100 users, most of whom have joined though the recommendation of another user, there will be a large number of common email addresses shared by each users contact lists. However, johnsmith#email.com, may be known as John, J Smith, Johnny boy etc. by different users. If I understand the principles of normalization correctly (unlikely) the separation of user, contact name, and email address in to separate tables, should reduce duplicate entries significantly and make the database more efficient. In the example below, the Contacts table could contain the same email addresses multiple times.
So, to cut a long story short, is it better to have more entries than necessary in one table or several smaller tables without duplicate entries?
You're probably needlessly complicating things: I'd recommend one table for users, one for contacts and a join table to allow a many to many relationship between the two. If contacts are not shared between users it'd be acceptable to have the user id as a foreign key in the contacts table.
Hope this helps
You can do like this
1] User_info Table
User_Id | name
2] Contacts Table
Contact_Id | Contact_Name | Contact_Email
3] User_Contact Table
User_Id | Contact_Id
Can contacts have same email but distinct names, or vice-versa ? If not, i suggest two tables (users and contacts) linked by an associative table :
USERS
- userId
- userName
CONTACTS_USERS
- userId
- contactId
CONTACTS
- contactId
- contactName
- contactEmail
With foreign key constraints on userId and contactId you can achieve a robust linkage between the two tables, where each contact may be used by distinct users and where each user may have distinct contacts.
I am building a database for a web application that includes users following each other. What would be a good design? I was thinking this:
TABLE: users ROWS: user_id, name, pass, email, activated, user_level, registration_date
TABLE: relationships ROWS: relation_id, user_id, followed_id
What do you think of that?
For the user table, I guess what you have is correct. If you need to add more columns, you could simply alter that table, or add an additional table with a one to one relationship.
As for the relationships table, I think that is correct. Although i wouldn't call it followed_id. I would suggest that you could use that table for many different types of interactions, so I would call it user_id and interacter_id and the relationship_id would be a number of different types of interactions (follow, poke, etc).
I'm new to database design,
please give me advice about this.
1 When should I use a composite index?
im not sure what does index does, but
i do know we should put it when it
will be heavly loaded like for WHERE
verified = 1 and in search like
company.name = something. am i right ?
2 MySQL indexes - how many are enough?
is it just enough ?
3 Database Normalization
is it just right?
Thanks.
edit*
rules.
each users( company member or owners ) could be a member of a
company
each company have some member of users.
there are company admins ( ceo, admins) and there are company members
( inserts the products )
each company can have products.
for the number 3 i will add a bit at users_company
- 1 is for admin
- 0 is for members
Looks good, well normalised, to me at least.
I notice that each product can only belong to one company. If that's what you intended that's fine, otherwise you could have product have its own PID and have a product_company relation table, which would let more than one company sell a particular product. Depends who administers the products I guess.
I did notice that the user table is called 'users' (plural) and the others are singular ('company', 'product'). That's only a minor thing though.
The only comment I have is that you may want to consider just adding a mapping_id column to your users_company table and making CID and UID foreign keys, and add a UNIQUE constraint.
This way you can have a distinct Primary Key for records in that table which isn't dependent on the structure of your other tables or any of your business logic.
Need your help to get the list of suggested friends (who aren't friends of the current user but are friends of 2 or more of the current user's friends). The primary ordering should put people at the same school at the top, and the secondary ordering should put people with more common friends (that is, the number of people who are friends of that person and the current user) near the top.
Users:
user_id PK,
user_name
Profiles:
user_id PK,
school_name,
...
Friendships:
id PK,
user_id FK,
friend_id FK
Thank you in advance.
Joe
This is not a homework question. I am currently working on a site and my solution seems not efficient enough. That's why I need you suggestions. Thanks.
(I'm assuming HW here.)
Seems like if you queried for a list of all of your friends' friends, and checked for the friends-of-friends that weren't unique in that list, you'd be getting somewhere.