I apologize in advance if this is a stupid question... :-)

We are using NS alongside of an existing CRM system that was built
in-house. We have our own Customer table that has a CustomerId, Email, and
an active/inactive flag (among other things). To integrate w/ NS, we have
copied our Customer data over into our NS Subscriber table, making sure the
NS SubscriberID matches our CustomerID. We have created processes that
keep these tables in sync.

On the NS side, we have attempted to write our Subscription Class join
using the views that are created, and for the most part we have been
successful. That said, using these views seems to add an extra level of
complexity, as opposed to just joining back to the Master NSSubscriber
table, or even back to our own Customer table. So, my question is this...
Is it essential to use the views generated during a quantum in the
Subscription join? What do they bring to the table that would not exist
without them?

Please understand, I'm really seeking understanding of NS here, not just
wanting to rebel against the norm. I notice Shyam's book advocates the
views and uses them in the examples, so I'm assuming that is best practice.
I was just asked by my boss why the views are needed, and I didn't have an
answer, so I'm seeking justification for the complexity.

Thanks,

Scott,
You are never required to use any of the views and NS certainly can't
enforce whether you do or not. However, in some cases, using the views does
provide some value. I'll try to describe the best practices here.

In general, you should never work against NS tables directly. The structure
of the tables can change from release to release and the expected contents
of the tables is never guaranteed. The views define a public contract so
it's always safe to use those.

In the case of subscribers, you should feel free to go against your own
table instead of the NS view. Just don't go against the NS table (as per the
previous paragraph).

For events and subscriptions, going through the views means that you get the
benefits of the NS scoping mechansims. In other words, the events view is
guaranteed to only contain the "current" events against which your rule
should fire. If you went against the events table directly (again, not
recommended) you would have to figure out what data is in scope manually.
Same goes for the subscriptions view, especially in the context of scheduled
subscriptions: only the subscriptions due to fire at the current time will
appear in the view.

Hope this helps.
-shyam
--
Learn more about SQL-NS:
http://www.amazon.com/exec/obidos/tg/detail/-/0672326647/
---------------------------------------------
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm.
---------------------------------------------
[quoted text, click to view]