Very simple DB, and confirmation of which app to use
I'm reasonably versed in creating DB's in anything from Access to Oracle but would just like a second opinion...
I'm creating a new db for my employers to store all data relating to our clients and the projects/jobs that we are undertaking:
1 Client can have N projects
1 Project can only have 1 Client
So keeping it really simple (for possible future expansion) I have two tables:
Date of contact
Client Number (FK)
Client First Name
Client Second Name
Status (In progress/completed etc)
Are my two tables normalised as best as possible?
I'm thinking WAMP or LAMP are the best tools to do this, am I right?
For a front-end, I can just output/query with strings through a browser, but can I host this on a private network and it will function like it does on a website?
Have I missed anything as I'm very rusty?
P.S. I really want to avoid the use of Access/Excel as (a) Excel 2010 is a shocker and full of bugs and (b) this database is going to be pretty darn large and I'd prefer a more malleable application.
Why carry the client's name in projects table? You already have the FK on client number. Also, it would allow for the name to be put in differently than it was put into the client table.
I don't know what kind of projects you are working on, but are you sure you wouldn't want a project for multiple clients? For instance if your projects are computer processes, you could easily have a client with the same requirements for a project that you already did for another client, then you could use a lot of the same project info and not have to reinvent the wheel on each project. The same re-use can be applied to other types of projects.
Each project would definitely be unique to the client, no two projects are ever the same they are always custom/bespoke. So on that front no, but thanks for asking.
As for duplicating the Client Name in the Project table, should that be removed you think...I see your point but when viewing a project it would be useful to know exactly which client we are dealing with, even if it is data redundancy.