alerts say
AlertID PK
AlertUserID FK references(User, UserID)
AlertDateTime
AlertRead
AlertMessage
The AlertUserID refers to the User that the alert is for
Your db is normalized
You can have as many or few alerts as you like
You can post to AlertRead when the user retrieves the alert (for the
firse time)
you can purge alerts that are n days old and/or have been read bu the
user.
There is no system-imposed limit on the number of alerts that can be
stored for a given user & this is a very efficient way to process and
store them -- a RDBMS is designed specifically to handle this kind of
relationship.
Another way to do this is with JMS (Java Messaging Services) this is
not much used now, but I think we will be seeing a lot of JMS usage
when Blackstone arrives,
Basically, JMS is responsible for receiving, storing and delivering
messages relieving the develop of much of the work.
JMS is built into JRun, so you won't need to buy anything.
But, for now, it is probably easiest to manage the alerts in a
database, as above.
HTH
Dick
On Aug 27, 2004, at 11:41 PM, Roberto Perez wrote:
> Hi all,
>
> I'd like to hear opinions on how to implement this: I have a database
> of
> users and I'd like to have a section for "alerts" or "internal
> messages".
> This would store messages/alerts send by another user (a request, a
> response, etc.), or by the system (new message, new request, new
> contribution to discussion thread, etc.).
>
> What I'd like to know is how would you go about those storing alerts:
> - A bunch of fields in the user database, like "alert1" through "alert
> 100"? In that case, what happens when there are more than 100 alerts
> accumulated? And, wouldn't that make a huge database?
>
> - Some system (that I don't know of) that would add a field to the
> database
> as alerts come in, thus allowing for an infinite number alerts?
>
> - Something else?
>
> The way eBay does it is they let you keep up to 30 items in your
> "monitoring auction" section, and you cannot add any more when you
> reach
> that limit. So I guess in their case they do have 30 fields in the
> user
> database. That, as said before, would be kind of limiting.
>
> Any ideas, best practices, possible solutions that you can think of
> or have
> actually implemented?
>
> Thanks in advance,
>
> Roberto Perez
> [EMAIL PROTECTED]
>
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings] [Donations and Support]
