Why Majority Collector Use Spread Sheet ?

I was wondering why majority Collector use Spreadsheet than
databases. (relational database). Though it is understandable
now a days each spreadsheet has over million and 40 thousand rows.

tikithindi :)

In my case it's very simple - I know how to build a basic spreadsheet but I don't know how to build a database. Spreadsheets are commonly used in most day-to-day office jobs, so many people are generally familiar with them. Databases not so much. I think that's a lot of it, right there. And, for my purposes, spreadsheets work just fine.

Most people have the "How to get the job done with the least amount of effort" approach.

When I was at work, after routinely creating electronic mayhem when asked to "input to this spreadsheet", I made my colleagues' lives easier by scrawling information on paper, handing it to them, and saying, "You put it in, old chap". Consequently, I use my memory or, sometimes, catalogue-scrawling. A database would be way, way beyond me.

tikithindi, here are my top 3 reasons collectors use a spreadsheet vs. database. BTW, I'm basically agreeing with what the others already posted:

1. It's the right choice for the project: For most of the "here's my collection" projects, a spreadsheet is perfectly sufficient. While a relational structure might help (minimally,) it's really not necessary in most cases.

2. Familiarity, cost, availability & ease of use: There are plenty of free & easy-to-use spreadsheet programs out there, including Google Spreadsheet. Most people understand intuitively how to use a spreadsheet, but would be lost trying to set up relational tables for a database. The design of forms, queries, etc. is also not particularly straightforward (without prior experience in database development.) Virtually all versions of virtually all office suites come with a spreadsheet app, but not all come with a database app.

3. Increasing sophistication of (even the free) spreadsheet programs. They now offer pretty complex data manipulation capabilities (e.g. pivot tables) which allow for pretty good analysis with a straightforward "drag and drop" or "checkbox" approach.

I'm a research scientist by training and used a lot of database programs in my day (still use Access for personal projects and my website is MySQL driven.) I'm familiar with what's required to set up a good relational database and create the other supporting pieces (forms, queries, etc.) Having said that, the "overwhelming" use of spreadsheets for most stamp collecting projects does not surprise me at all. I find myself using Excel for virtually everything else in my stamp business.

For instance, I recently went through 3,000 USA Scott 807a booklet panes (3c Presidential,) each showing a portion of a plate number. An Excel spreadsheet w/ pivot table to sort, count, display any which way I want (by plate number, by position, by percentage, etc.) is perfectly adequate...and quite honestly MUCH easier/faster than creating a database for that project!

I use the best of both worlds (I am a programmer - so...it's a bit easier for me)

I input everything into a spreadsheet (my inventory), but then I wrote tools that sync the data to the database on my website so it is also stored in a way that can be queried for my site.

The reason I input into a spreadsheet is because there is no better general purpose data entry tool ever built.

I agree with the previous posts but will narrow the reasons down to two words: Simplicity and Flexibility. Unless one is a programmer or a computer expert, a spreadsheet is so much simpler to create and manage.

Some years ago I had opportunity to learn some relational database programs but never quite got the hang of it. Since I can create and access virtually the same data via use of a spreadsheet in much less time (because of already having a working knowledge of the program) it makes it the obvious choice.

Besides, should things change in the future, my data is very simply converted via any number of data transfer protocols.

Thank you very much to all. For replies and hints. I asked only reason was sometime ago
I had created Access database for stamp collection inventory. Unfortunately crash of my computer and Health issue. I postponed meantime thought would ask others for opinions. I almost felt same way as srailKb, wt1,eric and all other who answered. appreciate very much for your time.

thanks again

tikithindi

I document my collection and started off with a spreadsheet approach (I use the LibreOffice suite).
One of the things I wanted to do was have images of my stamps and soon struggled with getting images into the spreadsheet (tried many approaches - hyperlinks etc.)
This encouraged me to try the database part of LibreOffice and I have now got a very workable database of my 14,000+ collection. I am even learning a little bit of SQL queries which is very powerful.
This hobby is a very visual one and images are therefore high priority for me. (I can easily add postmark images to my database for example)
Like some of previous posters, I am definitely not a computer expert but have taught myself enough to get this database going quite well.

If you make a Google Sheets spreadsheet, you can access it from pretty much anywhere. Not so with a database.

Hello! Sounds like most of you pass on purchase/use of stamp software apps for inventory tracking.
Does anyone think that having the stamp image built in to these apps provides a reasonable approach for cataloging collections?
Are such software tools useful in searching for specific "haves" or "missing" issues?
Since I am only now consolidating my US collection into a soon-to-be-purchased hingeless album, I see cataloging as a natural next step.

hi dcaraz1949,

any Images if at all. than it is in its Folder(Directory).
Could have been listed either name wise or mostly as numerical
and ".JPG" or any graphic file extension. One can build that
with the images.

tikithindi

hi Conker and apastuszak,

I like both approaches. could we say now a days we can make
use of best of both spread sheet and LibreOffice, Mysql or any
Database. (if Databases schema is model Relational hopefully )
One can use Php, VB, VBA, c# .NEt etc any for it.


tiktihindi

Spreadsheets are like a 'checkers' game while a relational database is more like a 'chess' game. In other words, relational database require a lot of fore thought, planning, and thinking several moves ahead while spreadsheets are more of a 'on-the-fly' kind of thought process.
Don

TheArtfulHinger not only nailed it, but reminds of when, back in the 1980s, I was trying to choose between two database programs, RBase & DBase.

RBase had the better yichus (lineage), as it was a mainframe program being ported down to XTs. DBase was developed for the PC market, and was enjoying greater commercial success.

I finally ran across a freelancer who programmed in both RBase & DBase, and he assured me that anyone I asked would always recommend the one they already knew.

Around the same time, I ran across a few financial types who were composing business correspondence in VisiCalc because WordPerfect was a whole 'nother learning curve.

Q/ Correct me if I am wrong, but don't the 'integrated suites' allow you to open your database in a spreadsheet? For some operations - performing a similar edit on a number of records - this always seemed easier ;)

Cheers,

/s/ ikeyPikey

The data (rows and columns) can certainly be exchanged between databases and spreadsheets but the OP asked a specific question about relational databases. Chances are good that are that some here actually do not really understand the difference between a 'database' and a 'relational database'.

A relational database uses multiple tables with 'keys' between them to associate the data; they are NOT simply a big table with huge amounts of data. There are very good reasons to use a relational database over a single database structure. It greatly improve performance, stability, and flexibility.

As an example let me briefly describe how the Plate Number Tool (in Stamp Smarter) is structured as a relational database. In one table the fields include things like Scott Number, denomination, color, description, printer name. In another table the fields includes Scott number, plate numbers. This design was intentional because I understood the 'many-to-one' nature of the plate numbers. When a user looks up a single Scott number, the combined data is presented from both tables.

This kind of functionality is difficult to replicate into a single spreadsheet. Databases are the proper way to this kind of functionality, not spreadsheets. This is why truly powerful apps, major corporations, and things like the APS library and this very forum all use relational databases and not spreadsheets for storing valuable data while spreadsheets are considered a 'desktop' tool.
Don