A few years ago I had a requirement to allow both developers and customers to see rows from a table used to store error information while making sure that any PII, PCI or similar sensitive data was not displayed. The tolerance for “oops” was low! This article presents one way to solve the challenge by […]
Many of have applications that log errors to a table. Ever thought about what happens when an application starts to throw a lot of errors? This article looks at the problem and some of the responses you might consider having ready in case it happens to you!
It’s still a bit hard to believe that SQL Server will soon run on Linux. If you think back to the early days of SQL 7, 2000, even 2005, who would have bet any money on it ever happening?
If you’re involved in the database world it’s hard to have missed the rise of the “no-sql” database products, designed to – depending on your view or the product I suppose – make databases simpler, break out of the transaction database paradigm, scale out across hundreds of machines, make it easy to change the db design (or not require one). I think some of the problems no-sql tries to solve are real, others reflect a lack of awareness/training/tools on how and why relational databases could not just solve the problem, but solve it better.
Back in April Steve Jones wrote up a disaster at work. Andy had one this week and wrote up the story too. Copy cat! Pretty soon everyone will be having a disaster and writing a story about it! Give these guys credit for letting you see what happens when it ALL goes bad. Disaster recovery is hard to sell and hard to do, reading the article might give you an idea that will save you some time and/or data one day.