Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo


table refs and user_data

Matt - Zee
  • Matt - Zee
    Matt - Zee


    This is pretty awesome software, and I am trying to understand its core to start tinkling with it. I am trying to understand the database structure. Looking through the database, these two tables seems to hold all the information about reference entries.

    In my case, refs has 71 rows, but user_data has 300+ rows. This is because when I first started out, I mass-imported from a .bib file, disliked something, and removed those record from the refs using DELETE (bad idea in retrospect, but there isn't any other mass deletion method). Perhaps I should have deleted corresponding entries in user_data. In refs, the primary key is "serial" in user_data there is field call "record_id", how are they different, similar, related? Is there dev documentation somewhere describing the various tables?



  • Hi MZ,

    your observation is correct, tables 'refs' and 'user_data' hold all the relevant data. Table 'refs' is for "global" data (i.e. data that's generally visible to everyone).

    Table 'user_data' holds the "user-specific" information, i.e. information that's unique to each user and that can be only viewed & queried by its owner/creator (well, there are a few exceptions to this rule such as that the 'cite_key' field can be queried by everybody via the API).

    The primary key 'serial' in table 'refs' is identical to the 'record_id' in  table 'user_data', so this is how user-specific data are matched to a record's global data.

    Unfortunately, there isn't much dev documentation. I've started to document the refbase table structure (http://www.refbase.net/index.php/MySQL_tables) but, except for (http://www.refbase.net/index.php/Table_refs), it never got finished.

    Here's a basic description of the fields in table 'user_data':

          The unique ID number of this user data entry.
          The user's unique ID number (which corresponds to the user_id number of the
          user's record entry within the "users" table).
          The unique ID number of the record this data entry is referring to (which
          corresponds to the 'serial' number of the record's entry within the "refs"
          Has the user marked this record?
          Has the user a printed copy of this record?
          Has the user selected this publication? (by that she can label publications
          that are important to her OR, if he/she's among the authors, indicate that
          this is one of the "better" publications).
          The user's personal keywords for this record.
          The user's personal notes for this record.
          If the user owns a digital copy of this record, he/she can specify its file
          name/path here.
          The user's personal groups to which this record belongs (note that this
          field contains names of *reference* groups for this user, which must not be
          confused with the *user* groups from table 'users').
          The unique citation key for this record which uniquely identifies this
          record when citing.
          Contains pointers to related records. Pointers can be serial numbers or
          partial queries, e.g.:
          - '1234; 2678; 1988; author=steffens' -> items separated by ";" will be connected by OR.
          - Pure-digit items: assumed to be record serials.
          - Dynamic items: 'field=content' syntax will be resolved to 'field RLIKE "content"'

    HTH, Matthias