|
| Featured Contents |
| Question of the Day |
| |
| The Voice of the DBA |
| The Types of Changes I would guess that most of you reading this piece are database professionals in some sense. Either you work on databases as a developer of some sort (app and/or database) or manage them as a DBA or sysadmin. In working with databases, I'm sure that you need to alter object structures. Maybe you perform a lot of changes, or maybe you just alter the schema occasionally, In either case, you need to make decisions on which changes to make. I would guess that the most common changes are altering stored procs/views/functions. Often these are to handle new or updated business rules. In those cases, how do you ensure you haven't added regressions? I would hope you had a set of test scripts to verify that your results are correct. If I were very optimistic, I'd hope that you had a set of automated tests, such as those you could write with tsqlt or the Microsoft Unit Test Framework. I'm sure many of you add new columns to tables. What are these types of changes? Capturing new data? Splitting existing columns or de-normalizing data? In these cases, are you re-examining the data model to ensure the changes make sense? Maybe even more importantly, if you are capturing new data, do you consider vertical partitions for the table? This can be a good way to separate out data in columns that isn't queried as often. Despite most recommendations, lots of developers will still SELECT * from tables, which can flood the buffer cache with data that isn't often needed by an application. Vertical partitions can reduce the impact of these types of queries. For those of you that add new data, do you consider using different data types for your new data, or do you have a standard string/numeric/date type that you use? SQL Server (and other platforms) often have a variety of different data types that can save space, while still accommodating the requirements for a change. As an example, many people use datetime as a standard type when they just need a date. In this case, we could save 5 bytes per row by choosing a more appropriate type. If you add status values or flags, have you considered bit storage for your values? Whether you use the bit datatype or bits in an int, you can dramatically save space in each row. Newer versions of SQL Server include T-SQL functions to help you work with bits, though I would hope most developers can handle simple AND/OR logic against an integer to test if a particular bit is set. Most software under active development has a need to continually alter and modify the database to meet new requirements. While lots of us have experience in making these changes, and do so often, once we make a change it often becomes enshrined in our production system for years. I would hope that we feel confident in refactoring our code as needed, but the reality of what I often see is that people are loathe to change the database for fear of breaking our software. Even when the refactoring actually improves the performance of the application. I'm curious what types of changes you often make, and how you go about deciding on the specifics of the change. Let us know about your approach in the discussion. I'm especially interested in how you might handle the various options for changes. Do you assume defaults or are you explicit in how you structure your ALTER code? You might have a novel way of examining requests and implementing changes that can help others in learning to ensure they make better changes in their own system. Steve Jones - SSC Editor Join the debate, and respond to today's editorial on the forums |
| |
| Featured Contents |
