New SQL Server Show – SelecTViews –
Open source projects and SQL Server, FrontPage Lives?!, Business Intelligence is profiling…. or is it? SQL Server tools and the cloud, featured blog, Chris Shaw on the show and MUCH more.
[Watch the Show]
Kalen Delaney 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.
$$SWYNK$$
Featured Article(s)
SQL Server 2008: The Resource Governor (Part 1 of 3)
One of the long requested features by many DBAs over the last few decades has been the ability to throttle resource usage based on the workload coming in to the server. Microsoft has finally given us the Resource Governor in SQL Server 2008. In this session, we’ll talk about what the Resource Governor really is, how it works, and what it will and WON’T do for your servers
Featured White Paper(s)
Why and How You Should Find and Fix Index Fragmentation
In a high-volume database you need frequent critical maintenance. If you skip this important task, index fragmentation may ca… (read more)
Featured Script
Script SQL Database DDL
A tool which scripts out SQL Server 2000/2005 database objects to individual files in a manner which mimics Microsoft’s Visua… (read more)
Data Separation Techniques – Day 2
Yesterday we talked about taking Sensitive data and placing it in a separate database. Common data is replicated across all the separate data stores allowing for the enforcement of referential integrity.
Another pattern, that comes in from our readers, pushes the requirements for referential integrity into a different layer of the application. This means that the common data is stored in a central database shared by all, and the protected data is stored separately. This pattern was used when the volume of common data was far greater than that of the protected data.
This design requires a lot more work on layers outside of the database in order to not hard code server.database.owner.object items into your SQL code, or require a lot of maintenance on alias definitions.
In this kind of design, the persistence layer or business layer performs the necessary join of data from the disparate data stores so that the database server does not ever have access to both databases in a single query. This method places the logic of data store direction outside of the database. It also requires the other layers to handle the issues of referential integrity.
Another reason this model is more common would be the use of data stores other than relational databases. So, now you may have heterogeneous data stores, but your persistence layers can handle that readily.
Do you have an implementation strategy you’d like to share with the rest of us? Drop me a line at btaylor@sswug.org and I’ll include your thoughts.
Cheers,
Ben