Virtual Workshop: SQL Server 2008 Indexes – Internals and Best Practices
Feb. 25, 2011
Along with a good database design I would say that Indexes are a cornerstone to good database performance. There are a lot of other skills you can develop in relational databases; but without these two skills, you’re going to find yourself in a heap of trouble. The SSWUG.org’s virtual workshop, conducted by Microsoft SQL Server MVP Kalen Delaney, will give you the skills you need to understand indexes, evaluate their effectiveness and make the necessary adjustments for performance. Register today to save your spot.
Online Course: Introduction to SQL Server Replication
12 On-Demand Sessions Start on MARCH 1, 2011 and Ends MARCH 31, 2011
Have you taken advantage of any of these on-demand courses taught by Eric Johnson yet. The response has been awesome. You have access to all the course content, in this case 12 sessions, for an entire month. Study when you have time, learn at your own pace, and establish an expertise in areas where you have not had enough experience. Click Here to Register for the March series. Registration ends February 28th.
DBTechCon – Spring 2011
The SSWUG Spring 2011 virtual conference is quickly coming together. You can go to the registration page and see profiles for presenters, and summaries for the sessions to be presented. Without a doubt, this will be the largest virtual conference in the information technology industry. Access more than 70 sessions from well seasoned professionals with in-depth instruction on technologies such as SQL Server, SharePoint, .Net, Business Intelligence and much more. Register any time from now to April 19th. There are early registration discounts for those who register early. Go to the Registration page to get signed up right away.
$$SWYNK$$
Featured Article(s)
Fault Tolerance Options, Overview of Features and Techniques (Part 2 of 3)
Now, from a Microsoft perspective, what Microsoft has done is created a branding that they are calling Always On. And they introduced this branding with SQL Server 2005 in their Always On technologies. And basically, it’s a marketing term, but it also helps from the perspective of hardware vendors that are building specific systems for a SQL Server. They could also this branding to say, "This is capable of using the following Always On technologies." And it just helps people to purchase the right hardware, which has traditionally been a real problem with respect to building high availability systems in SQL Server.
Featured White Paper(s)
An Introduction to Workload Tuning
Workload Tuning is just what it sounds like: tuning the performance of all processes that comprise a database workload in one… (read more)
Featured Script
Metadata get descriptions from all tables
SQL Server 2000 allows metadata to be added to table definitions – i.e. descriptions. This script gets all descriptions for… (read more)
Separation of Customer Data for Hosted Solutions
Many of us provide Software as a Service, meaning that we sell the use of our software to our customers, but host the application and data on our systems. Customers access the applications through either a Web application or some sort of local application using a web service, etc.
This is a growing software model, especially with the growth of the Cloud. One issue this raises is the necessity to separate data from one customer to the next, assuring that credentials provided guarantee separation of data. For the last 7 years I have worked with companies where this is a core requirement of their database systems.
It’s pretty easy to separate customer data for those services where there is little or no shared data between customers. However, when the majority of the data is common across customers, the implementation, especially in a relational database, becomes more challenging.
For example, say you have a completely separate database for each customer, but customers are able to have relationships to tables contained in the shared central database, how would you enforce referential integrity between the two? You cannot declare a foreign key constraint against a table in a completely different database.
Do you instead use our old friend the Trigger? How do you handle the fact that your trigger now has a hard coded relationship to a Server.database.owner.table? You can’t easily move that database from one instance to another.
Do you simply refuse to impose the relationship in the schema and push this requirement into the business logic layer of your application?
There are a lot of other issues, some of which I’ll add to tomorrow’s editorial. However, feel free to send your experience and/or thoughts (I promise to be gentle) to btaylor@sswug.org to get into the discussion. Share with our readers how you have or will solve some of the challenges for the developers who must create physical separation of their data.
Cheers,
Ben