Just some loose remarks:
- What dbms will you be using? SQL implementations aren't so uniform that it does not matter (and in such a small db interoperability is probably unimportant?).
- It seems unwise to name a table with 'index' or an '_index' suffix. An index belongs to a table but it is something separate (it isn't even part of the SQL specification; indexes are just an implementation detail that may or may not speed up a retrieval from a table).
- The data you describe are so small (hundreds of rows) that performance and indexes are unlikely to be important considerations (small tables are always seqscanned). Concentrate on getting easy-to-understand queries.
- Your option 2 (everything in one table) is called EAV and is generally frowned upon (see for instance this). I think eav is only defensible when a 'table structure' needs to be extremely flexible (and the structure is unknown beforehand), and this is not the case for you).
Maybe you should try to show us the SQL-'hairiness' that you fear. It probably isn't as bad as you think :)
In reply to Re: OT - SQL choosing a schema for index tables
by erix
in thread OT - SQL choosing a schema for index tables
by bangor
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |