Big Fat Greek Flat-File -- best structure?

[GKChesterton]

I want to compare 300 violins, let us say, and for each violin I want to record 200 specified characteristics -- certain length measurements, summary analyzes of tone, historical details, and so on. This makes for an awkward large table.
X axis = Violins (300)
Y axis = Violin Qualities (200)

I could use a flat-file table, or I could use multiple tables. If multiple tables, a large tabular view could be obtained using a cross-join query.

CROSS-JOIN: My experience tells me I'm in for some frustrations. If all V/Q combinations have data, everything's easy; but where the combinations or intersections of the data have nulls, it will be awkward. I've considered a maintenance routine that will ensure all combinations are handled, even if an empty string is all that's there. So if you add a new violin, you run the routine to add 200 records to the main data table.

FLAT-FILE: The whole thing becomes easier to handle in Excel -- although to collate the finished data and present it in non-tabular format, it's back to Access.

Can anyone give me a classic best approach for this? I haven't ever had satisfaction from the pivot-table functions, but could they be helpful? Is there a Cartesian product solution? And am I in the best forum?

For your interest, my project is an in-depth comparison of functionality for manufacturing/business software (ERP). Resource planning logic is well-defined in many ways, but there are some fundamental options in paradigm and approach, scope and scale. Collating information in a way that accounts for differences forces me into fairly loose and general descriptions of functionality. So the actual data is unwieldy.

[purple]If we knew what it was we were doing, it would not be called
research [blue]database development[/blue], would it? [tab]-- Albert Einstein[/purple]​

 

[Remou]

Why not a table of characteristics, a table of violins and a table of violin characteristics?

 

[PHV]

Have a look here:

http://r937.com/relational.html

http://www.devshed.com/c/a/MySQL/Understanding-SQL-Joins

Hope This Helps, PH.
FAQ219-2884
FAQ181-2886

 

[GKChesterton]

Remou: Yes, those would be the multiple tables. The question then turns to efficient access and handling.

PVH: I have spent time on both those sites. It would be great to understand SQL from the inside out, and my respect for the language has double-doubled since venturing into MySQL. Still I'm weak. I've normalized a lot of data without being able to describe much theory, and very inefficient work it was. Anyway, you don't want to humor my "shortcut-to-understanding" approach?

[purple]If we knew what it was we were doing, it would not be called
research [blue]database development[/blue], would it? [tab]-- Albert Einstein[/purple]​