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
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.
"Joe Webb" wrote:
> I'm assuming the events, subscriptions, etc are the same for the
> 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.
> 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
> >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
> >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
> >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?