Single Large Database vs Multiple Single Topic DBs

Gestartet von: am

Beitrag #1 -
Single Large Database vs Multiple Single Topic DBs

As I am in the process of maximum use of AMN (with conversion of many notes from OneNote and Evernote), I would like to have experienced perspective on the following organizational question:

What are the pros and cons of having one large DB (database) with many subjects as Tree items vs multiple smaller DBs restricted to their own topics?

Large DB might be

MyData

HEALTH TOPICS

FINANCIAL TOPICS

PROJECT TOPICS

vs

HEALTH DB

EXERCISE TOPICS

DIET TOPICS

DISEASE TOPICS

and

FINANCIAL TOPICS

BUDGETING TOPICS

INVESTING TOPICS

SAVINGS TOPICS

and ETC. Please tell me your experiences and opinions on this. I certainly will appreciate your advice.

Thanks,

Ken

Beitrag #2 -
Re: Single Large Database vs Multiple Single Topic DBs

I sure wish I could see some replies to this question. It seems an important one, especially to those just starting out with AMN.

If you see this and have some insights, please reply.

Thanks much,

Ken

Beitrag #3 -
Re: Single Large Database vs Multiple Single Topic DBs

Usually we recommend single storage file and multiple folders within it to categorize your data. This way you can have all your data searchable and available for browsing at all times. There is no performance issues - AllMyNotes keeps all data on a disk, it only loads currently edited note, so no need to worry about anything. No matter how your data file is, it start up instantly and uses minimum of RAM.

Beitrag #4 -
Re: Single Large Database vs Multiple Single Topic DBs

I'm a writer, with various projects going on at the same time (e.g., technical writing project, fiction story, someone's blog articles, etc.)

What I've found most practical is to have 1 "Personal" AMN database, and numerous dedicated separate files for each main project.

A "project" can be, say, a client or it can be a particular group of articles.

For example:

"My Diary" handles to-do lists, dates, reminders, quick ideas, and whatever goofy stuff I want to remember while I'm on the computer.

"ABC Corporation" is a client who hires me to write an instruction manual for an in-house software application.

"Great Novel" is a book I'm hoping to publish someday. It can have rough ideas for things, or written drafts. I can have a folder for "Characters," and do the character development. I can have another folder (in the same file) for "Chapter Outline," with summaries of each chapter to come. And so forth. I generally write the actual chapter in something like MS Word, because it has to be submitted to copy-editors and publishers, who may not have AMN.

Another dedicated file might be, "American Blog," where I do the same as with the novel, only ideas for articles to post as a guest author. "Clients" might be a Folder in my "Diary" database, with separate sub-folders for each blog site (if I have multiple different blogs at a time) or client.

I can link to "file" from within my own Diary, and open that particular database easily.

Each database can easily insert links to either somewhere in one file, or to another file entirely. The "global search" feature helps me to find out whether Johnny Badguy is a smoker or non-smoker.

I've used various outliners and information managers, but have always missed InfoSelect. Now, with the modern AllMyNotes, I get the best of all worlds. So my recommendation has to do with how your mind processes information.

1. Determine major categories of entire bodies of information (like the clients, projects, books, diary, etc)

2. Choose the same folder on your computer to store all the AMN databases. Makes it easier to backup everything to a stick drive.

3. Name each database file with a recognizable filename so you can find it easily in generic file explorers.

4. Divide each database in its own Tree structure, with "large" but not global categories.

So a book might have a Folder for all Chapters, but another folder for each article, character, or whatever.

This makes it easy for multiple submitted articles to the same place. For example, if I have an individual file for "Blog Writing," I can have separate Folders for "Blog 1," Blog 2, and Blog 3. Under "Blog 1," I can have sub-folders for "Article A," Article B, Article C.

Then I can have a sub-folder for "Payments." So

File: Blog Writing.

Folder: American Industry

Note: January article

Note: February article

Folder: Political Ninja

Note: November elections

Folder: Payments

Note (or sub-folder): American Industry - article title, submitted date, invoice amount, expected payment receipt. What's nice is these can each have "checkbox" events to keep track.

Organize your mind, and the computer will follow along. :-)

Beitrag #5 -
Single large database and multiple smaller databases

I use a combination of both. I treat each database like a digital filing cabinet. I have multiple subfolders for each database. I also use the checkboxes and like to include images pertaining to the information in the databases. I also use tables in my databases.

Beitrag #6 -

Thanks, Jewel, for chiming in - nice to see this 2019 thread still alive, proving that "one database vs many" is basically the eternal question of note-taking. To sum up what Ken, CraigL, and Jewel have all said - everyone's right at the same time, they just landed on different trade-offs. There's no universal answer here, only what fits how your own brain organizes things. Personally, I keep one database for everything - personal and work - just split into folders. The main reason is simple: global search looks across everything at once, so I never have to guess which of five files I jotted something down in three months ago. There was one exception, though. At some point I had a project that came with a ton of attachments - gigabytes of the stuff. I didn't want to keep that in my main database for two reasons: first, backups of the main file were getting bloated by data I wasn't even touching anymore; second, the project itself was temporary, and honestly by now I barely remember the details - the file just sits there as an archive, in case I ever need to dig it up. So, short version: 1. If the data is actively used and belongs together conceptually - one file, folders for structure, let search do the heavy lifting. 2. If some chunk of data is heavy (lots of attachments) or inherently temporary/project-based - split it into its own file, so you're not bloating 3. backups with stuff you've already forgotten about. 3. Every year or two, take a look at whatever "temporary" file is still sitting there - otherwise it'll stay "temporary" for the next five years.

Antwort veröffentlichen

Anonym posten: Ihre Nachricht wird von Moderatoren geprüft, bevor sie öffentlich erscheint.
Formatierung: [b]bold[/b] [i]italic[/i] [u]underline[/u] [url]link[/url] [quote]text[/quote] [code]code[/code] [img]url[/img] [list][*]item[/list]
Bitte antworten Sie mit „NEIN“, damit Ihre Nachricht zugestellt wird!