Category: Editorial
-
Sharing Data
One of the things that’s written into various computer laws is that unauthorized access of a computer system with another’s credentials is a crime. That’s been drilled into me at various organizations where no one was supposed to share any credentials. That is something many sysadmins drill into users, while sharing their own system level credentials for accounts like root, sa, system, and more. I’ve seen no shortage of these accounts in use across multiple services or multiple people from those that would admonish a manager for sharing their password with an assistant.This week Troy Hunt wrote about politicians sharing passwords, and the problems with doing so. It’s an interesting read, and certainly points out that the expediency of having users share a workload has plenty of downsides in accountability and auditing of actions. I think there’s little excuse for sharing security credentials in UK gvoernment as there are other solutions to handle this issue. I am more sympathetic in real time environments, like hospitals, where the login process might literally cause a death in the event of a delay.Leaving aside the authentication aspect, we often share data among individuals inside of an organization. In fact, outside of sysadmins, there might not be many people that really understand who should have access, let alone who has access, to some data. In fact, over time it seems that most organizations tend to lean towards allowing an ever-growing number of people to access data in file shares. While we might prevent database access and grant/revoke this at times, the output from our systems often ends up in Excel sheets or other files and people that might not have direct access still see the data.The real physical world is just as bad, since many people may leave data lying around on desks or tacked to a wall. Just like credentials on a post-it, we have lots of data available for others to read, though physical access is required. However, have you thought about how many people have physical access? It’s not just your co-workers, but also janitorial staff, tradespeople, and others likely wander regularly through your office spaces.Security is a tough battle, one that is interesting in that most of the time we don’t need much more than good passwords. Most people don’t have the time or inclination to deal with their own data, much less yours. However, when an attack is targeted on your organization, from outside or within, it’s extremely difficult to ensure data won’t get lost.I don’t have a great solution, but I do think that there are good reasons to limit access to data on our systems, not the least of which is auditing and accountability. Beyond that, however, we have to hope that our users have some judgment about with whom they may share reports and other data.Steve Jones -
Singular or Plural
There are all sorts of interesting debates that developers will have about programming. One of those I’ve written about in the past is Spaces v Tabs. There’s a lot of discussion about that one, and certainly no share of strong opinions. I’m sure there are plenty of other development paradigms and habits that will create debate, arguments, and perhaps strain some working relationships.
While I’m not looking to upset anyone, I ran across a discussion recently and thought this would make an interesting debate. If you’ve got an opinion, please share how and why you might choose to follow your convention. Examples are helpful and may enhance the reasons why you go choose to build systems one way or the other.
If you examine any sample databases out there, you will run across tables named like this: Customers, Orders, Cities, etc. You might also find Product, Person, Address as well. If you are paying attention, you might notice that my examples are both singular and plural in their form. There are no shortage of debates on the topic, but I’m wondering what many of you think.
I’ve tended to build tables with plural nouns in the past, but I think that’s because the first few people that taught me did that. As I’ve read more and listened to others explain their design decisions, I’ve embraced singular names. After all, the entity being modeled is often a single instance of a type. A Person or a CreditCard, not a series of them, though we could certainly argue the table is a set of people, so use that.
Ultimately I’m not sure that it matters much in any particular application. We certainly have databases that using each convention, and probably a few that use both inside the same schema. I think choosing an entity name that is easy to understand is important, and maybe the idea of singular or plural names matters less. After all, as long as you’re not naming tables F42 and H1492, everyone will get used to the convention.
Steve Jones
The Voice of the DBA Podcast
Listen to the MP3 Audio (3.5 MB) podcast or subscribe to the feed at iTunes and Libsyn.
-
The Relational Database is the Default
It seems that I regularly meet people in the SQL community that are asked about moving their datastore to a NoSQL type of database. In a mature system, that might be a conversation worth having, especially if there are issues with handling the workload. I doubt there are many type of workloads that I would think are worth moving, but perhaps some exist. However, the discussion about moving is one you can have, given your understanding of the deficiencies you see in your datastore.
Often I often find is a different story for new applications. Often I hear about developers becoming enamored with a datastore, a simpler one than SQL Server or some other RDBMS, and look to MongoDB, Cassandra, Hadoop, Neo4J, etc. as the shiny, new, exciting choice. They think NoSQL offers an easier way to build their application, where they can throw and grab JSON through an API, while changing their minds on the ways in which they need to handle data.
They approach a new application like a startup would, using some exciting technology that has just proven to be successful by some hot company in the news. They look forward to developing an application that other developers will be jealous of next year. Or they just want to use something new that’s being written about on blogs and spoken about at conferences. Or they just want to do something more interesting on the next project. All these might be great approaches, and certainly are ways that make one’s job more engaging.
However. Just as this piece notes, choosing a new datastore because it’s new and exciting, and not because it fits the data model is a mistake. The data model matters, often because this is the permanent output of your software application. The data will live on and needs to meet current and future needs, separate from the amazing Node.JS framework of the week that your users love. Actually, users don’t love your framework. They love your work. Whether it’s MVC, Angular, Django, or Dapper, most clients could care less. Any language/framework/platform can build an application that works well for clients. Your application just has to work.
Relational databases work really, really, really well. They handle most problem domains well, with protection against common consistency errors, and they have plenty of features that help you build a solid data model. There are tips and tricks to migrate your schema to some new form if you need to. However, if you need to migrate your schema every few days, you haven’t really thought about the schema. As the article notes, you need a schema. On read, on write, or both, you’re not getting away with ignoring schema.
And by the way, if you keep your schema in Python or C# or some other language, you’re likely creating a set of “legacy code” that will haunt you for years and is much harder to manage than database schema migrations. Maybe it feels less risky, but it’s probably way less fun to work on.
Databases are a pain to work with. I get that. It’s so much more cumbersome than refactoring C# classes on the fly. Databases have a different job, and they do it well. If you have a good reason to choose some other datastore that’s related to your problem domain and data model, then go ahead and choose something else. If you don’t, then use SQL Server (or PostgreSQL, Oracle, etc.). Most of you won’t, so just stick with relational databases. You might not thank me, but your organization and future developers will.
Steve Jones
The Voice of the DBA Podcast
Listen to the MP3 Audio ( 4.8MB) podcast or subscribe to the feed at iTunes and Libsyn.
-
Pluralsight is Amazing
I used to work for a digital learning company early in the modern Internet. We were ahead of our time and struggled to sell online learning at the turn of the millennium. Bandwidth limitations held back video courses from widescale adoption. I moved on when the company folded, but I’ve watched other companies start to build and grow video training across the years. One of them that I’ve been most impressed with is Pluralsight. In fact, I very much appreciate their customer service.
I try to make time every week to watch something. I don’t always get to any bits of learning, which is the way things go. Life is busy, and some days I don’t have the mental energy. I do try to download a course or two to my phone for long plane rides and other travel. I’ve even had a few modules playing on long drives or in my headphones while skiing. Of course, I can’t watch the screen during those events, but I can listen and try to learn something on the go. I’ve even whiled away sessions on the stationary bike with a Pluralsight course playing in front of me. It’s not deep learning, but it’s a way of looking at something that I find interesting. I often will go back and try a bit of code later.
I don’t focus too tightly on SQL Server with Pluralsight as I get plenty of that elsewhere, but sometimes I use their courses for investigation into other areas. I’ve listened to Chef and Puppet courses, C#, ASP MVC, Python, and more. I don’t always use the skills directly, but a little learning does help me understand the larger view of how technology works. I’ve found throughout my career that having some good general knowledge in various areas helps me troubleshoot and understand the larger picture, often helping me find an issue in a complex system quicker. I also get ideas on why I might consider some other type of technology as a way of improving an application in the future.
I certainly hope that most of you continue to come to SQLServerCentral to get ideas, learn something, and get questions answered. My mission with this site is to help others become better SQL Server professionals. We may add some video to go with our written work, and certainly I think we could improve some assessments and testing. If there are areas you’d like to see more content, let us know.
However, we can’t do what Pluralsight does with their long courses and variety of topics. If you get the chance, or have a subscription, check them out. They provide a great learning resource that I’d recommend.
Steve Jones
The Voice of the DBA Podcast
Listen to the MP3 Audio ( 3.7MB) podcast or subscribe to the feed at iTunes and Libsyn.