Schema Information

users

The first table that is created is users. It is very simple, storing only a username, a service, and a code, user_id. Everyone who sends or receives a message will have an entry in users.

user_display_name

The user_display_name table is quite simple. It has a user_id field, which references users.user_id, a text field (display_name) and a date (effdate). This table is used for storing Aliases and Display Names. It stores them by date to get the most clear picture of someone whose display name/alias changes often.

As an example, let's say I'm talking to my friend Colin (user_id 100) on MSN. He has recently changed his MSN name to Colin Rocks! He's so cool! He's so good at everything! When he IMs me at 6:15, a row is inserted into user_display_name with his name and the date (6:15). We talk for a bit. Since this name is annoying, I set his alias to Colin at 6:30. Nothing changes in the database, since I haven't IMed him yet. At 6:45, I IM him. User_display_name now has a row with the following values: Colin / 6:45.

So now, doing a select on user_display_name, this is what I see:

select * from user_display_name where user_id = 100;
 user_id  | display_name  | effdate
 100      | Colin Rocks!  | 6:15
 100      | Colin         | 6:45

user_statistics

User statistics keeps a running total of messages sent and received. It stores a sender_id, a recipient_id, the total messages, and the date of the last message sent. This table is primarily for speed, but not a lot does anything with it.

messages

The second table, messages, contains the basis for the plugin: the messages. Named messages, it has a sequenced field for each message (message_id), the message itself (message), the message date and time (message_date), and two references to users (sender_id, recipient_id). If you have tsearch indexing setup, it contains another field (idxfti).

message_notes

Message notes can be used to add notes to yourself on a message. It references a message_id, and contains a title, the note itself, and the date it was added.

information_keys

The SQL Logger has extensible meta-data, which means that you can choose to store any information you want about a certain contact. What you want to store (URL, Location, Website, Address, etc) are all stored in information_keys.

contact_information

The information about each contact is actually stored in contact_information. It contains a field referencing information_keys, to determine which key is being stored, a user_id, a meta_id, and the value. It can store something about either a user or a meta-contact.

meta_container

meta_container stores the names of your meta-contacts. It has a meta_id is the unique identifier for the meta-contact.

meta_contact

meta_contact is very simple. It contains only a meta_id and a user_id, so that as many users can be included in each meta contact as you want. It also contains a "preferred" contact, in the cases where one user is in multiple meta-contacts (so the viewer knows which to use).

saved_items

saved items stores the name of saved forms. It currently stores queries, chats, and searches.

saved_fields

saved_fields stores a list of key-value pairs for the values of the saved form. For example, there is one row for start_date, one row for end_date, etc

simple_message_v/message_v

The created view is used for all of the message viewing. It contains message_id, message, message_date, the screenames from users (sender_sn, sender_service, recipient_sn, recipient_service), and the display name at the time the message was sent. It does not contain message_idx, the tsearch field, or any statistical information. Using message_v can allow searches based on screenname instead of a (relatively) meaningless number.

Insertions

Both the Adium plugin and the log parsing scripts work by inserting a record into message_v. When an insert is performed, a rule fires. It attempts to insert the screennames into users, and doesn't if that screenname already exists. Then it retrieves the two user_ids and inserts a record into message. It also checks to see if the display name has changed, and if it does, inserts a new record into user_display_name. Updates or deletes on message_v silently fail, and are best performed by operating directly on the underlying tables.

Queries

It is possible to see the queries being run by the JSP pages. You can see generic queries used by all the JSP pages at standard.html, queries relating to the statistics at stats.html and update and insert queries at update.html.