I am trying to have a lean database size, so I thought that if an input, which will always be a string, should be checked for its value type and therefore saved in a specific table that is appropriate with its type. Meaning if an input represents a string, then it should go to a table that saves string, or if an input represents a number, then it go to a table that saves integers or precision numbers. In context, these tables serve the same purpose all together, to save a value corresponding to an input and another table that is related to the input.My questions are is this a good approach to what I am trying to achieve, and if so, how can I achieve this without complicating my code?I am currently using .Net framework and entity framework, but I can take out entity framework if needed be. Thanks for all the help.Edit:I should have mentioned that my application follows a question-answer relationship, where the answer varies in data-type: string, number, datetime, etc.Edit:Here is what I was thinking:If the input is a string, save it to a table that has a string column; if numerical, save it on a table with int column; if date time, save it on a datetime column. If the answer needs to be accessed, it will be accessed according to the data type of the answer.Because of the answer below by Robert Harvey, I realized that I am overcomplicating my design for the sake of saving storage space, and I am using more unnecessary data which will just be against what I was trying to achieve in the first place.
Selective table CRUD depending on value
c#;relational database
If an input represents a string, then it should go to a table that saves string, or if an input represents a number, then it go to a table that saves integers or precision numbers.Fundamentally, a table represents a collection of entity objects.  An Entity is simply the representation of a thing, so a table is a collection of similar things having different properties.  For example, a contact manager manages contacts (lists of people and places).  So you might have a Contacts table, a Persons table, and a Places table, with tables or keys that relate the records in each table to records in other tables.Each record in a table represents a single entity instance.  So the Persons table contains a Person record for each person you want to represent.  While Person is considered a type, it's not the same kind of type as a string or number.  It is a complex type, whereas strings and numbers are simple types. It's clearer, then, to think of a table as a list of records of a specific complex type, and each record as a list of simple types.  So your Person record would contain a string that holds the person's first name, a string that holds the person's last name, a datetime that holds his birth date, and so on.In Entity Framework, you will have a single class for each table.  This class is the code representation of a record in a table in the database.  So you will have a Person class that represents a Person record in the database table.  This class will contain a property for each field in the table, such as LastName, FirstName and BirthDate.