Pros and cons of single-page inheritance for assets in Rails

Question

I look at bootstraps for files, and there seems to be a tendency to put all assets in one Assets table and use STI to subclass. Like ImageAsset , VideoAsset , AudioAsset etc.

I am new to Rails and I have never used STI. Previously, I would just make images , videos , audios separate tables. Of course, they can share several columns, but I would say that they will also have several different ones (the sampling frequency does not apply to the image, for example.)

Profiling all of this in one “assets” table: it’s easier to run queries on all assets. Cons: the table will become faster. I guess I could always characterize a type column if this is a problem. I also expect that all audio-only columns will have a null value for image rows, etc.

My entire application will be based on assets, so I want to make sure that I have pros and cons right before making a decision. Has anyone made an STI asset and regretted it? Has anyone done this and did not regret it (for a large amount of assets)? Would CTI (class table inheritance) be the best solution here?

Answer 1

I would say that one of the biggest disadvantages of using STI is that if you ever add a column to a table that is not shared (and that means the same thing) between all STI models, you just blew your data integrity right there.

Zero fields in (relational) databases is what usually causes more problems than they solve.

I have been bitten by this several times, and it is especially frustrating when classes in your STI relation begin to have their own subclasses, which in turn adds even more columns to the table.

I would say that if you want to make this structure as possible as possible, I really think that CTI is a much better alternative, although it can be a little difficult to get it working with rails. This is much more complicated than STI.

At the top of my head, I can just think of one scenario where an STI might be reasonable, and that when you are dealing with transaction models (for example, deposits and withdrawals from a bank account or so on). In these cases, both models are essentially the same except for the “direction” of the transaction.

You could also argue that STI is “good” for rapid prototyping, and if you just want to build something quickly to see if it works at all, you can use STI, but as soon as you start adding columns it doesn't make sense Of all the models in regards, you should probably reorganize it into CTI or something else.