On Wed, Jun 07, 2006 at 07:10:49PM +0200, Davide Alberani wrote:
...
> [retrieving information about a movie]
> An important query is the one used to retrieve a row about a
> movie in the Title (or AkaTitle) table, but I assume that
> a Title.get(movieID) is _always_ fast enough. :-)
Very likely the DBMS automatically creates an index on the primary key, yes.
...
> [retrieving information about a person]
> As usual, Name.get(personID) is already optimized enough. :-)
>
> The CastInfo table is searched for the personID:
> CastInfo.select(CastInfo.q.personID == personID)
>
> The same is done with the PersonInfo and AkaName tables.
Perhaps the AkaName table is missing a:
DatabaseIndex('person', name='idx_person)
I have some questions:
[AkaName]:
AFAIK most of the searches are done using the phonetic codes. Is it
necessary to have an index on "name" and "imdbIndex" columns?
[AkaTitle]:
More or less the same as AkaName. I'd say "episodeOfID" is OK. But the rest?
[Name]:
Suspicious about utility of indexes on 'name' and 'imdbIndex'
[Title]
Suspicious about utility of indexes on 'title', 'imdbIndex', 'kind',
'productionYear'
As I've said before I'd suggest to avoid multi-column indexes, because they
may not be as widely supported as single-column ones. I can fix this in the
CVS once we agree on indexes definition.
--
Giuseppe "Cowo" Corbelli ~\/~ My software: http://cowo.yoda2000.net
-<! *Real* programmers use cat > a.out! No way, /real/ ones
use zcat > a.out 'cause you can type faster that way. !>-
-- from a Slashdot discussion
_______________________________________________
Imdbpy-devel mailing list
Imdbpy-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/imdbpy-devel
