[
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
notifications.
>
> 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
http://www.total-knowledge.com
--
Alexey Parshin,
http://www.sptk.net