Build a database

[PeterKegels]

Is it better to have a lot af tables for data or 1 tabe for all data?

 

[pr2-eugin]

Could you explain a little bit in detail what you wish to do?

 

[plog]

It's a trick question. The correct answer is to have a normalized database : http://en.wikipedia.org/wiki/Database_normalization

 

[jk42]

I'm sort of facing the same issue. I have been reading a TON of articles and from an Access book, and it seems like sometimes you can decide to forgo normalization in some case. I have ZERO building experience, so maybe I am misunderstanding. But in my instance, I have a tblProjectDetails that is really what I'm trying to track, and there are some categories that will be repeated on several lines for any number of the projects in the database:

tblProject Status-and there will be three things -terminated, completed, in progress-
tblProjectPhase- and the only entries are I, II, III, IV
tblprojectcategory-__,___, and ____

Would it make it easier for me to just have those values repeated in the tblProjectDetails, for each project entry? It seems like setting up three more tables is a lot more work! However, i do want to be able to search by phase and category, so does that affect how I need to set them up?

Peter, sorry to piggy back your question, but maybe this will help you, too!

 

[ButtonMoon]

Don't create new tables for single attributes unless you need them. The main reason for creating such tables is if the valid domain of values for those attributes needs to be updated frequently at runtime. Based on what you've said I suspect you don't need tables for the Status and Phase attributes.

Don't neglect normalization though. Aim to design your database to at least Boyce-Codd / 5th Normal Form except where you find reason to deviate from that. For the avoidance of doubt, normalization has nothing at all to do with moving an attribute with "repeated" values into a new table. Normalization is purely and simply about dependencies between attributes; ensuring those dependencies are accurately supported by keys in your tables.

 

[jk42]

Thanks, ButtonMoon. That helps alot. Actually, That may change a lot of things for me! This entire database centers around Projects. I kept breaking things up because that's what all the books told me to do. But honestly, this entire database surrounds "Projects." Once the data is entered into the table-it will NOT change-as it is just historical facts I'm keeping track of, with the exception of maybe project managers, employees, and client contact, finance numbers associated with it, and maybe one more thing.

Does that mean that I can keep everything in one table, except for the above mentioned things? When I draw my tables out on paper, ALL of them relate back to TblProjects.


I can upload a picture if that will help.