It depends on what you want to do with the cars table. If each user can only have one car, then you have a one-to-one relationship. If each user can have multiple cars, then you have a one-to-many relationship. Its unlikely that youll have a car that belongs to more than one person so you wont be dealing with many-to-many relationships and you won't need a pivot table (car_user). Check out the Laravel documentation to see how to set up these relationships. http://laravel.com/docs/5.0/eloquent#relationships

For the photos, you should put your photos in a photos folder in the public directory of your app. In the database, store the path/file name and then send that to your view where it can be displayed properly.

zachleigh said:

It depends on what you want to do with the cars table. If each user can only have one car, then you have a one-to-one relationship. If each user can have multiple cars, then you have a one-to-many relationship. Its unlikely that youll have a car that belongs to more than one person so you wont be dealing with many-to-many relationships and you won't need a pivot table (car_user). Check out the Laravel documentation to see how to set up these relationships. http://laravel.com/docs/5.0/eloquent#relationships

For the photos, you should put your photos in a photos folder in the public directory of your app. In the database, store the path/file name and then send that to your view where it can be displayed properly.

Thanks. Each user can have multiple cars and the car have a lot of fields (details) Should be good create a cars table and a cars_details table? Inside of car table i could put the user_id and 2 more fields like prize, mark and model. What do you think?

And about the photos. I understand everything, but how i save the path in the databse? Create a table such car_photos with id id_car and path?

Personally, I would just have one car table with all the car details. For each car, you could have fields like: -id -make -model -year -color -price -photo

Having more than one table for each car just means that youll have to do more database queries which will take more time and use more resources. If you want to be more specific about the cars (engine type, features, gas milage etc) you could create a seperate table for each car model. For example, Ford Explorer, Toyota Prius etc.. This makes sense because all Ford Explorers/Prisues etc. will share common traits so putting these traits in a seperate database will mean that you wont have to enter them into the database more than once. Each individual Ford Explorer could then belong to the Ford Explorer category and could reference all those traits.

I have around 30 details and 5 common fields. Around 90% of the times, i only would need to see the common fields. I dont know what is better if 1 table of 35 fields or 2 tables(5/30). I dont know about optimizing, so what is better, make a request of the "common fields" or just split tables. (I dont know if is the same a request selecting common fields than select all of a common fields table)

zachleigh said:

Personally, I would just have one car table with all the car details. For each car, you could have fields like: -id -make -model -year -color -price -photo

Having more than one table for each car just means that youll have to do more database queries which will take more time and use more resources. If you want to be more specific about the cars (engine type, features, gas milage etc) you could create a seperate table for each car model. For example, Ford Explorer, Toyota Prius etc.. This makes sense because all Ford Explorers/Prisues etc. will share common traits so putting these traits in a seperate database will mean that you wont have to enter them into the database more than once. Each individual Ford Explorer could then belong to the Ford Explorer category and could reference all those traits.