Use case question

[ssnyder]

Hi,

I just came across your gem, and it looks like you handle my situation fairly well. I have an existing table (and model) - tableA, and the structure is more complex (too many columns in my opinion - I inherited this design, and performance is a small issue), but simply this:
id
user_id (FK on users table with its own model)
status (string)
result (large string)
address_id (FK on address table with its own model)
language_id (FK on languages table with its own model)
etc.

There are approximately 21 million records. I need to add another column to this table, and obviously the migration time is horrible. I was thinking about creating another table (tableB) with the same id as the key, and just the new column I wish to add (I may consider moving some of the other columns off of tableA, but more likely will just continue to use table B to add columns since it is so much smaller). Obviously I don't want to create a new model for such a simple table.

It looks to me like your flatten_record could be what I'm looking for - make these normalized tables (just tableA and tableB) look/feel to the code as one table. I'm not sure exactly how to define this new model...and could I just define it in the existing tableA model so I have less code to change? There are lots of scopes and functions that are defined in the tableA model as well as references directly to that model that I obviously don't want to have to update if i don't have to.

Any assistance would be appreciated - or if you have a better suggestion - please feel free to let me know!

Thanks,
Sharon

[alvinsj]

Hi Sharon,
Looking at your description, I think the challenging part is the design of the models/relationships in order to correctly represent the architecture of your system. If it might end up with too many relationships/tables and join is a pain, then adding denormalized records can be one of the solutions.

If you are able to normalize your tables into table A, B,C,D,... then denormalized table Z can serve you the purpose to get record out of them. However, you still need to do migration whenever you are adding a column, but now only the denormalized table and the changed normalized table will be affected.

I am not sure I understand/answer your question correctly, hopefully it helps a bit.