microsoft.public.sqlserver.notificationsvcs
[Top] [All Lists]

Re: Multiple Subscriptions to the Same Field Type

Subject: Re: Multiple Subscriptions to the Same Field Type
From: Joe Webb
Date: Wed, 06 Sep 2006 06:36:35 -0500
Newsgroups: microsoft.public.sqlserver.notificationsvcs
Hi Isadore - 

The good news is that I think you have plenty of options from which to
choose the best one that meets your needs. You certainly could create
a subscription for every sales person you're responsible for - I don't
know that your users will necessarily find that to be the best
implementation though. 

Why not use the group scenario like the pre-SQLNS days, if that worked
well for you?  You could include the join in your match rule. I think
you could probably re-write the current query to use joins or even
subqueries and do away with the need for a temp table. 

HTH...




-- 
Joe Webb
SQL Server MVP
http://www.sqlns.com


~~~
Get up to speed quickly with SQLNS
http://www.amazon.com/exec/obidos/tg/detail/-/0972688811 

I support PASS, the Professional Association for SQL Server.
(www.sqlpass.org)




On Fri, 1 Sep 2006 06:41:01 -0700, Isadore Schwartz
<[email protected]> wrote:

>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
>> http://www.sqlns.com
>> 
>> 
>> ~~~
>> Get up to speed quickly with SQLNS
>> http://www.amazon.com/exec/obidos/tg/detail/-/0972688811 
>> 
>> I support PASS, the Professional Association for SQL Server.
>> (www.sqlpass.org)
>> 
>> 
>> 
>> 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>