One of the things that annoys me about many common RDBMSs is that they do not support the concept of domain.
Dom... what?
Domain the set of possible values for a given data element (ie column) - remember that RDBMSs are all about set theory - relation are interscetionsbetween sets.
In your case the domain for the attribute values are all given as "whatever can be represented in 10 characters", which probably is not the case. Your attributes will have different domains (sets of possible values) - even though you would encode them all in a 10 character wide text column.
Handling domains with care, ie. taking care not to store different domains in the same column, not joining columns that have diffent domains and so on; ie. in general not comparing apples and oranges and not storing cats and apples in the same keg; simplifies the care and maintainance of your database - just like in all programming.
In your case I would look carefully at the data, consider what changes are likely, possible, unlikely, improbable and impossible - and try to make a clean database design based on those factors. Trying to optimize access to the data beforehand nearly always causes more trouble later - you know "measure first, tune later".
Try to get hold of a good textbook on vendor neutral database theory (ie not a manual for your RDBMS) and read on normalisation, optimisation and so on. Database design is a fine art, that can only be learned by correcting your own mistakes ;-)