Taking relationships to the extremes

[panchristo]

It has occured to me sometimes and I thought I should discuss to get your opinion:

Let's suppose one faces the following:

1) One main table with several related at the periphery,

2) many fields per secondary table (3050)

3) sometimes more than one record from each peripheral table related to the main one,

4) difficulties for reporting (sorting, space-saving)

5) flexibility for data export.

Do you consider the structuring of data in fiewer tables in the manner of data tagging a viable solution?

For example, I guess that for data tagging in a child table, one would need the same amount of different "stationary fields" in the parent main table to produce the relative tagged childs. In the afore-mentioned situation (200+ fields) it would produce a huge amount of extra fields to maintain the tagging.

In real-life terms, imagine a situation where you would need to document pathological characteristics found in human skeletons in standardized fields for every bone, together with other types of information for all the bones of the skeleton in other tables, all summing up to a great number that would need to accompany each skeleton in a concise report...

Is this considered a viable practise, or a no-go?

Is more flexibility (in use) worth such hassle in the developing level?

Would anyone go that way?

[bcooney]

Sorry, your question is too abstract for me. Can you be more specific?

I especially encourage data modeling questions, bcs this is where the majority of systems fail. You must get the model correct or you'll paint yourself in a corner.

It's helpful to work backwards from the report that you'll need. Also, remember that a temp reporting table can be used to gather records from several child tables into one for reporting.