A comprehensive and complete summary can be found in the When DNNs go wrong blog, which I recommend you to read.
All these amazing studies use state of the art deep learning techniques, which makes them (in my opinion) difficult to reproduce and to answer questions we might have as non-experts in this subject.
My intention in this blog is to bring the main concepts down to earth, to an easily reproducible setting where they are clear and actually visible. In addition, I hope this short blog can provide a better understanding of the limitations of discriminative models in general. The complete code used in this blog post can be found here.
This is a great article.
I was editing an article recently that talked about ROLLUP, and I wanted to play with this a bit more. I hadn’t used this much in my career, but it’s a handy operator that’s worth including in your toolkit.
ROLLUP is used to provide additional totals for your aggregates while using GROUP BY. Here’s a little example. I’ve got some data for American Football quaterbacks. In this case, I’ve extracted some stats for a few noteworthy players today.
I’ll probably end up using ROLLUP about once every three months and be very pleased when I remember that it exists. I use GROUPING SETS more often and almost never use CUBE.
In some cases, sources for Direct Query models are either large (and therefore need some time to bring back the data) or slow (which could maybe be improved by some database tuning :-)).
Before the Nov2017 release, every change in a filter or slicer led to an immediate round trip to the data source which made some of those reports … let’s call it .. not perfect in the context of user experience.
Beginning with the Nov2017 release some options for Query Reduction has been introduced.
Click through for an example of how to use Query Reduction on direct query models.
The short version is that our data, log and backup files are encrypted at rest (i.e., on the storage layer), so that an attacker cannot simply copy and attach the data and log files, or restore a backup, without having access to the master key. If backup tapes or drives are stolen, the data on those devices cannot be recovered.
We can also use what is known as a Hardware Security Module (HSM) to provide keys to secure the database. This is a dedicated physical or virtual device, separate from SQL Server, that generates keys for various services in an organization.
Read on for Randolph’s argument. For the counter-argument, check out Simon McAuliffe’s article on the topic. Over the past couple of years, I’ve grown much more sympathetic to the idea that TDE’s primary use case is in weeding out the rabble-rousers with nary a clue, but it’s not very helpful against a knowledgeable attacker with administrative access to your SQL Server.
I have written while ago, about how to implement a dynamic row level security in Power BI. This post is an addition to that post. I’ve had a lot of inquiries that; “What If I want users to see their own data, and the Manager to see everything?”, or “How to add Manager or Director Level access to the dynamic row level security?” This post will answer this question. In this post, you will learn a scenario that you can implement a dynamic row level security. In this scenario, everyone will see their own data, but the manager will see everything. If you want to learn more about Power BI, read Power BI book from Rookie to Rock Star.
Read on to see one method of solving this dilemma.
@brianszadek says: I am looking to automate the scripting of objects with PowerShell for easier source control integration.
I thought this would be a little bit easier, but it looks like the SMO way of doing this is still fairly complicated. Maybe something I can look at simplifying for the project in a bit
If you want to get your database into source control but feel like it’s going to be a time-consuming challenge, this isn’t the time-consuming part.
In only a few seconds you have a SQL 2017 instance up and running (Take a look at Andrews blog at dbafromthecold.com for a great container series with much greater detail)
Now that we have our container we need to connect to it. We need to gather the IPAddress. We can do this using docker command docker inspect but I like to make things a little more programmatical. This works for my Windows 10 machine for Windows SQL Containers. There are some errors with other machines it appears but there is an alternative below
Read the whole thing.