Simple Canada Stamp Database.

Hi guys...Got bored and made this database for you Windows users to input your Canadian stamp information...Before I send it to anyone that could use it, please see if there are other titles I am missing..Any input is appreciated...See what it looks like now below...Thanks

I can make it up to 5000 lines or more if necessary...And tell me if you are going to PM me.

A column for catalogue value? and acquired price? (to gloat on the difference?)

sak...Could we not input that into a comment area as I have just added..??...The only trouble with catolog value is that every year it might change and I don't think I want to go back and update 4000 comments...haha




Maybe add the year stamp was introduced...??

For Canada, change first column to Unitrade no.

I would love to Gilles le timbre but isn't it officially a Scott numbering system...??

Perhaps inclusion of Souvenir Sheets, Coil Strips and Booklets is needed to cover most of the possibilities so you have a better idea of what's in the collection.

If you can sort the table by SC #, then items can be added and/or deleted as necessary and more understandable if in numerical order.

Wert,
You need a 'unique' ID column in any database. This is an automatically assigned unique identifier for each row. The 'catalog' number column is not going for this purpose. (You will end up wanting to have multiple rows for a catalog number. You might have one row for a single stamp and one row for same stamp in a block of four.)

Change Scott # to catalog number and allow database to handle any catalog the user desires to input. This also gets you around the copyright and trademark issues with catalog numbers. If you push forward with a specific catalog number column you will need to get permission from the publishers. I can tell you right now few will allow you to publish this database with their numbering system in it.

Add column for 'qty issued'.

Add column for 'date issued'.

Remove limit for 5000 rows. (Again, one row not for each catalog number but rather for each stamp/stamp format/on cover stamps a person might have in their collection.)

'# of stamps' is not a good database field, you want one row for each stamp. For example, how can you enter 'Condition' for multiple stamps? (Not to mention this is not how relational database are constructed).

Other than the 'comments' field you need to restrict how user enter data into each field. In other words, make drop down for every field, requiring user to select the exact value form a list. If you do not, users will enter inconsistent data. For example, one row might contain '1944' and another just '44'. The queries/filtering/sorting would then not work correctly.

Related to the above comment; a big part of database design is about the 'field' type. You need to define each column specifically. A date column value be stored in many ways in a database. Same with numeric value (you can actual assign a text format to a numeric field if desired). This become critical when trying to do anything with other databases. If you have stored data in your database as one type of field, and another database has basically stored the same data but with a different field type assigned, you will struggle to ever get the two databases to 'talk ' to each other.

Consider breaking down this effort to multiple tables instead of one huge file. This will help with performance and data entry later down the road.

If you would like some help with the best way to design and structure a relationship database let me know.
don

In every other stamp organization/nomenclature, Perf horz. PRECEDES Perf vert.

Perhaps a column that allows you to put a link to your stamp picture, especially usefull for special details, re-entries etc...

Good point Gilles.
Wert did not supply a lot of information about his intent for this tool. Although both can store similar data there are huge differences between a spreadsheet and a relational database. If he is looking to build a real foundation for a good, portable database that includes the ability to grow and improve, then he should consider a real database. If he is only trying to distribute a spreadsheet template with no plans on it growing or being used by a lot of different people, then he should stay with a simple spreadsheet.

In general databases use links to images; ideally this held in a separate table and not included in the primary table. The reasons for this is performance; large text fields can cause longer load/search times.

If Wert wants to stay with the spreadsheet approach, there are ways to actually embedded the image in the spreadsheet itself. The challenge here is to not clutter up the spreadsheet with various sized images. One solution is to tap into a tool like Excel has to 'pop-up' an image. Here is an example that demonstrates this
http://dd-designs.co/dnloads/Displa...upStamp.xlsx

don

Ok...I was just throwing it out there for people to see if there is a need/want to have something small like this..I will pull it off line for now and maybe down the road I will enter some more information...I know it needed a lot more than I showed on this post, but was trying to get a feel is it was even worth while going deeper..Oh well..Guess there is lots of $$$ software programs for you guys to buy that at far more superior than what I was trying to do..for now I lay it to rest...

Wert - I would leave it up. People can often tweek these to suit their own needs, and it looks like an awesome base.
Please continue to share it. Some of the guys at the club I attend do the very same thing. For a beginner, a spreadsheet like this may be just what they need.

Way to go creating it!!

Well..I have been adding and taking away..Here is what it looks so far for all its worth.





WITH COMMENTS

I like it! Well done. Is the file available to others on the forum?

guykickinit...I have to add one more thing and that is a cell/button that will link the Unitrade # to the actual stamp(s) picture, then I will gladly give it to anyone..Its not the quality of store bought, but it will be free.

Wert,

I'm late to the party of "what about this", but here goes

Thanks for sharing this--I like the topic.

I myself created a custom Excel spreadsheet which I use; and originally I began with an exhaustive "boil the ocean" approach--then retreated to a less is more approach. You've gone beyond my spreadsheet and I am envious and admiring of it.

There was one thing that jumped out compared to my little data base : the value. In my case, I put in a column for the catalog value (Unitrade) and what I paid for the item. I also include the date for this later field. Obviously, I don't do it for every single stamp. And I don't have a time machine to go back in time. But I find it handy to fill in going forward, so I have this. And in some cases, I've gone back on my old invoices and input the high dollar value. I am not sure you or others will find this suggestion interesting--but for me (I have a financial background), I like having this data. As an aside--it helps for the total value sum too, for insurance or the like. And also, I hope having some data for future inheritance on what was paid for an item my help someone cull the cream from the bottom, so to speak.