Relational database structure logic configuration

Question

I'm going to develop a relational database on server side with MySql RDBMS.

Since this database will contain many informations and there will be many simultaneous queries, i'd like to setup an optimized structure to avoid slow processes when retrieving datas.

My main table called "account" will contain information about name, surname ecc.. of users:

 TABLE 'account'

 ID - NAME - SURNAME - AGE

 Primary key -> 'ID'

The second table will be called "file" and has an id (foreign key referring account.id), a filename and a column called 'count':

 TABLE 'file'

 ID - FILENAME - COUNT

 Primary key -> {'ID','FILENAME'}

 Foreign key -> 'ID' -> 'account.ID'

My last table is called 'visit' and has this structure:

 TABLE 'visit'

 ID - FILENAME - OPTION

 Primary key -> {'ID','FILENAME'}

 Foreign key -> 'ID' -> 'account.ID'
 Foreign key -> 'FILENAME' -> 'file.FILENAME'

While first table won't contain many rows, second table could have something like thousands of rows and third table hundreds of thousands rows.

Maybe i'm wrong (i'm not an expert about db system management and optimization :D), but if i make simultaneous queries on 'visit' table with so many rows and joined with other tables, the process could become slow.

Is this structure good or can be improved?

Last question, can i update automatically 'file' -> 'count' column with the count of rows contained in 'visit' where 'file.filename' = 'visit.filename' when 'visit' table is updated ?

Or it's better to make a query like 'SELECT count(*) from ecc..' every time?

Hope i explained myself, thanks.

Answer 1

According to what you comment, your idea sounds good, but everything depends on the business, ie business logic — if you are considering make daily reports, weeks, monthly visits; if the business is interested in knowing the history of visits in the last 10, 20 or 30 years. Depending on that, you could create from time to time historical data tables with a period of time (it may be a year).

As you can see there are many ways, and you should also take into account the part of business the technical side, such as disk space, backups, etc, how important is to keep historical data and for how long.

EDIT :

Regarding your second question, yes you can, if you implement a trigger. But you can check this nice link to ensure if you're making a good decision to create a trigger. (I don't like copy and paste so I prefer share the link, if I'm breaking the rules , please do me know)

https://softwareengineering.stackexchange.com/questions/123074/sql-triggers-and-when-or-when-not-to-use-them

UPDATE V.2.0:

Suggestions:

1. Try to not use restricted names on your column names (like count,option), I don't exactly if there are restricted on mysql but in SQL SERVER yes , so for portability is better not use names like this.

2. Like Jonathan Leffler says, its not a good idea save the age, you can prefer save a birthdate.