This data model will result in very large link and term tables. The performance of the database is crucial, especially on queries. There are essentially two types of SQL query demanded by the model, selects involving normal joins, and nested selects. Although we have not tested all performance ramifications, we suspect that nested selects can cause performance problems on some SQL databases. We are still testing to determine how much performance degrades with nested selects. (see Ganski and Wong (1987) and Won (1982)).

An example of normal join to find all the diary records for person X in role of victim

Query 1

Select diary.start_date, diary.end_date, diary.diary_verb,
diary.diary_text
from name, link, diary
where link.diary_id = diary.diary_id
and link.id = name.name_id
and link.table_ptr = 'name'
and link.role = 'victim'
and name.name_id =X

Example of nested select: Find all the people cited as perpetrators in EVENT Y

Query 2

Select name.fullname
from name,link
where link.entity_id = name.name_id
and link.table_ptr = 'name'
and link.role = 'perpetrator'
and link.diary_id =
(select link.diary_id
from link 
where link.entity_id = Y
and link.table_ptr = 'event')

It would be possible to specify a join rather than a nested select by aliasing the link table, and joining it to itself:

Query 3

Select distinct name.fullname
from name, link link1, link link2
where link1.id = name.name_id
and link1.table_ptr = 'name'
and link1.role = 'perpetrator'
and link1.diary_id = link2.diary_id
and link2.entity_id = Y
and link2.table_ptr = 'event'

However this would not necessarily improve performance as the 'distinct' keyword tends also to reduce performance. It is necessary to specify, 'distinct', as otherwise the query will return duplicate rows when a perpetrator is linked to the same event more than once.