database management

Database management isn’t rocket science: it is essentially the capture, storage and retrieval of your data. Our involvement would depend on what you need: for example we can manage your data over time in such a way that you secure all the benefits of it being managed in-house, with none of the disadvantages of it being managed by a third party; alternatively it may be project-based eg. data migration or manipulation exercises (see next page).

So why is database management so important? Well, one of the most important resources that any organisation can possess is its data. This can be data about sales, leads or enquiries; products, services or other offerings; customers, employees, subscribers, members or other stakeholders, etc; in fact just about anything that can be listed can be a database. And it makes sense to capture that data effectively and to store it efficiently in order to be able to retrieve it comprehensively.

Capturing data effectively starts with database design. Its structure should enable you to acquire the data that you need, avoiding peripheral or ephemeral information. Self-evidently, if you don't capture the data that you need, then you won't be able retrieve records based on it; so if you only ask for e-mail addresses from subscribers to an e-newsletter, you’ll be unable to identify them geographically. For postal addresses, rather than just pouring in an address top-down, you should use ‘dedicated’ town and postcode fields. For personal data, the components of data subjects’ names should be entered separately (Mr+John+Smith), enabling you to build salutations for personalised mailings (and in 2010 non-personalised mailings are simply not credible). Records should also be error-checked or validated as far as possible, as they are entered; eg. pasting (rather than typing) in addresses from an address checker, or at the very least validating postcodes against PAF. They should also be classified in some useful way, on entry, ideally from a look-up table.

Storing data efficiently is about choosing your database environment wisely, and structuring it in a rational fashion. Data held in a spreadsheet (such as Excel) or low-level file-based database (like Access) may be OK for short-term analysis of a small number of records, but you don’t have to push these too hard to find their limits, especially if it migrates to the web, where a client/server database (eg. MySQL or SQL Server) is essential. Also, most data needs to be held in a relational database, rather than a ‘flat file’; such data is said to be normalised ie. to have optimised relationships and therefore to be organised so as to avoid duplication, further saving storage space and improving performance. Here are two key examples of database management ‘norms’.

Retrieving data comprehensively means that no matter what data you want, whenever you want it, in whatever format you want it and irrespective of how it is to be retrieved, you do not encounter difficulties. This should continue to be the case even if you change your mind about frequency, format or retrieval methods (click here for a case study that epitomises this). So, assuming your data has been entered effectively and is being stored efficiently, then data retrieval should be straightforward. One of ABC’s key strengths as a database manager is that ‘if the data is in there, we can get at it’!

top of page

This is not always the case. With some database management operations, calling for data extracts can be a frustrating, time-consuming and often error-prone affair. This is particularly true with some in-house operations, where the maintenance of lists is left to non-specialists, usually as a peripheral activity to their primary role within the organisation. All too often, database management is seen as a relatively low-level, largely clerical activity. So it is little wonder that when you come to analyse the output of these organisations you often find that their lists are poorly maintained, out-of-date, inaccurate or full of duplications — often all of the above! We encounter phrases such as “So what if much of the list isn’t postcoded? It’ll probably get there”, or the classic “Well, if we contact them more than once, they can always let us know”, to which our reaction is “Meanwhile, back on Planet Earth…” (click here for a case study where poor quality data simply wasn’t an option).

Organisations that are smart treat their data with the respect it deserves and can therefore reap the dividends from being able to maximise their investment in that data to further the organisation’s objectives, quickly and cost-effectively. The bottom line is therefore:

• decide in advance what you are seeking to achieve
• choose and structure your database environment to meet those objectives, usually in a relational fashion
• capture data comprehensively and accurately
• have at your disposal powerful tools to enable rapid and precise data selection, and
• ensure that you can extract whatever data you need, when and how you need it, directly or indirectly

Or, better still, call in the professionals!

top of page