Magical Memory Moments, or,
How In-Memory Objects Can Supercharge Your Data And Bring About World Peace (Well, maybe not both of those fantastical concepts …)
OK, so you’ve been reading about, perhaps even testing out some of the ‘in-memory’ objects now available in SQL Server. Some of the claims are exciting, and some seem overly optimistic. And Yet, you want to know, experience more … Perhaps your situation doesn’t really call out for in-memory tables. But you should consider memory-optimized #Temp tables, memory-optimized table variables, and natively compiled stored procedures.
It’s true. Using memory-optimized tables requires a little more fore-thought, a bit more care, even a few configuration tweaks.
• But what are the real advantages of memory-optimized objects?
• What are the memory-optimized objects you can use?
• How can you best use memory-optimized objects?
In this demo packed session, we will discuss the pros and cons of using memory-optimized objects in ways that will supercharge your SQL Server. You will leave the session with concrete examples and great ideas of how memory-optimized objects in SQL Server can bring about World Peace. Drat, I meant to say the other one!
Arnie is a long serving Microsoft SQL Server MVP (10 years), has been a Subject Matter Expert (SME) working on SQL Server training courses since version 2000, and has been involved as a SME with the development of the SQL Server Microsoft Certification Exams. Arnie has also been a Microsoft Certified Trainer, and has served as a technical editor for several publishers, including multiple SQL Server titles in the Microsoft Official Curriculum. Arnie has served as adjunct faculty at both University and Community College. Clients include Fortune 500 and Multi-National companies, Federal and State agencies, Foreign governments, nationally recognized training facilities, and local enterprises –both public and private.
Multi-Tenant database using RLS – A case study
What is a multi-tenant database? And why do we want one?
A multi-tenant database allows users from disparate groups to share a database but not have visibility to each other’s data. The idea is that a single application or suite and a single data base instance can appear to users as separate copies.
Leveraging an existing capability to support multiple clients without giving one client access to another’s data.
Often (always) a database includes a fair amount of “metadata” which is not specific to users. Rather than duplicate those tables you can provide full access to this by everyone.
Tables are identified as shared or not. Shared data is available to users regardless of company. Non-shared data has rows specific to a particular company. An example of non-shared is the Product table where there are records belonging to one company or another.
Pat is Technical Architect at R2C Group, a local ad agency that uses custom applications and a reasonably large SQL database to manage the business of buying and evaluating advertising performance. Recently they have refactored their database and applications so that multiple companies can share the same data. After evaluating several strategies they went with Row Level Security which is available on MS-SQL 2016
The presentation will use the project as a case study. He’ll show us how they did it and what challenges they had. He will show actual code snippets and demonstrate the results..
Refreshments graciously provided.
Featured Sponsor: Intertech
Visit our website for more details.
We wish to acknowledge the OSHU Information Technology Group for supporting Oregon SQL by generously providing the meeting venue.