Seeking help to prevent adding table with too many columns - ruby-on-rails

Question

In my app I have a model called Post, that has a belongs to association with the Blog. That's how they look like:
app/models/post:
class Post < ApplicationRecord
belongs_to :blog
end
app/models/blog:
class Blog < ApplicationRecord
has_many :posts
end
The app will collect and store posts of a lot of content management systems (like Wordpress), and there are columns that should only exist for certain types of posts. I would like to know if it's possible to have some kinda of hierarchy, like this:
Post
- WordpressPost
- DrupalPost
This is important because that are columns that should only exist when it's a WordpressPost, for example.
I've tried to understand something called Polymorphic association (I really did), but I just can't get my head around the concept, and I'm also not sure if that's what's going to allow me that flexibility.
Right now the posts table look like this:
+------------+---------------------------------------------------------------------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+------------+---------------------------------------------------------------------------+------+-----+---------+----------------+
| id | bigint(20) | NO | PRI | NULL | auto_increment |
| site_id | bigint(20) | NO | MUL | NULL | |
| status | enum('auto_draft','draft','future','pending','private','publish','trash') | NO | | NULL | |
| date | datetime | NO | | NULL | |
| title | varchar(255) | NO | | NULL | |
| url | varchar(255) | NO | | NULL | |
| body | longtext | NO | | NULL | |
| created_at | datetime(6) | NO | | NULL | |
| updated_at | datetime(6) | NO | | NULL | |
+------------+---------------------------------------------------------------------------+------+-----+---------+----------------+
But things like:
- status
- date
Should only exist for Wordpress posts. I really would like to understand the best way to do what I want.
Thank you.

Answer 1

when mapping OO inheritance to relational database we traditionally have three ways of doing it (as highlighted in this link):
Single Table Inheritance(STI): One table with all the attributes used by all the subclasses. This way is more suitable for cases where the attributes don't change much from one subclass to another.
Class Table Inheritance(MTI): One dad table with common attributes, and child tables for each subclass with their specific attributes and a foreign key to the dad table. Good when there are many different attributes between each subclass and even different associations.
Concrete Table Inheritance: One table for each class with all the needed attributes. May be good if there are little common attributes.
Rails allow us to create a Single Table Inheritance(STI) and we can also use the Concrete Table Inheritance. But it doesn't have a built in way of dealing with the Class Table Inheritance(known as well as Multiple Table Inheritance - MTI), what doesn't prevents you from creating your own way of doing it, like it is done in this post.
Rails also allow us to have a Polymorphic Association, which is useful when we want an association of one type for certain records and of another for others, this can be used for inheritance, but was not actually designed for this. In this link you will find an example of all the three types and how to use them.
Another way to achieve it is by having an options jsonb field. This is a good approach when you have unpredictable/changeable fields that will vary from one record to another. Which is a much simpler way but must be well designed, cause may have some downsides.
Proposed Solution:
I wouldnt use:
STI: as you said it is going to be a lot of different management systems, I believe it is not a good idea because you would have too many unused columns.
Concrete Table Inheritance: I guess you want to make it easy to add new management systems as you go, treating them as one and ignoring their nuances. So it is not really a good option because it would make it harder to understand their commonalities.
I could use:
MTI: it would be a good database design, but as youre using rails you would have to deal with it your own way and it could add some complexity to the code. I would use it if I were more concerned about having a normalized database.
Polymorphic Association: would add some complexity to the database when compared to the MTI and to make it usable as an inheritance would add some complexity to the code as well. I prefer using it with an actual polymorphic association.
I would use:
An options json field: I believe you will need to access this specific attributes just in some specific moments and that each different management system wouldn't have other associations. So I guess it would be the most straightforward solution being totally supported by both rails and the database without adding complexity to neither one.
Ps: If you have just some little different attributes, I would use a STI instead.

Answer 2

As u need different set of columns for different post type based on the cms(post source),
you have to setup specific set of columns required by each post source.
setting up all the required columns in the same Post model itself is not recommended.
because scenarios like removing a post source or adding a post source into your application will be hard in future.
The solution I suggest is to setup a separate model for each post source like
class WordpressPost < ActiveRecord::Base
belongs_to :post
end
class JoomlaPost < ActiveRecord::Base
belongs_to :post
end
Each of these model will have their own specific set of columns like status and data for WordpressPost model and so on to hold the post data along with the post_id.
Then, the Post model can be updated like
class Post < ApplicationRecord
belongs_to :blog
has_one: wordpress_post
has_one: joomla_post
end
Additionally, in the posts table,
you have to include a column called 'post_source' which stores the integer values to denote the post source type.
the reference value for each integer value can be obtained using an helper function like
def get_post_source(source_val)
if (source_val == 1)
source_info = { name: 'Wordpress', model: 'WordpressPost' }
elsif (source_val == 2)
source_info = { name: 'Joomla', model: 'JoomlaPost' }
end
return source_info
end
Using this approach,
you can maintain scalability with ease.
If you have to remove joomla posts entirely from your application, then you can do that without affecting the structure of any other model.
Similarly, you can also add other new post sources like drupal, medium and so on by adding separate models for each.

Answer 3

I think there is another way to do that, changing the database. Like mongoDB, it's easier to meet your goal. If you dont't like mongoDB you can choose Postgres either, which can store hash like data structure.
Back to your polymorphic problem
class Person < ActiveRecord::Base
has_one :address, :as => :addressable
end
class Company < ActiveRecord::Base
has_one :address, :as => :addressable
end
class Address < ActiveRecord::Base
belongs_to :addressable, :polymorphic => true
end
In above example, address is the common part.
So you should define two classes
Post
- WordpressPost
- Content
- DrupalPost
- Content

Answer 4

From the answer from Rafael, you could use the singl etable inheritance.
first, allow null data in the status and date columns (you need to create a migration for that), and even create a new column that stores the content management system so later you could do a validation before saving (ensuring that the column exist in the cases that are needed) or to make querys only on some of your content by cms.