Ignore:
Timestamp:
12/09/11 12:45:34 (13 years ago)
Author:
jkraaijeveld
Message:

Wrote more future work for documentation

File:
1 edited

Legend:

Unmodified
Added
Removed
  • Doc/Backend/DBInterface.tex

    r179 r180  
    220220                does not exist.
    221221
     222        \subsection{Optimize queries}
     223                Queries as they are at the moment can be a bottleneck in performance if the sets get really large. This is because of a
     224                couple of things. For one, there are duplicate queries being executed: if a Session object is retrieved, it also retrieves
     225                all the corresponding AnswerSets, which in turn retrieves the corresponding Questions. However, the Session also
     226                retrieves the Surveys related to it, which afterwards also retrieve the same questions. There has been no benchmarking
     227                of performance so I have no clue at what size of the .rdf files this will become an issue.
     228
     229                I have a gut feeling that the SPARQL queries can be optimized some as well. This is regarding entries with zero or more
     230                elements of a specific type, like Survey. Now, there is a second query for getting all the IDs for all the questions, but
     231                there must be a way to introduce this into the first query without getting the exponential growth of the RDF 'different
     232                tree options'.
     233
     234
    222235\appendix
    223236\pagebreak
Note: See TracChangeset for help on using the changeset viewer.