How to normalize my MySQL Database

Question

I have PHP/MYSQL car rental site. In the MYSQL table i store

1. car license plates
2. car specs (like AC, brand and such)
3. price per day (30 colums), since price for 1 day is X euro per day, and for 30 days let's say is Y euro per day
4. insurance per day (this is a per car thing because it depends on the specific car history, year, brand, model and such). So since there are 30 days in a month, we have here another 30 columns, since insurance for 1 day <> insurance for 28 days let's say

Now if i put all this stuff in I will have about 70 colums. Any smarter way of doing it to avoid a performance blow? I do not control the prices and there is not a daily price or daily insurance formula.

One ideea would be to use the car plates as an index and blow it in 2 tables, one with prices (35 rows), one with insurance (35 rows). Any other?

The DB has 1000 cars or so. I get about 10.000 queries a day in the DB

Kind thanks.

Answer 1

A quick an dirty attempt below. I'd move prices and insurence costs in dedicated tables, each having a car_id and days field.

Select brand,type,ac,seats FROM cars
LEFT JOIN prices ON cars.id = prices.car_id
LEFT JOIN insurence_costs ON cars.id = insurence_costs.car_id
WHERE
    licensePlate = 'HH-OH-234'
    AND prices.days = 28
    AND insurence_costs.days = 28

Update: Added the license plates. I'd just put them in car specs. In general they are car related but may change sometime in future. If they change quite often I'd rather move them in a dedicated table too.

I would actually save the price per renting day depending on the overall renting span to the db. That way, you could do something like

SELECT price FROM prices
WHERE car_id = 123 AND days = MAX(days);

That way you could multiply the "last" price with the actual amount of renting days for any rents above 30 days. But thats up to pricing definitions.

Answer 2

To normalize a database (or more general to design a database) you have to, clearly, determine the entities that you have.

From your description, you have four entities as follows:

1. Car
2. Specification
3. Price
4. Insurance

Every entity of the above should has a table to handle its properties (columns).

After, defining the entities, the real normalization is to define the relations between the entities, either through, keys properties (columns) or through new entity (table), for example, in Many to Many relations. Lets discus the relations:

1. Car: one car should has one specification, price and insurance. ie the relation is one to one. So, cars table should has specification_id, price_id and insurance_id columns that relate it with the other three tables.

2. On the other hand the other three tables (entities: specifications, price and insurance) may have many cars so its relation to car is one to many and it is covered by defining the foreign keys in the cars table (specification_id, price_id and insurance_id)

How could it work?

Before inserting new car, you have to complete the other entities. In other words, a list of all available, specifications, prices, insurances should be found in there respectable tables (entities) and if you have got a new car that has no any defined one of them, then you have to create new entity that covers its need before inserting or creating it. ie inserting new specification and/or new price and/or new insurance that car should belong to.

Notice: this is not a law, you or other one may able to invent another entities relations. However, what I have regarded here is a general hint based on relational database design methodology