What is the best coin collecting software

[TomGoodheart]

I'd happily use something simple and free! But I hated learning about databases and SQL and have no desire to revisit even Excel if it requires much work! Currently I have two Excel sheets, one arranged in Spink reference number order (ie it's a stock list of my collection and concludes with a total 'value' of what I've spent) and the other in order of the date I aquired the coins and is primarily to show how much I have left to spend on coins! Neither has photos, but does name where I bought the coin, when and how much for.

The coins have a ticket each with basic details (type, weight, date of purchase and from whom and price) and then I keep any paperwork such as receipts or printouts of the ebay listing as physical evidence of my purchases.

Finally I occasionally print a record of all my coins as thumbnail photos. I only have 68 coins in total, so it's not so difficult. If I had hundreds then clearly it would be a different matter!

Ideally it would be nice to have somewhere that holds everything, but it's frankly a bit daunting to have to start all over and I'm lazy!

[Colin G.]

I would be interested to know how you get on with image/Ole fields in open office. I have always used MS Access 2002 because of the simplicity with displaying relational pictures in forms.

However any upgrade (as I have found again with MS Access 2010) always seems to have problems displaying my images because of the software associated with the creation of the image file originally.

The solution is to start coding up a solution, but I just can't be bothered at the moment, too many other things going on!! I would be interested to know how open office handles image data, or if anyone else has already solved such an issue?

[Peckris]

Okay, have tried out a few things now on my Mac to create a custom coin database/spreadsheet:

Filemaker Pro looks quite powerful, but I found it quite intimidating as a new user, would also be a little concerned about "locking-in" to the Filemaker format, though I guess I could just use it as a front-end to MySQL. It's also quite expensive.

Believe me - if you found FMPro intimidating, MS Access is no easier, in fact it's more complex to learn. The upside of the learning curve is that once you get some confidence with it, you'll start using it for loads of things. As for the cost, yes if you buy the latest version it is expensive, but I got the previous version from Amazon (new, sealed) for significantly under £100, which for a full-featured relational database is not at all poor value.

As a Mac user already there is no downside to being "locked in" to FMP (I've used it since 1994) especially when you consider there are multiple export formats including Excel.

[Oxford_Collector]

Okay, have tried out a few things now on my Mac to create a custom coin database/spreadsheet:

Filemaker Pro looks quite powerful, but I found it quite intimidating as a new user, would also be a little concerned about "locking-in" to the Filemaker format, though I guess I could just use it as a front-end to MySQL. It's also quite expensive.

Believe me - if you found FMPro intimidating, MS Access is no easier, in fact it's more complex to learn. The upside of the learning curve is that once you get some confidence with it, you'll start using it for loads of things. As for the cost, yes if you buy the latest version it is expensive, but I got the previous version from Amazon (new, sealed) for significantly under £100, which for a full-featured relational database is not at all poor value.

As a Mac user already there is no downside to being "locked in" to FMP (I've used it since 1994) especially when you consider there are multiple export formats including Excel.

Okay, I might give FMPro another go, I downloaded a 30-day demo and still have time remaining on this. BTW does FMPro have visual tools (like MS Access, Open Office, Navicat etc.) for defining the relations between tables etc.? Is the form-buider relatively easy to use? Any other tips? Thanks

[Oxford_Collector]

BTW have noticed that there is currently a promotion to purchase a download of the FileMaker Training Series for FileMaker 11 at the special promotional price of US$9.99 (normally US$99 ) until March 15, 2012, so I might look into acquiring this...

[Peckris]

Okay, have tried out a few things now on my Mac to create a custom coin database/spreadsheet:

Filemaker Pro looks quite powerful, but I found it quite intimidating as a new user, would also be a little concerned about "locking-in" to the Filemaker format, though I guess I could just use it as a front-end to MySQL. It's also quite expensive.

Believe me - if you found FMPro intimidating, MS Access is no easier, in fact it's more complex to learn. The upside of the learning curve is that once you get some confidence with it, you'll start using it for loads of things. As for the cost, yes if you buy the latest version it is expensive, but I got the previous version from Amazon (new, sealed) for significantly under £100, which for a full-featured relational database is not at all poor value.

As a Mac user already there is no downside to being "locked in" to FMP (I've used it since 1994) especially when you consider there are multiple export formats including Excel.

Okay, I might give FMPro another go, I downloaded a 30-day demo and still have time remaining on this. BTW does FMPro have visual tools (like MS Access, Open Office, Navicat etc.) for defining the relations between tables etc.? Is the form-buider relatively easy to use? Any other tips? Thanks

The form builder has always been easy to use - you just specify which type you want (list, report, full data entry, etc), then just define fields or drag existing fields into place where you want them. You can go into Layout Mode any time and change things around, move fields, add more, delete, etc. And create new layouts (forms) whenever you want.

The relationship designer I don't know about - I built mine in the days when it didn't exist. However, whenever I've looked at relationships in FMP 10 I've noticed a nice visual chart showing how everything connects together. Therefore I'd make the assumption that such a thing exists at the design level also.

The good thing about FMP is that it's pretty destruct-resistant - you can make changes to most aspects of a database as and when you need or want to. But as with all database managers it helps to plan in advance as far as you can, it makes things a lot easier in the long run.

[Oxford_Collector]

Okay, have tried out a few things now on my Mac to create a custom coin database/spreadsheet:

Filemaker Pro looks quite powerful, but I found it quite intimidating as a new user, would also be a little concerned about "locking-in" to the Filemaker format, though I guess I could just use it as a front-end to MySQL. It's also quite expensive.

Believe me - if you found FMPro intimidating, MS Access is no easier, in fact it's more complex to learn. The upside of the learning curve is that once you get some confidence with it, you'll start using it for loads of things. As for the cost, yes if you buy the latest version it is expensive, but I got the previous version from Amazon (new, sealed) for significantly under £100, which for a full-featured relational database is not at all poor value.

As a Mac user already there is no downside to being "locked in" to FMP (I've used it since 1994) especially when you consider there are multiple export formats including Excel.

Okay, I might give FMPro another go, I downloaded a 30-day demo and still have time remaining on this. BTW does FMPro have visual tools (like MS Access, Open Office, Navicat etc.) for defining the relations between tables etc.? Is the form-buider relatively easy to use? Any other tips? Thanks

The form builder has always been easy to use - you just specify which type you want (list, report, full data entry, etc), then just define fields or drag existing fields into place where you want them. You can go into Layout Mode any time and change things around, move fields, add more, delete, etc. And create new layouts (forms) whenever you want.

The relationship designer I don't know about - I built mine in the days when it didn't exist. However, whenever I've looked at relationships in FMP 10 I've noticed a nice visual chart showing how everything connects together. Therefore I'd make the assumption that such a thing exists at the design level also.

The good thing about FMP is that it's pretty destruct-resistant - you can make changes to most aspects of a database as and when you need or want to. But as with all database managers it helps to plan in advance as far as you can, it makes things a lot easier in the long run.

Okay, had another play with FMP this evening, looks better than I originally thought, but will still take a little bit of time to get my head around, but could be worth persevering.

Am starting to think about table structures, needs tweaking, but here's where I've got to in terms of tables:

• Specimen (i.e. individual actual coin and/or perhaps coin set) - information about condition, how acquired/sold, estimated current value, look-up for location etc.
  
• Type - one record for each coin type, each coin type could have many specimens. Am not sure whether this means having a type record per date or just per series, though probably the former as mintage and Spink prices (and varieties...) will be specific to a year
  
• Series - not sure about this, but could perhaps have many type records with shared data (e.g. same obverse/reverse info., weight, size, composition) per series - most non-year/variety specific coin type data could go here
  
• Variety - - not quite sure about this one or whether can account for varieties within the Type table
  
• Set (can contain a number of specimens e.g. proof sets). Or could possibly have a proof set as a Type in itself and a Specimen in itself, not sure of best approach here
  
• Reign (for kings and queens, names, dates etc.)
  
• Mints - location and details of mints
  
• Location (for storage locations)
  
• Dealer/Customer - dealers I've bought from/customers I've sold to
  
• Reference - i.e. reference book details - Spink, Davies, ESC, coincraft etc.
  
• Bullion - table with current bullion values per oz/gramme so can automatically calculate coin Series bullion values
  

Obviously some of these would be combined in the layout views. What do you think? Overkill? Or have I missed something out? Will start in the fields next...

[Oxford_Collector]

Okay, have tried out a few things now on my Mac to create a custom coin database/spreadsheet:

Filemaker Pro looks quite powerful, but I found it quite intimidating as a new user, would also be a little concerned about "locking-in" to the Filemaker format, though I guess I could just use it as a front-end to MySQL. It's also quite expensive.

Believe me - if you found FMPro intimidating, MS Access is no easier, in fact it's more complex to learn. The upside of the learning curve is that once you get some confidence with it, you'll start using it for loads of things. As for the cost, yes if you buy the latest version it is expensive, but I got the previous version from Amazon (new, sealed) for significantly under £100, which for a full-featured relational database is not at all poor value.

As a Mac user already there is no downside to being "locked in" to FMP (I've used it since 1994) especially when you consider there are multiple export formats including Excel.

Okay, I might give FMPro another go, I downloaded a 30-day demo and still have time remaining on this. BTW does FMPro have visual tools (like MS Access, Open Office, Navicat etc.) for defining the relations between tables etc.? Is the form-buider relatively easy to use? Any other tips? Thanks

The form builder has always been easy to use - you just specify which type you want (list, report, full data entry, etc), then just define fields or drag existing fields into place where you want them. You can go into Layout Mode any time and change things around, move fields, add more, delete, etc. And create new layouts (forms) whenever you want.

The relationship designer I don't know about - I built mine in the days when it didn't exist. However, whenever I've looked at relationships in FMP 10 I've noticed a nice visual chart showing how everything connects together. Therefore I'd make the assumption that such a thing exists at the design level also.

The good thing about FMP is that it's pretty destruct-resistant - you can make changes to most aspects of a database as and when you need or want to. But as with all database managers it helps to plan in advance as far as you can, it makes things a lot easier in the long run.

Okay, had another play with FMP this evening, looks better than I originally thought, but will still take a little bit of time to get my head around, but could be worth persevering.

Am starting to think about table structures, needs tweaking, but here's where I've got to in terms of tables:

• Specimen (i.e. individual actual coin and/or perhaps coin set) - information about condition, how acquired/sold, estimated current value, look-up for location etc.
  
• Type - one record for each coin type, each coin type could have many specimens. Am not sure whether this means having a type record per date or just per series, though probably the former as mintage and Spink prices (and varieties...) will be specific to a year
  
• Series - not sure about this, but could perhaps have many type records with shared data (e.g. same obverse/reverse info., weight, size, composition) per series - most non-year/variety specific coin type data could go here
  
• Variety - - not quite sure about this one or whether can account for varieties within the Type table
  
• Set (can contain a number of specimens e.g. proof sets). Or could possibly have a proof set as a Type in itself and a Specimen in itself, not sure of best approach here
  
• Reign (for kings and queens, names, dates etc.)
  
• Mints - location and details of mints
  
• Location (for storage locations)
  
• Dealer/Customer - dealers I've bought from/customers I've sold to
  
• Reference - i.e. reference book details - Spink, Davies, ESC, coincraft etc.
  
• Bullion - table with current bullion values per oz/gramme so can automatically calculate coin Series bullion values
  

Obviously some of these would be combined in the layout views. What do you think? Overkill? Or have I missed something out? Will start in the fields next...

Missed one... Also was going to have a table for:

• Denomination (including fields like common name, short name, value, value unit e.g. "Half Crown", "2/6", 30, "d"
  

Edited February 20, 2012 by Oxford_Collector

[Peckris]

Okay, have tried out a few things now on my Mac to create a custom coin database/spreadsheet:

Filemaker Pro looks quite powerful, but I found it quite intimidating as a new user, would also be a little concerned about "locking-in" to the Filemaker format, though I guess I could just use it as a front-end to MySQL. It's also quite expensive.

Believe me - if you found FMPro intimidating, MS Access is no easier, in fact it's more complex to learn. The upside of the learning curve is that once you get some confidence with it, you'll start using it for loads of things. As for the cost, yes if you buy the latest version it is expensive, but I got the previous version from Amazon (new, sealed) for significantly under £100, which for a full-featured relational database is not at all poor value.

As a Mac user already there is no downside to being "locked in" to FMP (I've used it since 1994) especially when you consider there are multiple export formats including Excel.

Okay, I might give FMPro another go, I downloaded a 30-day demo and still have time remaining on this. BTW does FMPro have visual tools (like MS Access, Open Office, Navicat etc.) for defining the relations between tables etc.? Is the form-buider relatively easy to use? Any other tips? Thanks

The form builder has always been easy to use - you just specify which type you want (list, report, full data entry, etc), then just define fields or drag existing fields into place where you want them. You can go into Layout Mode any time and change things around, move fields, add more, delete, etc. And create new layouts (forms) whenever you want.

The relationship designer I don't know about - I built mine in the days when it didn't exist. However, whenever I've looked at relationships in FMP 10 I've noticed a nice visual chart showing how everything connects together. Therefore I'd make the assumption that such a thing exists at the design level also.

The good thing about FMP is that it's pretty destruct-resistant - you can make changes to most aspects of a database as and when you need or want to. But as with all database managers it helps to plan in advance as far as you can, it makes things a lot easier in the long run.

Okay, had another play with FMP this evening, looks better than I originally thought, but will still take a little bit of time to get my head around, but could be worth persevering.

Am starting to think about table structures, needs tweaking, but here's where I've got to in terms of tables:

• Specimen (i.e. individual actual coin and/or perhaps coin set) - information about condition, how acquired/sold, estimated current value, look-up for location etc.
  
• Type - one record for each coin type, each coin type could have many specimens. Am not sure whether this means having a type record per date or just per series, though probably the former as mintage and Spink prices (and varieties...) will be specific to a year
  
• Series - not sure about this, but could perhaps have many type records with shared data (e.g. same obverse/reverse info., weight, size, composition) per series - most non-year/variety specific coin type data could go here
  
• Variety - - not quite sure about this one or whether can account for varieties within the Type table
  
• Set (can contain a number of specimens e.g. proof sets). Or could possibly have a proof set as a Type in itself and a Specimen in itself, not sure of best approach here
  
• Reign (for kings and queens, names, dates etc.)
  
• Mints - location and details of mints
  
• Location (for storage locations)
  
• Dealer/Customer - dealers I've bought from/customers I've sold to
  
• Reference - i.e. reference book details - Spink, Davies, ESC, coincraft etc.
  
• Bullion - table with current bullion values per oz/gramme so can automatically calculate coin Series bullion values
  

Obviously some of these would be combined in the layout views. What do you think? Overkill? Or have I missed something out? Will start in the fields next...

Missed one... Also was going to have a table for:

• Denomination (including fields like common name, short name, value, value unit e.g. "Half Crown", "2/6", 30, "d"
  

Interesting - most of those fields iI've included in my main data entry layout. Then I have other layouts for Spink values in several grades. And separate list-style layouts for location, buying details, selling details, etc. Not to mention a print layout for taking to the library to look up Spink values. And so on.

I have related files for auction lots, and for the history of Seaby/Spink values since the 1960s, and for coins in sets. But really, how you set it all up is entirely on what you want to see. My main external file is for pictures, as I want to keep the main database fairly small aa manageable. I have a relationship (Coin ID number) that ties each coin to its picture, and the picture appears in any layout I've defined that relationship in (only one, in practice).

[Oxford_Collector]

Okay, have tried out a few things now on my Mac to create a custom coin database/spreadsheet:

Filemaker Pro looks quite powerful, but I found it quite intimidating as a new user, would also be a little concerned about "locking-in" to the Filemaker format, though I guess I could just use it as a front-end to MySQL. It's also quite expensive.

Believe me - if you found FMPro intimidating, MS Access is no easier, in fact it's more complex to learn. The upside of the learning curve is that once you get some confidence with it, you'll start using it for loads of things. As for the cost, yes if you buy the latest version it is expensive, but I got the previous version from Amazon (new, sealed) for significantly under £100, which for a full-featured relational database is not at all poor value.

As a Mac user already there is no downside to being "locked in" to FMP (I've used it since 1994) especially when you consider there are multiple export formats including Excel.

Okay, I might give FMPro another go, I downloaded a 30-day demo and still have time remaining on this. BTW does FMPro have visual tools (like MS Access, Open Office, Navicat etc.) for defining the relations between tables etc.? Is the form-buider relatively easy to use? Any other tips? Thanks

The form builder has always been easy to use - you just specify which type you want (list, report, full data entry, etc), then just define fields or drag existing fields into place where you want them. You can go into Layout Mode any time and change things around, move fields, add more, delete, etc. And create new layouts (forms) whenever you want.

The relationship designer I don't know about - I built mine in the days when it didn't exist. However, whenever I've looked at relationships in FMP 10 I've noticed a nice visual chart showing how everything connects together. Therefore I'd make the assumption that such a thing exists at the design level also.

The good thing about FMP is that it's pretty destruct-resistant - you can make changes to most aspects of a database as and when you need or want to. But as with all database managers it helps to plan in advance as far as you can, it makes things a lot easier in the long run.

Okay, had another play with FMP this evening, looks better than I originally thought, but will still take a little bit of time to get my head around, but could be worth persevering.

Am starting to think about table structures, needs tweaking, but here's where I've got to in terms of tables:

• Specimen (i.e. individual actual coin and/or perhaps coin set) - information about condition, how acquired/sold, estimated current value, look-up for location etc.
  
• Type - one record for each coin type, each coin type could have many specimens. Am not sure whether this means having a type record per date or just per series, though probably the former as mintage and Spink prices (and varieties...) will be specific to a year
  
• Series - not sure about this, but could perhaps have many type records with shared data (e.g. same obverse/reverse info., weight, size, composition) per series - most non-year/variety specific coin type data could go here
  
• Variety - - not quite sure about this one or whether can account for varieties within the Type table
  
• Set (can contain a number of specimens e.g. proof sets). Or could possibly have a proof set as a Type in itself and a Specimen in itself, not sure of best approach here
  
• Reign (for kings and queens, names, dates etc.)
  
• Mints - location and details of mints
  
• Location (for storage locations)
  
• Dealer/Customer - dealers I've bought from/customers I've sold to
  
• Reference - i.e. reference book details - Spink, Davies, ESC, coincraft etc.
  
• Bullion - table with current bullion values per oz/gramme so can automatically calculate coin Series bullion values
  

Obviously some of these would be combined in the layout views. What do you think? Overkill? Or have I missed something out? Will start in the fields next...

Missed one... Also was going to have a table for:

• Denomination (including fields like common name, short name, value, value unit e.g. "Half Crown", "2/6", 30, "d"
  

Interesting - most of those fields iI've included in my main data entry layout.

Sure, but if understand it, a layout is just a "view" on the data and can be made up of data from many tables, which are necessary to avoid data repetition, which is a big no-no if being strict about relational database design...

Then I have other layouts for Spink values in several grades. And separate list-style layouts for location, buying details, selling details, etc. Not to mention a print layout for taking to the library to look up Spink values. And so on.

I have related files for auction lots, and for the history of Seaby/Spink values since the 1960s, and for coins in sets. But really, how you set it all up is entirely on what you want to see. My main external file is for pictures, as I want to keep the main database fairly small aa manageable. I have a relationship (Coin ID number) that ties each coin to its picture, and the picture appears in any layout I've defined that relationship in (only one, in practice).

Sounds sensible, does it allow for many pictures per coin specimen, though?

Here's a stab at some of the fields I was thinking of for each table, needs some work, though (and probably simplifying...):

Specimen

--------

TypeID

LocationID (FK)

DealerID (FK)

CustomerID (FK)

SetID (FK)

Die Number

Weight?? (although this can probably go in type for post-1816, unless weighing individual coins)

Grade

Graded by (drop-down - include self, dealer, cgs, pcgs etc.)

Slab Serial No.

Further Remarks (e.g. colouration, dents, nicks, scratches, patina, toning)

(Variety?)

Valuation

Valuation Date

Valuation Source

Price Paid

Date Acquired

Where Acquired

Who Acquired From - DealerID (FK)

Sold (Yes/No)

Date Sold

Where Sold

Who Sold To - CustomerID (FK)

Holder (e.g. cardboard 2x2, "air-tite", "PCGS slab", 2x2 Saflip)

Comments

Sell?

Upgrade?

Quantity? (e.g. for bullion coins)

Obverse Image

Reverse Image

(or Image filename (repeat field))

Document Filename (for PDFs of scanned receipts etc.)

Type

-----

TypeID

MintID (FK)

SeriesID (FK)

Date

AlternateDate (e.g. Gothic)

Die Variety?

Mintage

ReferenceID (repeat?) (e.g. Krause, Coincraft, Spink, Davies, Seaby, Marsh, Gouby etc.)

ReferenceNo (repeat)

Rarity? (e.g. from ESC)

Mint Mark (Drop-Down?)

Values (repeating field):

Spink FDC

Spink BU

Spink UNC

Spink EF

Spink VF

Spink F

Edge - Milled/Plain/Design/Letters (or have this in series?)

Finish - Proof, Burnished, Uncirculated etc.

Comments?

Series

------

SeriesID

Series Description / Common Name

Country (drop-down) - or look-up in a country table?

ReignID (FK)

DenominationID (FK)

Weight

Diameter

Thickness

Composition e.g. Gold, Silver, Bronze (or may reference bullionID, so can retrieve and calculate bullion value)

Fineness (e.g. 0.925)

Troy Weight?

Bullion Value? (calculated)

Obverse Description

Reverse Description

Obverse Legend

Reverse Legend

Designer - Obverse

First Year Obverse Issued

Designer - Reverse

First Year Reverse Issued

Die Axis (i.e. coin/medal) - or does this go with type?

Comments?

Reference

---------

ReferenceID

ReferenceName

ReferenceAuthor(s)

ReferenceYear

Reference ISBN

Publisher

Comments

Owned? (yes/no)

Location

--------

LocationID

LocationName

LocationDescription

Comments

Dealer

------

DealerID

Name

Address

Website

Email

Phone

Specialities

Comments

Rating :-)

Customer

--------

CustomerID

Name

Address

Website

Email

Phone

Comments

More tomorrow...

[Rob]

This seems far too complicated e.g. separate fields for each grade unless that is you intend to obtain many examples of the same coin. A lot of the info you have listed isn't something you would want to search which would be the main reason for keeping field data separate. It would be far better to keep most data in a simple file containg all the data you would never need to search. Unless that is you have a system like Declan who can undoubtedly tell me that a coin struck in brass, in VF grade, that cost £2.74, is dated 1914, weighs 4.3g, that has a Spink reference number of 1234, gives you a value of 42. (Sorry Douglas)

[Oxford_Collector]

This seems far too complicated e.g. separate fields for each grade unless that is you intend to obtain many examples of the same coin. A lot of the info you have listed isn't something you would want to search which would be the main reason for keeping field data separate. It would be far better to keep most data in a simple file containg all the data you would never need to search. Unless that is you have a system like Declan who can undoubtedly tell me that a coin struck in brass, in VF grade, that cost £2.74, is dated 1914, weighs 4.3g, that has a Spink reference number of 1234, gives you a value of 42. (Sorry Douglas)

Yes, I see your point… though I'm still wondering whether to keep the main hierarchy I've outlined here i.e.: coin series -> coin type -> coin specimen or whether to flatten this structure?

[Paulus]

This seems far too complicated e.g. separate fields for each grade unless that is you intend to obtain many examples of the same coin. A lot of the info you have listed isn't something you would want to search which would be the main reason for keeping field data separate. It would be far better to keep most data in a simple file containg all the data you would never need to search. Unless that is you have a system like Declan who can undoubtedly tell me that a coin struck in brass, in VF grade, that cost £2.74, is dated 1914, weighs 4.3g, that has a Spink reference number of 1234, gives you a value of 42. (Sorry Douglas)

[Paulus]

This seems far too complicated e.g. separate fields for each grade unless that is you intend to obtain many examples of the same coin. A lot of the info you have listed isn't something you would want to search which would be the main reason for keeping field data separate. It would be far better to keep most data in a simple file containg all the data you would never need to search. Unless that is you have a system like Declan who can undoubtedly tell me that a coin struck in brass, in VF grade, that cost £2.74, is dated 1914, weighs 4.3g, that has a Spink reference number of 1234, gives you a value of 42. (Sorry Douglas)

Yes, I see your point… though I'm still wondering whether to keep the main hierarchy I've outlined here i.e.: coin series -> coin type -> coin specimen or whether to flatten this structure?

Are we talking about hundreds or many thousands of coins? If the former (for me, 700 or so), Excel works perfectly well with all the fields (flattened if you like) into columns and hyperlinks to your photos either on your PC or on the interweb, I think unless you want to learn about relational database design and use (as a separate hobby almost!), they only come into their own when handling sizeable quantities of data

[Oxford_Collector]

This seems far too complicated e.g. separate fields for each grade unless that is you intend to obtain many examples of the same coin. A lot of the info you have listed isn't something you would want to search which would be the main reason for keeping field data separate. It would be far better to keep most data in a simple file containg all the data you would never need to search. Unless that is you have a system like Declan who can undoubtedly tell me that a coin struck in brass, in VF grade, that cost £2.74, is dated 1914, weighs 4.3g, that has a Spink reference number of 1234, gives you a value of 42. (Sorry Douglas)

Yes, I see your point… though I'm still wondering whether to keep the main hierarchy I've outlined here i.e.: coin series -> coin type -> coin specimen or whether to flatten this structure?

Are we talking about hundreds or many thousands of coins? If the former (for me, 700 or so), Excel works perfectly well with all the fields (flattened if you like) into columns and hyperlinks to your photos either on your PC or on the interweb, I think unless you want to learn about relational database design and use (as a separate hobby almost!), they only come into their own when handling sizeable quantities of data

At the moment only a few hundred coins, but growing... but only a small percentage of that is actually the "good stuff". Perhaps you're right and I'm being over-ambitious and should just try to Excel route for now... BTW it is possible to make Excel relational (sort of), if necessary - each of the "tables" could be represented in its own spreadsheet in the same workbook. The sheet names reflect the table names. The column headings reflect the field names. There's more information about this here: http://www.tushar-mehta.com/excel/newsgroups/rdbms_in_excel/index.html

[declanwmagee]

You can also do ridiculously complex stuff within Excel with INDEX, MATCH, and VLOOKUP, without having to feed it out to MSQuery. I have, as Rob quite correctly alluded to, flogged Excel to within an inch of its life in order to avoid real RDBMS work!

I drove myself close to the brink of insanity with dBase III about 20 years ago and haven't been back in that direction since learning Lotus 123 soon after that. It'll always be spreadsheets now.

Edited February 21, 2012 by declanwmagee

[Peckris]

Interesting - most of those fields iI've included in my main data entry layout.

Sure, but if understand it, a layout is just a "view" on the data and can be made up of data from many tables, which are necessary to avoid data repetition, which is a big no-no if being strict about relational database design...

Then I have other layouts for Spink values in several grades. And separate list-style layouts for location, buying details, selling details, etc. Not to mention a print layout for taking to the library to look up Spink values. And so on.

I have related files for auction lots, and for the history of Seaby/Spink values since the 1960s, and for coins in sets. But really, how you set it all up is entirely on what you want to see. My main external file is for pictures, as I want to keep the main database fairly small aa manageable. I have a relationship (Coin ID number) that ties each coin to its picture, and the picture appears in any layout I've defined that relationship in (only one, in practice).

Sounds sensible, does it allow for many pictures per coin specimen, though?

Well, I have Obverse and Reverse defined in the Pictures database, but you could have a third - Variety - or a fourth, or as many as you want.

As for data repetition, yes it would be good practice to avoid it, but my own coins database pre-dates FMP becoming relational !! And for - e.g. Location - it's just one field and would be overkill to have a separate table for. I simply choose one of 4 or 5 values from a drop-down value list.

This seems far too complicated e.g. separate fields for each grade unless that is you intend to obtain many examples of the same coin. A lot of the info you have listed isn't something you would want to search which would be the main reason for keeping field data separate. It would be far better to keep most data in a simple file containg all the data you would never need to search. Unless that is you have a system like Declan who can undoubtedly tell me that a coin struck in brass, in VF grade, that cost £2.74, is dated 1914, weighs 4.3g, that has a Spink reference number of 1234, gives you a value of 42. (Sorry Douglas)

Not necessarily - my own interest in how Seaby/Spink prices have changed since the 60s means I need to see them in all quoted grades whichever grade my own coin is in. It also means that when I upgrade, there's no further lookup of price required.

[Guest Leigh]

Liberty is fine until you need support, then you are on your own, had to give up using it which is a shame as it's a neat data base.

[garry1]

Recommend you to look at this article - Best ways for warehouse optimization - leading technologies for inventory maybe it's not the same, but I think that someone who have enough money could make special app for coin collecting to share with new purchases, for communication etc. 

[garry1]

Recommend you to look at this article - Best ways for warehouse optimization - leading technologies for inventory maybe it's not the same, but I think that someone who have enough money could make special app for coin collecting to share with new purchases, for communication etc. 

[AlinaKem]

This article could be also useful https://erminesoft.com/app-development-process-from-idea-to-application/ . 

[alexblack]

Thank you for sharing. Excellent articles. I found a lot of interesting things

Edited May 25, 2017 by alexblack

[hazelman]

On 2/13/2009 at 2:01 AM, Kronos said:

Ok, I have finally settled with Coin Manage UK from Liberty Street Software, it's just so easy to add a scan of your coin. Still running with an Excel spreadsheet though, just for the posterity.

Kronos what have you finally settled on?

[Peckris 2]

1 hour ago, hazelman said:

Kronos what have you finally settled on?

You waited 9 years to ask that? 

[Rob]

Kronos hasn't posted on the forum for 8 years.