De-normalization of database for read performance

Viewing 11 posts - 1 through 11 (of 11 total)
  • Author
    Posts
  • #1708
    tkeer
    Participant

    How we denormalized our table to get ride of complex and slow queries.

    [https://medium.com/@taukeer/de-normalization-of-database-for-read-performance-220cd50ac827](https://medium.com/@taukeer/de-normalization-of-database-for-read-performance-220cd50ac827)

    #1709
    colshrapnel
    Guest

    > We all know how bad left joins are for the performance

    Pardon my ignorance but I probably lived under the rock and never heard of that. Can you please explain in layman’s terms, what’s wrong with left joins? In my ignorance I am using them all over the place.

    #1710
    phordijk
    Guest

    I am confused here. You are showing 10 rows in your data table and say it became so slow you needed to denormalize. Are you sure you are querying your data correctly and have proper indices?

    >Luckily, the app was built with laravel, and its orm (eloquent)

    Well that *might* have been your problem on top of the above. Your ORM is slow or the way you work with it is.

    #1711
    darkhorz
    Guest

    Is it safe to assume that it’s not a few queries that are the culprit and that you have analyzed/tweaked the queries and optimized indices etc.?

    #1712
    xgryph
    Guest

    I’ve made good use of denormalisation, but these joins and this amount of data doesn’t look low it should even be close to needing such a heavy handed approach. I would optimise first something isn’t right.

    #1713
    justaphpguy
    Guest

    It’s not just left join.

    From first hand I saw (Postgres) that joins on many rows were just not efficient enough and de-normalizing, i.e. duplicating the data on the primary table you need to avoid the join, was the way to go. It happens.

    #1714
    przemo_li
    Guest

    Where is query analyzer output. Explain or equivalent there of is great tool, and it can be used to validate join related performance insights.

    #1715
    NigelRel3
    Guest

    This sounds more like a problem of setting customer expectations than an application problem.

    They want things faster now for short term gains. When they want to make changes to the application they find that they cost twice as much because the data is spread across the database.

    Some features won’t work due to the data becoming inconsistent (the main point of normalisation).

    Sounds like the start of a slope to bigger problems!

    #1716
    darkhorz
    Guest

    I have never used them myself, but does anyone have any experience using views for this? By the sound of it views addresses this problem.

    #1717
    dialtonee
    Guest

    Yeah in our current system I am pulling through several tables to present user data. This makes sense.

    #1718
    secretvrdev
    Guest

    Bro do you know temp tables?

Viewing 11 posts - 1 through 11 (of 11 total)
  • You must be logged in to reply to this topic.