it all depends.
its not just the cost of the application software, its also about other stuff such as your abilities, your experience, how secure the app needs to be. who uses the app. who looks after it after you move on.
personally ive never heard of zoho, zengine and caspio (had to look 'em up). Ive doen and seen stuff in open office which is fine for most things. I think OO tries to achieve the inverse pareto law, ie it does 80% of the functionality for 20% of the codebase, or is that 90:10, or 97:3.. the numbers don't matter but what does is that things like OO can do virtually all of the common everyday tasks required of a db but doesn't have some of the more esoteric (and therefore less frequently used) features. Im guessing that zoho, zengine & caspio are trying to do the same sort of thing but using 'the cloud'. but unless another contributor here ahas experience of those 3 items you will have to do your own research and prove that either way.
anything cloud related makes me nervous about data security (if you have some data which is personal or professional eg names & address, contact details or professional accreditations then you may well have to take steps and demonstrate adequate steps to protect privacy. so security is important. so you know who changed what and when, you control who has access to what.
in an abstract way what you want to achieve is relatively trivial, but thats like going to a tool shop and asking if they have a tool to do something.. the answer is yes, but you haven't provided enough information to give a meaningful answer
to be honest I think you will be better off developing the business requirement case forget about the implementation details and focus instead on what is required
what outputs do you need (ie what information, roughly in what style. eg a paper report identifying people qualified to level X in what categories
what information do you require to achieve those goals
how the system should hang together (who does the data entry, reporting and so on, what are the ecuirty implications / requiremments)
..effectively scope the project, understand what needs to be done before doing the project
..whilst you are in that process learn up and use normalistation & good db design techniques. the followijng are my oft used read this list, but there are others just as good if not better
Unless you have a lot of experience I wouldn't start by playing with a specific tool / software, identify the software tool required after identifying what actually is needed. if you are already up to speed with db design then by all means do use a software tool to flesh out your design ideas, but don't let the software tool coerce a specific approach when the project requires a different approach
spend more time with text and diagrams up front nearly always means spending less time in development and a higher chance of delivering a successfull project (and often on time/on budget). invovle others in the requirements definition phase. far too often I see one man band applications which meet a specific persons perspective of 'the' problem, but don't meet the organsiations overall perception of the problem. ferinstance its very common to find applciations which are financial or operationaly focussed at the expense of any other perspective becuase the sponsoring department is financial they only 'see' the financial side of things so the systme works for that mndset but not for the organisations actual day to day operational use.
I'd rather be riding on the Tiger 800 or the Norton