Database Design Schema I have a project which we have to make a database for a car dealership. We have to make a Salersperson be able to view the inventory, add sales people, add cars/ car details. A customer must be able to view inventory, add cars they would think about purchasing, and then purchase the car or have a salesperson purchase the car. Salesperson must have their sales saved . I feel like my design looks a bit clunky and could be broken down better in a few more tables, but I am just drawing a blank when thinking about how else to break this up. Any suggestions?
I don't really understand what you mean by &quot;looks a bit clunky and could be broken down better in a few more tables&quot;; something looking &quot;clunky&quot;, however that applies to database design, doesn't seem like a good reason to breaking things up. Unlike fighting the dark force, you probably should use logic, not your feelings.
For a suggestion, may be you could answer (to yourself) to some questions about your model, such as:
Why do you think that &quot;car make/model&quot; is a separate entity and not simply attributes of a &quot;car&quot; entity?
Why car.car_lot varchar(255) references car_lot.lot_id (integer)?
Why for_sale_cars? What entity does that represent?
Is customer.customer_cars varchar(255) intended to store a list of cars? That would violate 1NF. And how is that then different from saved_cars?
Why do you think you need an extra key in saved_cars?
Which of the requirements you have listed cannot be addressed by your model? Are there any requirements that are missing?