Filemaker can do all of these things if you or a consultant designs the database to do it. When you purchase filemaker, you'll get a series of template files and one or more of them might be adapted to do what you need or you can design from a "blank page" to create what you want. Either approach requires you to either invest time and effort in creating such a database or you will need to hire someone to do it for you.
To get a more complete picture of what Filemaker is like, download their free trial copy and see what you can or can't do with it. If, after downloading, you encounter questions about what you are doing, feel free to post them here.
Perfect. Will do. I'm pretty new to databases (databasing?), but totally willing to learn.
Starting with one of the free templates that FileMaker comes with or looking at some of the more professional ones is also a good start (see my company's shameless advertising signature below).
The key to choosing FileMaker over and "off the shelf" package like Act! or Daylite to run your business is that FileMaker is completely customizable and can be programmed to fit your specific business requirements.
Also, the FileMaker community offers a wide array of professional developers that can help you build and maintain your software as your business needs change which makes it very hard to outgrow FileMaker as a platform.
I will chime in with the rest of the gang in saying FileMaker will suit your needs. You may want to look at http://filemakerfree.com to see if one of the suggested free starters does everything you want.
One of the advantages of using a template file to start from is that it already has some of what you need. One of the disadvantages is that it often also has things you don't need, or is just done differently from what you need. The FileMaker template that looked closest to what you need is Task Management, in the Business Projects folder. It has 3 levels in a Project; Project, Task, Assignment.
I am generally not too crazy about the FileMaker templates. They could use a bit more folders in the scripts (bunches of sorting scripts in every table), etc.. I use a slightly different field naming convention; but theirs is OK. I do not really agree with their relationship naming convention however. Repeatedly using the word "related" in a table occurrence (relationship) name seems redundant to me.* I use a strictly structural-alphabetical naming convention. But some of this is just personal; the relationships look correct, which is what matters.
One of the big troubles with templates is that if you already knew how to modify one quickly and cleanly to suit your needs you probably wouldn't need one in the first place :-] But it could give you some idea.
I would also recommend just using the template to give you an idea of what the basic relationship and operations look like, then building your own simpler version. You will learn more that way, and get less caught up in the extras which you may not need (at first anyway).
1. A "timesheet" kind of entry has both the "person working on something", the "something", and the "person who's paying for it" (optionally, often this is implicit in the "something" worked on). ALL of these are IDs only; because each of them occurs multiple times, and also exists in its own table higher up in the hierarchy. It could be thought of as a join table, but it is an entity of its own, because of the date-time.
Such a table can be looked at from several points of view. From a Client, from a Project, from an Employee. It can also be reported on directly, on a layout of its own table, using Subsummaries (which work very cute in FileMaker 10 :-).
You very seldom enter anything more than once in a well-designed database.
2. A separate Addresses table, linked to the people, would have the 2 addresses. You would do the mailing from that table. In databases you do not often have "blank" entries (address 1, address 2). That is what related tables are for.
*I am sorry to offend whoever built all these example files (quite a while ago). It is likely impossible to build something that makes sense to all levels of developers, and definitely impossible to build something everyone likes.
Yes, all this is possible and I agree completely with Phil. Regarding your first question, simply think of the system as "zero balance". The hour billed to your client is in effect the same hour you pay out. If you pay out for example $20.00 to a tutor and $5.00 to yourself and charge $25.00 per hour, everything billed gets paid out, whether to you or your employees. I pay a lot of people in any given year. The software sees me the same way it sees the people I pay. IN=OUT is the way to go. It's fairly simple to set up a check printing routine that doesn't print one out for the user while still accounting for the user's "income" but pays everyone else (as an example).
Regarding multiple addresses for students, I would set up two address tables. One tracks Billing or Mailing address, another residence . . . or whatever you like. Unless of course you'd like to send out a bill to both addresses. I wouldn't go for that (you could get paid twice!). This way you have a table of addresses that are used for a given purpose. You don't need to use "IfIsEmpty . . ." "then" scenarios to calculate the appropriate address. You can continue to keep all this info created and sorted under Student name. You can have "Parents' Name" fields in this table. You can flag the billable parent (which would then use his/her address).
my two cents,