Database to my alpha system - is it needed?

Database to my alpha system - is it needed?

07-07-2007, 11:44 AM

Hi everyone,

I am new to post in this forum, despite of the fact that I frequently read here.

I am a graduate student in Physics - pretty poor living on stipends:P. And I have been starting GTD for ~1 month now. The initial setup phase, is settling down, and I am trying to tune the system to best suit my needs.

According to David, one of the things I do is to set up an alpha system for general reference filing.

I don't have much stuff to file, so I'm able to fit them into 1 drawer. My current system consists of the followings:
/i 26 hanging folders labeled A-Z
/ii every manila folder files stuff to its own right (even 1 piece of paper as David puts it), which is in turn put into the corresponding hanging folder according to the first letter in the label.

My question is:
I have been wondering if I should setup a database for the filing system, so I can search the inside by keywords, and exactly locate what I want, when I need it.
Pros is: I have exact knowledge about my general reference, out of my mind, which I can even carry on the go with my PDA

Cons are:
/i every time I file something, I need to enter its data. Though I can streamline it to just a few clicks and typings, I wonder if it adds to my mental resistence to file.
/ii then, assume I can overcome this mental load (as I think keeping the database is a fun thing by itself), is it a practical approach? Provided the sometimes dynamical nature of our filing, I might need to update the database every time I move something in/out. It tremendously adds to the complexity, as I need to remind myself to update the database every time I access something, or I cannot trust it (esp sometimes you just need to grab sth out for a while).

---------------------------------------------
So, with these ponders in mind, I am not sure if I should spend the time setting it up, and maintain it up to date. As most people here put it, the system should be as simple as possible, but not too simple.
/i Is a database really worthwhile to do?
/ii Is the sacrifice in simplicity worth the benefit?

/iii if a database is a good-to-go, which software should I use?
/iv if a database is not worthwhile, is there any solid naming techniques or conventions so I can still access what I need in my reference as its volume grows?

I don't think having a database for the sake of having a database is a good investment. YMMV.

You will probably find that you accumulate large piles of technical reading material as your studies progress, especially as you start to focus on specific research questions. In physics, much of this material will be accessible in electronic form, so you may find that electronic storage is more convenient than paper storage.

It therefore might make sense to wait and see what information you have, and in what form, before you decide how best to organize it.

Katherine

Comment

I don't think having a database for the sake of having a database is a good investment. YMMV.

You will probably find that you accumulate large piles of technical reading material as your studies progress, especially as you start to focus on specific research questions. In physics, much of this material will be accessible in electronic form, so you may find that electronic storage is more convenient than paper storage.

It therefore might make sense to wait and see what information you have, and in what form, before you decide how best to organize it.

Katherine

Thanks Katherine. Yes, in physics and the topics I am working on (which has more biology now:P), most technical readings can be in electronic forms. I am now picking up EndNote (which my PI recommend) to organize them - both the paper and digital versions.
I shall keep the technical part of my reference in another drawer in my lab, and soft copies in my computer. I might try giving them their own drawer later when hard papers grow. I hope to keep these specific technical stuff out of the "daily-s".

So, my ponders are mostly on the daily stuff in my reference systems (restaurant manuals, bills, tax forms, phone bills......or even ticklers). What do you think about a database, for this large amount of apparently unrelated reference materials?

Thanks a lot

Comment

So, my ponders are mostly on the daily stuff in my reference systems (restaurant manuals, bills, tax forms, phone bills......or even ticklers). What do you think about a database, for this large amount of apparently unrelated reference materials?

Honestly? I think it's a waste of time. In my experience, filing this kind of stuff is extremely straightforward. There may be a lot of ways to file most technical papers, but a phone bill is just a phone bill. And most individuals just don't generate much of this kind of paperwork anyway. Set up a system, use it consistently, and you'll be fine.

For the record, in my own system I have a file for each bank or credit account, plus files for "utilities," "household services," and so forth. Each January, I start new files and rotate the old ones to longer term storage.

Katherine

Comment

Honestly? I think it's a waste of time. In my experience, filing this kind of stuff is extremely straightforward. There may be a lot of ways to file most technical papers, but a phone bill is just a phone bill. And most individuals just don't generate much of this kind of paperwork anyway. Set up a system, use it consistently, and you'll be fine.

For the record, in my own system I have a file for each bank or credit account, plus files for "utilities," "household services," and so forth. Each January, I start new files and rotate the old ones to longer term storage.

Katherine

Um...I also worried this would be too time consuming compared to the benefit. I tend more to stick to a plain alpha system; it may just be a paranoid in the back of my mind that I need to know exactly what's going on in any aspect, any time, any where, even my file drawer.

I have a system like yours too - Utitilies, Bills: Comcast, Bills: Cingular, Statements from my old & current bank....

Would you think of any particular advice on their names? As you see, for example, I set the bills as a general subject, followed by specifics.
My impression is, I should name the folder as the first name/word/phrase I would think of when I need that material. Do you think it's a good approach?

Comment

My impression is, I should name the folder as the first name/word/phrase I would think of when I need that material. Do you think it's a good approach?

Yes. What else would you call it?

The less obvious the name, the more likely you are to need an index/database to help you find things.

In my own system, I name financial files by the account holder, then by the type of account:
Direct Federal - Checking -- 2007; Direct Federal - Mortagage -- 2007; and so forth. I don't have much trouble remembering which accounts are assets and which are liabilities, so don't bother including that in the file title.

Comment

The less obvious the name, the more likely you are to need an index/database to help you find things.

In my own system, I name financial files by the account holder, then by the type of account:
Direct Federal - Checking -- 2007; Direct Federal - Mortagage -- 2007; and so forth. I don't have much trouble remembering which accounts are assets and which are liabilities, so don't bother including that in the file title.

Katherine

Thanks Katherine. These are tangible opinions, and confirmations to kill my paranoid. There's a tendency to go for a "formal" name (...too much used to categories stuff in my old thinking), instead of going for intuition. This is onward training though.

Thanks so much for your help along

Comment

Though I too am a devotee of GTD, for anyone with handy access to a computer there is a vastly superior filing system than the method David describes in his book, which is perfectly serviceable...if you can remember the name, contents, and hierarchy of every folder you ever created. I used that system for years and got sick of stumbling across redundant file folders that I'd forgotten about here or there, or ones legitimately filed under a different name but directly related to the exact same project or client.

A better system, IMHO, is to use any software that can be text-searched and which ideally has a time/date stamp feature, plus a cardboard box. When it's time to file something, time/date stamp an entry in the text file
with a few keywords, then time/date stamp the item itself and throw it in a cardboard box which is sitting on end by your desk. Every month burn a backup copy of the text file. When the box fills up, label it and get another. Every three years, print out a list of the stuff in the oldest box, highlight the items you want to keep, pull them and throw out the rest. In just a minute or so, I can find any piece of paper I've filed using this system for the past several years.

If you have a bunch of papers associated with a given project, grab a sheet of 11 x 17 paper, fold it in half, and time/date stamp it. Insert documents, then do your keyword entry and time/date stamps. You can buy paper that size inexpensively at any office supply store. It takes up much less space and is far cheaper and lighter than manila folders. Keep outsize or odd objects like VHS tapes or fat reports in a separate box but integrated into the same data file. Keep legal documents and contracts, insurance policies, etc. in a fireproof box but also enter them in the system.

So the software question is answered simply: which has the two features you need (text search, time/date stamp) and is such second nature to you that you don't even need to think about it?

Comment

Though I too am a devotee of GTD, for anyone with handy access to a computer there is a vastly superior filing system than the method David describes in his book, which is perfectly serviceable...if you can remember the name, contents, and hierarchy of every folder you ever created. I used that system for years and got sick of stumbling across redundant file folders that I'd forgotten about here or there, or ones legitimately filed under a different name but directly related to the exact same project or client.

A better system, IMHO, is to use any software that can be text-searched and which ideally has a time/date stamp feature, plus a cardboard box. When it's time to file something, time/date stamp an entry in the text file
with a few keywords, then time/date stamp the item itself and throw it in a cardboard box which is sitting on end by your desk. Every month burn a backup copy of the text file. When the box fills up, label it and get another. Every three years, print out a list of the stuff in the oldest box, highlight the items you want to keep, pull them and throw out the rest. In just a minute or so, I can find any piece of paper I've filed using this system for the past several years.

If you have a bunch of papers associated with a given project, grab a sheet of 11 x 17 paper, fold it in half, and time/date stamp it. Insert documents, then do your keyword entry and time/date stamps. You can buy paper that size inexpensively at any office supply store. It takes up much less space and is far cheaper and lighter than manila folders. Keep outsize or odd objects like VHS tapes or fat reports in a separate box but integrated into the same data file. Keep legal documents and contracts, insurance policies, etc. in a fireproof box but also enter them in the system.

So the software question is answered simply: which has the two features you need (text search, time/date stamp) and is such second nature to you that you don't even need to think about it?

Thanks for your advice. I don't quite get the cardboard box idea. In the software side, I did some research, ranging from using excel spreadsheet, to building my own database in Access (regret that I know too little VBA to customize it).

This is some kind of "database" in its own right. So, the same question remains: provided the dynamic nature(physical locations, desired filing options, usage, validity) of some material, it takes quite an extensive effort to maintain a up-to-date database - be it cardboard or spreadsheet.

It's just my anticipation. Since you have been doing it for years, may I know how you tackle this problem? or it does not ever exist in your case?

Firstly, I have one of those plastic briefcase-file things, which has a click-latch to close it, a handle to carry it, and 12 separate sections. In this I put all my financials, by month. All of them. At the end of the financial year, I've got it all ready to pack up and see the accountant, then archive with my tax statement.

Why do I do this? Well, I found that if I needed any of my papers, say a phone bill, I probably also needed the corresponding bank statement. And if I didn't, I knew that I needed February's phone bill, so I could easily find that by looking in the February section of my financials file. The file thingie just sits in front of my file drawer.

Then for everything else, I've got an alpha system in broad categories (which have sticky-up labels), then components of each broad category. So for example my Car category contains various folders such as Insurance, license, maintenance and repair, and so on. I don't bother to arrange these alphabetically because there's only about half a dozen sub-categories for anything. So I look in the centre for the main category label, then leaf through individual folders for the exact item. Easy.

Oh, and I don't use hanging files because they're noisy and inconvenient, and so my file drawers just have folders kept straight using a bookend.

My suggestion: don't set up a database. You probably won't maintain it, at least not as scrupulously as you need to, and once it's out of synch it's basically useless.

And think carefully about your nomenclature - think about why you'll need to retrieve something, which will give you a clue as to how to name things. Don't feel you 'should' name them something just because that's the header at the top of the page, and don't use something that someone else uses without thinking hard about whether it would work for you. Work it out for yourself, because that's the only way you'll be able to find things.

Comment

When I first started GTD, I also had a simple 26 folders with A-Z labels. When I needed to file something in that alpha file, I simply dropped it into the respective alphabet folder. I also had a simple database where I typed in the name of that item, and any notes, including expiry date of that item. It was simpler than pulling out a manilla folder and punching in a typeset label to stick on that folder (what do you do with that manilla folder and label when the item expires?). If your computer is on all the time next to your filing system, it is as simple or simpler than typing in the labeler.

My database was a modified Access book catalogue database (comes with the program as a sample). The advantage is that you can periodically print off a list of everything in your General Reference filing system, note which ones are expired, and purge them.

I attach it for your evaluation. The sample data can be deleted.

Regards

Frank

Oh, a problem with attaching the zip file even though it's only 147kb. I'll email to you as private message.

Comment

o I've found the simple A-Z works great for most people. No index, no software, etc. This makes filing and retrieving fast.
o I think that indexing file content generally isn't worth it - it slows down creating and retrieving, and usually doesn't warrant the extra effort. YMMV, though...
o In addition to the home-grown computer indexing methods mentioned above, there are dedicated programs to do indexing, e.g., http://thepapertiger.com/

In general, I'd recommend the less is more approach, which underlies much of Allen's thinking...

Comment

I also agree that maintaining an index is too much overhead. Just use a basic file system as described in the book.

The file name should be the thing you will think of when looking for the item. If you think of it as "phone bill" then file it like that. If you think of it as "Sprint Bill" then use that. If you want to find it under "Utilities - Phone" or "Bills - Phone" then use one of those. It doesn't really matter. Just be consistent. Once you set up the system the first time, you will find it much easier to maintain because you will have settled on your naming conventions. Worst case is you have to look in 2 or 3 different alpahbetical locations before you find something and even that will only take a minute. Probably no longer than the time it takes to first refer to the index and then find the correct file. You don't have to be perfect the first time you name something, either. The important thing is to get everything filed. If you later decide to change some file labels, then do so at that time. No big deal. The thing you want to avoid is having half your car stuff under "car" and half under "automobile" and the final half under "Ford" and a few other things under "maintenance" and one receipt under "oil changes". Be consistent. When this happens, pull it all together, decide on a single naming convention that makes sense and reorganize it all into one or more folders that are consistent.

If you find that using a label maker takes too much time when creating a new file, you may decide that handwriting labels is a good alternative for you.

When using hanging folders, don't be reluctant to add new ones as needed to handle the bulk. DA advises using one hanging folder for each file. That may not be absolutely necessary, but don't restrict yourself to one per letter of the alphabet. If "M" is 4 times thicker than "Z", it is fine to have 4 or more hanging folders for "M".

Comment

At the moment, I agree with most that maintaining a database takes more time/effort than its benefits, especially when the volume of my system is not so big.

Frank has sent me a good Access database he derived himself. If later it really grows into a big volume, or some big project needs detail tracking, I'd consider separate that from my main general reference, and use his derived database to track those specifics.

In the mean time, I think staying simple would be good for a general filing.

Thanks again for the insights on nomenclature. It's really helpful and vital, as I've been struggling with that for a while. It's hard to stay consistent on everything in the beginning. Still appreciate more sharing & advices - thanks in advance.