ERD Diagram, splitting data into separate table?

[shez]

Ok from a normalisation point my table is Ok i.e. only has fields that depend on the primaryId! but there are so many rows that I was thinking if i should separate the table? for example:

details(id, fn, ln, addressId, dob, tel, mob, email, password, newsletter, showCV, workType, contractType, Salary, experience)

and from that table remove some rows and create new tables such as:

work(workId, workType, contractType, Salary, experience)
site(siteId, password, newsletter, showCV)

even if you think that having all these fields is acceptable as there are only 16 rows, I have another database where I have exactly the same problem but if i dont split table in that db, i will end up having 20+ rows!

 

[MarkK]

Row is synonymous with record. Column is synonymous with field. Do you think you have too many columns?
It doesn't make sense to me to split a table based on an arbitrary count of fields. If, in order to be complete, a record requires 100 fields, then it does.
I just think that in the real world this will almost never happen.

 

[gemma-the-husky]

details(id, fn, ln, addressId, dob, tel, mob, email, password, newsletter, showCV, workType, contractType, Salary, experience)

and from that table remove some rows and create new tables such as:

work(workId, workType, contractType, Salary, experience)
site(siteId, password, newsletter, showCV)

you may have a point with this but it depends

the reason for removing the fields worktype contracttype salary and experience from the main table, and putting them in a separate table, would be that you have repeating groups of similar information in that table

but (eg) you are separating out both worktype and contracttype

now, then you have to consider the relationship between these - are these really two different attributes - or is there a single jobtype that encompasses BOTH worktype and contracttype - or is contracttype DEPENDENT on worktype (oe vice versa). ~Only you can know the answer to these questions, for your system

in the second case you are separating password, newsletter and showcv etc. its real hard to see how these can all be part of the same entity, and therefore belong together - but again its your system, and they may do

 

[shez]

you may have a point with this but it depends

the reason for removing the fields worktype contracttype salary and experience from the main table, and putting them in a separate table, would be that you have repeating groups of similar information in that table

but (eg) you are separating out both worktype and contracttype

now, then you have to consider the relationship between these - are these really two different attributes - or is there a single jobtype that encompasses BOTH worktype and contracttype - or is contracttype DEPENDENT on worktype (oe vice versa). ~Only you can know the answer to these questions, for your system

in the second case you are separating password, newsletter and showcv etc. its real hard to see how these can all be part of the same entity, and therefore belong together - but again its your system, and they may do

They do belong together because if a user uses my website, they will have a password, option to opt in/out of a newsletter and similar to showing their cv..

The point I was trying to make is if you have some "attributes" that all depend on one thing i.e. ID, is it appropriate to still split them up because as far as normalisation is concerned I shouldn't.

 

[gemma-the-husky]

but you are talking about removing rows, which should never be necessary

neither rows nor columns want removing for the sake of it - but they do want separating if they are not normalized

The point I was trying to make is if you have some "attributes" that all depend on one thing i.e. ID, is it appropriate to still split them up because as far as normalisation is concerned I shouldn't.

but this is wrong - if you have attrbutes in a table dependent on ID (repeating groups) then the IDs and associated attributes SHOULD be separated out, with just the id left in the main table, as the foreign key