[Top] [All Lists]

Re: Multiple Subscriptions to the Same Field Type

Subject: Re: Multiple Subscriptions to the Same Field Type
From: Isadore Schwartz
Date: Fri, 1 Sep 2006 06:41:01 -0700
Newsgroups: microsoft.public.sqlserver.notificationsvcs
Hi all,

Thanks for the initial responses. I think I explained what I was looking at 
in the wrong way. The answers help a bit, but the situation is a little 
different than what I believe I was able to express. I'll try to explain the 
scenario a little better below.

Let's use Sales people as an example.

I am Joe, a sales person for widget dealers. There are 20 other sales people 
on the sale force. We're all responsible for managing how many widgets are in 
stock, how many have been sold, and the people we've sold them too.

This is the situation. I come into work on Monday. I log into the system, I 
have a subscription to the application that says "give me a listing of all of 
the widgets I've sold since the last time I logged in, and who I sold them 
to." That's the easy part.

The difficult part is this. I also can manage and review sales data for 10 
of the other 20 sales people. So, when I log in, not only do I have to 
retrieve all of the updated widget sales for myself, I also have to retrieve 
all of the updated widget sales for the other 10 sales people that I have 
access to.

So, really, my question is how best to manage that from a subscription 
aspect. Do I have one subscription with a massive event rule for matching? 
Multiple subscriptions for every other sales person that I am somehow an 
associated subscriber to on top of my own subscription? Manage it someway via 
tables in the database? Or some other method.

At the moment (pre-SQLNS), we manage this application by storing a 'group' 
table in the database, which has one ID for the group, and a listing of all 
of the sales people IDs in that group. When we go to retrieve the data, the 
first thing we do is create a temporary table that is filled with all of the 
IDs for the group the logged individual is in, and then parses through each 
ID in that table to retrieve the relevant data for each person before 
returning the entire data set to the individual that is logged in.

Thanks again.

"Joe Webb" wrote:

> I'm assuming the events, subscriptions, etc are the same for the
> clients? 
> If so, could you combine the data into one table (replication, etc)
> using and clientid column to indicate where it came from and then use
> that as part of your matching rule? When the subscriber signs up, they
> could either select it themselves or have the subscription management
> app do it for them behind the scenes. 
> HTH...
> -- 
> Joe Webb
> SQL Server MVP
> ~~~
> Get up to speed quickly with SQLNS
> I support PASS, the Professional Association for SQL Server.
> (
> On Mon, 14 Aug 2006 13:19:01 -0700, Isadore Schwartz
> <[email protected]> wrote:
> >Hi all,
> >
> >I am looking at an application configuration that requires me to manage data 
> >for multiple clients as a single manager. Basically, I can have any number 
> >of 
> >clients I am responsible for (say 20), and I need to be able to retrieve any 
> >updates to data regarding those clients as it comes in. Thus, I could 
> >receive 
> >an update for 1 client, 5 clients, or all 20 clients all at the same time.
> >
> >My question is this. In a subscription model through SQL-NS, what would be 
> >the most reasonable/efficient way to manage that many clients (assuming that 
> >the search context would be - "give me all XXX for client YYY" in the 
> >subscription.
> >
> >I'm finding myself a little stuck functionally between having to define an 
> >individual susbscription for all 20 of the clients (for the single manager 
> >individual), or some sort of dynamic subscription that has all 20 clients as 
> >individual fields in the subscription.
> >
> >What do any of you feel would be the best way to work with this?

<Prev in Thread] Current Thread [Next in Thread>