Help designing a Table(s) with a single message to multiple placeholder values, with new placeholders added occasionally [closed]

Question

Closed. This question needs details or clarity. It is not currently accepting answers.

---

Want to improve this question? Add details and clarify the problem by editing this post.

Closed 3 months ago.

Improve this question

The basic situation is I have a single 'message' table, and currently our design for this is a single row, with all placeholde values stored against the row at generation, so they are available for editing of the message itself.

My issue is, we are constantly adding placeholders, not often but enough, where we have around 30 currently, and this specific table has now grown to 30mil rows. It seems to be getting slower when processing, and each time we add a placeholder it takes half an hour currently, and this is only going to get longer as the number of rows increase, which is happening rapidly.

Is this the best way to handle the placeholder values, most of which are NOT set, or is there a better way of having that relationship, and speeding up how we handle our data?

I have researched EAV (message_id | placeholder_id | placeholder_value) in addition to another 'placeholder' table, but this seems to be bad practice from what I have read.

We are considering archiving data at this point, but if there is a better way to handle the DB structure, I would like to implement it.

Thankyou for any help!

Answer 1

You should look into Normalization and possibly implementing Star Schema.

These are design techniques used to appropriately divide your Table structure into a more efficient schema both from a query processing and data redundancy standpoint.

The 5 second version being, can you break up your Message table such that a lot of the placeholder fields go into their own separate Table(s)? If so, it should help with querying when you SELECT only the fields you need and when you need to add more placeholder fields, they can potentially be added to a less wide table if it's not on the Message table.

It's also helpful from a concurrency contention standpoint too if you need update one field that's in one of the placeholder Tables, concurrently to the Message table being read from as it won't cause write locks on the Message table.