Home Projects Jobs Clientele Contact


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Latest DB schema

I have added a preliminary notifications support. The current version has simplified data integrity since (at this moment) I believe this data is not that important to add and maintain around 6 extra tables.

In short words, we have notification_list table that has the following fields (besides nl_id):

nl_person (int) - a reference to the notification receiver person_list( pl_id );
nl_even_type (int) - a bit-mask of events that trigger a notification. See event_type( et_value ) for possible events.
nl_object_type (int) - a reference to the object type user_object_type ( uot_id );
nl_object_id (int) - a reference to the object id (not covered by the foreign key). Object id is an id of the object record in corresponding *_base table for this object type. For example, for topic objects it would be topic_base table.

This schema allows to define a set of events for the particular object, that should trigger notification for the particular user. Since nl_object_id refers to an object and not to an object version, all versions of the object are included.

2006/11/1, Ilya A. Volynets-Evenbakh <ilya@total-knowledge.com>:
Alexey Parshin wrote:
> IMO, any preferences that are not one-to-many (ie not a list), like
> preferred_language, may go into person_list.
I tend to agree with that.
> As for the others - we would need to discuss it separately, since it
> probably requires support on the database level.
> The notifications, for instance, belong to an object.
Hmm... At first I wanted to say "to object relationship", but then
realized that relationships themselves
are versioned. At the same time each object-object relationship may have
its own notification preference.
I guess this either means separate object<->object table for
notification statuses, or copying that
preference when creating new object version, and using last version when
sending out actual
> 2006/10/31, sergey@total-knowledge.com
> <mailto:sergey@total-knowledge.com> < sergey@total-knowledge.com
> <mailto: sergey@total-knowledge.com>>:
>     > sergey@total-knowledge.com <mailto:sergey@total-knowledge.com >
>     wrote:
>     >> I think we may need something like person_preferences table to
>     handle
>     >> user
>     >> preferences for
>     >>
>     >> 1. Prefered UI language.
>     >>
>     > Good point. Although this might be just a field in person_list
>     IMO a new table may be better, since user may have many additional
>     preferncies(email notifications for ordering, currency, the way UI
>     displays certain UMOs/features, any kind of
>     restrictions/limitations/preferencies for UMO he is an author of,
>     etc).
>     >> 2. Object change notifications/preferencies.
>     >>
>     > No, these are per-object-relation. Although you are right in that
>     > the info is missing.
>     >> Also we need to handle user types somehow, probably using
>     user_types
>     >> table.
>     >>
>     > There are no user-types as such. There are access kinds users
>     > have to different objects. ACL tables handle that.
>     >
>     > --
>     > Ilya A. Volynets-Evenbakh
>     > Total Knowledge. CTO
>     > http://www.total-knowledge.com
>     >
>     >
> --
> Alexey Parshin,
> http://www.sptk.net <http://www.sptk.net>

Ilya A. Volynets-Evenbakh
Total Knowledge. CTO

Alexey Parshin,

Authoright © Total Knowledge: 2001-2008