Subject | Re: [firebird-support] Reading unnecessary records |
---|---|
Author | |
Post date | 2014-04-05T10:18:12Z |
Please, let me explain it better:
I cannot use INNER JOIN since many codification may be NULL. For example, a person could not have a hobby, or the the job codification could be NULL because he/she is a child. So, I need to use LEFT JOINs.
This view, PersonView, is exposed to database users for their own consults.
So, users using an assistant or SQL, they can create consults like:
SELECT PersonName FROM PersonView WHERE BirthDate='2011/1/1'
As I said, in theory the optimizer could know codification tables linked to PersonTable (City, Job, Hobby, ...) use primary keys (or unique) and therefore only scan PersonTable because in the above query, codification tables do not need to be involved.
So, if I have 10 records in PersonTable, it would be 10 records read. The reality is that now Firebird reads ALL codification tables, event it would not be necessary, taking minutes when a optimized SQL query like
SELECT PersonName FROM PersonTable WHERE BirthDate='2011/1/1' takes seconds
For example, in a table with 10 millions of people, 20 codification tables, it means 210 millions of reads instead of 10 millions.
The solution that some users of this forum are using, as they say, is to create "on-the-fly" the SQL statement instead of using views.
It is not easy in many cases because it implies to analyze the SQL syntax and convert it, but for now is the only solution that I have found.
I cannot use INNER JOIN since many codification may be NULL. For example, a person could not have a hobby, or the the job codification could be NULL because he/she is a child. So, I need to use LEFT JOINs.
This view, PersonView, is exposed to database users for their own consults.
So, users using an assistant or SQL, they can create consults like:
SELECT PersonName FROM PersonView WHERE BirthDate='2011/1/1'
As I said, in theory the optimizer could know codification tables linked to PersonTable (City, Job, Hobby, ...) use primary keys (or unique) and therefore only scan PersonTable because in the above query, codification tables do not need to be involved.
So, if I have 10 records in PersonTable, it would be 10 records read. The reality is that now Firebird reads ALL codification tables, event it would not be necessary, taking minutes when a optimized SQL query like
SELECT PersonName FROM PersonTable WHERE BirthDate='2011/1/1' takes seconds
For example, in a table with 10 millions of people, 20 codification tables, it means 210 millions of reads instead of 10 millions.
The solution that some users of this forum are using, as they say, is to create "on-the-fly" the SQL statement instead of using views.
It is not easy in many cases because it implies to analyze the SQL syntax and convert it, but for now is the only solution that I have found.