When you define a subscription class, you are defining storage for subscription data and queries that generate notifications from event and subscription data.
When defining storage for subscription data, you define fields for the subscription data you collect. For example, if part of the subscription data is a city of interest, you can add a City subscription field. Then, you provide an interface to let subscribers create subscriptions in which they specify a city.
If your application supports multiple subscriber locales and multiple devices, such as e-mail and cellular phones, you also can add DeviceName and SubscriberLocale fields to the subscription fields. These fields let you customize notifications for different devices, time zones, and languages.
Notification Services adds a SubscriberId field to the underlying table for each subscription class.
Besides defining subscription fields, you must also define a notification generation rule. This rule is a Transact-SQL query that matches event and subscription data and inserts the results into the notification class view. These rules can be event driven or scheduled. Event-driven rules run whenever events arrive. Scheduled rules evaluate individual subscriptions on a schedule provided in the subscription.
A subscription class can define other information, such as indexes on the subscription data and supplemental tables. For more information about subscription classes, see Defining Subscription Classes.
When you create the application, Notification Services uses the subscription class definition to create tables, views, indexes, and stored procedures for the subscription class.