Question

I currently have a model Feature that is used by various other models; in this example, it will be used by customer.

To keep things flexible, Feature is used to store things such as First Name, Last Name, Name, Date of Birth, Company Registration Number, etc.

You will have noticed a problem with this – while most of these are strings, features such as Date of Birth would ideally be stored in a column of type Date (and would be a datepicker rather than a text input in the view).

How would this best be handled? At the present time I simply have a string column “value”; I have considered using multiple value columns (e.g. string_value, date_value) but this doesn’t seem particularly efficient as there will always be a null column in every record.

Would appreciate any advice on how to handle this – thanks!

Answer 1

There are a couple of ways I could see you going with this, depending on your needs. I’m not completely satisfied with any of these, but perhaps they can point you in the right direction:

1. Serialize Everything

Rails can store any object as a byte stream, and in Ruby everything is an object. So in theory you could store string representations of any object, including Strings, DateTimes, or even your own models in a database column. The Marshal module handles this for you most of the time, and allows you to write your own serialization methods if your objects have special needs.

Pros: Really store anything in a single database column.

Cons: Ability to work with data in the database is minimal – It’s basically impossible to use this column as anything other than storage – you (probably) wouldn’t be able to sort or filter your data based on it, since the format won’t be anything the database will recognize.

1. Columns for every datatype

This is basically the solution you suggested in the question – figure out exactly which datatypes you might need to store – you mention strings and datestamps. If there aren’t too many of those, it’s feasible to simply have a column of each type and only store data in one of them. You can override the attribute accessor functions to use the proper column, and from the outside, Feature will act as though .value is whatever you need it to be.

Pros: Only need one table.

Cons: At least one null value in every record.

1. Multiple Models/Tables

You could make a model for each of the sorts of Feature you might need – TextFeature, DateFeature, etc. This guide on Multiple Table Inheritance conveys the idea and methodology.

Pros: No null values – every record contains only the columns it needs.

Cons: Complexity. In addition to needing multiple models, you may find yourself doing complex joins and unions if you need to work directly with features of different kinds in the database.