If you're talking about a project/business that has access to a person who knows how to "database analyst" (to mis-verbify a noun), then I'd definitely have to go with using SQL (or whatever other free database solution the DA is familiar with).
Here's how I got into databases and how it worked for me:
I was in sales and marketing for a small business. I was one of two salespeople in the whole company (which had, if I remember correctly, about 15 employees, tops). There was no means of keeping track of customers and orders, except when an order was placed, it would be put in a manila envelope and kept on someone's desk. So I started an Excel spreadsheet to keep track of my own customers, their contact data, their order history, etc.
The spreadsheet rapidly became too large and complex for easy use, so about a month after starting that, I decided to check out this "Access" product. I'd used flat-file databases before, at prior employers, but no relational databases, and wasn't even sure what "relational" meant.
Access was very easy for me to learn and get some decent use out of. Took me a couple of weeks of playing around with it between sales calls and such, and I had something that would work for my needs.
By this time, we were up to six salespeople, and the other five all wanted to use my Access app too, as they saw me using it. So I struggled through the help files and, again in very part-time work, got it set up so the database was on the server and the front end could work from any workstation in the company.
Functionality expanded. Features were added. Management wanted access to the data in it. The production and delivery departments wanted access to the upcoming jobs stored in it (what we sold, they had to produce and ship). Payroll wanted access to it for commissions data. And so on.
Rapidly, it became clear that too many users made it unstable and we were running into concurrency issues routinely.
So we upgraded to SQL Server. By that time, I had a good idea on how a relational database should work (as opposed to how I started out) and the migration to SQL took only a couple of days.
It's been five years since I started out trying to build something to keep track of my own customers, and it's been 3 1/2 years since I actually had any customers of my own to keep track of, since I was moved to full-time system development.
The application still has an Access front-end, the back-end is SQL Server 2000 Enterprise, and we have some very feature-rich .NET Web pages on the same database (though I don't do the pages).
I'm in the process of working out how to move to SQL 2005 and a .NET front-end (probably C++).
That kind of path, starting with easy-to-learn Access, moving to SQL when/if the application grows in use and functionality and importance, is very good when you don't have someone available/affordable to build a "real database" right off the bat. Also, if the database never ends up being mission critical, and stays small and easy to maintain in Access, you've invested less time and effort.
After all, experienced database analysts are much more expensive than having someone in Sales spend half an hour building something in Access.
Keep Up with TechRepublic