help with making a database in Access 2007

[QueBert]

I run a home business and all I've ever done is just invoices, not the most efficient way to look up crap months after I've done if it I need to. I'm an access n00b, I did watch a few tutorials on Youtube, but couldn't find one that got to the point though. I'm going to design something pretty simple, it will contain invoice numbers, with the basic client information and an attachment link to PDF copy of the actual invoice so I can look up what I did for the client.
I plan to do some sort of basic front end form to make it search able, but really this seems pretty basic as far as DB's go. My questions are these.

Should I use more than 1 table? I was thinking 1 table with a couple forms would be all I need. I have a fair amount of invoices from the past 3 years, but I don't know if I plan to input the data from them. I generally have 3-4 jobs a week, so the database shouldn't get big at all. Also, does what I described wanting to do seem like the best way? I know for a good DB you need to plan it out well. I created a Word document with a list of all the fields I'd imagine I need. Right now I'm reading up on relationships and what to do and not to do. I figured there would be at least a few DB wizards on here who either have some knowledge they could drop on me, or point me to a good resource. I'm messing around with the form design view right now trying to make it look uber. When all's said and done I want to have a front end where you wouldn't even know it was access. But I want the back end to be done right. Am I making more out of this then I need to be in terms of how involved I think it's going to be? When I started I figured I could read a lil and knock this out in a few hours, now I'm wondering how much time exactly this is going to take.

 

[EagleKeeper]

1 table for the list of clients (Possibly another table with just the City/State)
1 table for each client invoice

If you go with the city/state table, you will need a linkage to that in the client table

In the invoice field, you need a linkage to the client.
I usually use a number that I have assigned to the client - either numerical (1,2,3) or some unique number code.

This way, for the invoice, you are not duplicating the client information and can avoid typing/spelling mistakes.

To design the database should take no more than a couple of hours if you have already given thought to the fields that you need..
To design the input forms will be up to your skills and how fancy you want them to be.
Remember, you can always jsut enter the data raw if you have problems with the entry forms.
Report Forms will be even easier to initially design.

 

[QueBert]

thank you for the reply, I didn't think about having it create a new table for each invoice. The linkage to a client is also an excellent idea I didn't think of. I do work for a lot of the same companies and either what you said, or a drop down box with a list of them that auto fills most of the fields would be a huge time saver. I think the designing will take me much longer because I absolutely suck at Access, it's not logical at all to me. I'm still reading up and watching some tutorial so I can get a grasp of how it works. I'm use to free flowing programs, and DB's definitely don't fall into the creative category I'm good at lol.

You have given me some things to think about, I definitely need to do more reading and planning before I try to start on it.

 

[EagleKeeper]

Consider a client screen that will fill in/update the fields w/ exception of the customer id #.
A dropdown list of city to remove the potential of typos - looks professional if the city is spelt properly

Them a screen that replicates what your invoices look like.

A dropdown list of the clients with auto fill the client information for the invoice printing.

I would recommend that you start from what you have already on paper and then transfer it to forms/reports until you are comfortable with rework. And at that point, you will have more insight into the workings and what you desire.