<story><title>We saved $50k/year with a Go microservice coded in a hackathon</title><url>https://movio.co/en/blog/saving-money-with-Hackathon-project/</url></story><parent_chain><item><author>any626</author><text>The user data is most likely in rows instead of columns.
Instead of having&lt;p&gt;&lt;pre&gt;&lt;code&gt;    id, name, age, gender
    1213, fake, 60, female
&lt;/code&gt;&lt;/pre&gt;
they would have&lt;p&gt;&lt;pre&gt;&lt;code&gt;    property_id, user_id, value
    1 (assume age), 1213,    60
    2 (gender),     1213,    female
&lt;/code&gt;&lt;/pre&gt;
This gives them the freedom to add more properties to the user without always having to add a column to the users table. When querying the database you&amp;#x27;ll have to do unions or joins.</text></item><item><author>orf</author><text>I don&amp;#x27;t quite get this. How fast was running this query:&lt;p&gt;&lt;pre&gt;&lt;code&gt;   Select loyaltyMemberID
   from table
   WHERE gender = x
   AND (age = y OR censor = z)
&lt;/code&gt;&lt;/pre&gt;
Why the random complexity with individual unions and a group? Of course that&amp;#x27;s going to be dog slow.&lt;p&gt;Sure, the filters can be arbitrary but with an ORM it&amp;#x27;s really really simple to build them up from your app code. The Django ORM with Q objects is particularly great at this.&lt;p&gt;Obviously I&amp;#x27;m armchairing hard here but it smells like over engineering from this post alone. Stuff like this is bread and butter SQL.&lt;p&gt;Edit: I&amp;#x27;ve just read the query in the post again and I really can&amp;#x27;t understand why you would write it like that. Am I missing something here?&lt;p&gt;Seems like a fundamental misunderstanding of SQL rather than a particularly hard problem to solve.</text></item></parent_chain><comment><author>thorin</author><text>Entity attribute value anti pattern - this has been well known for at least 20 years. It can be tempting when you want to design a &amp;quot;flexible&amp;quot; system but really needs to be used sparingly. I was BI team lead on a product where the architect insisted that it be used on every entity (&amp;gt;300) as you never knew when you might want to add some bit of data. It led to some interesting (multi-page) sqls and the project ultimately failed. This was one of the reasons. Slow performance and often runtime errors when expected data wasn&amp;#x27;t present and the application layer couldn&amp;#x27;t cope. It was a good learning experience. 
&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;mikesmithers.wordpress.com&amp;#x2F;2013&amp;#x2F;12&amp;#x2F;22&amp;#x2F;the-anti-pattern-eavil-database-design&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;mikesmithers.wordpress.com&amp;#x2F;2013&amp;#x2F;12&amp;#x2F;22&amp;#x2F;the-anti-patte...&lt;/a&gt;</text></comment>
<story><title>We saved $50k/year with a Go microservice coded in a hackathon</title><url>https://movio.co/en/blog/saving-money-with-Hackathon-project/</url></story><parent_chain><item><author>any626</author><text>The user data is most likely in rows instead of columns.
Instead of having&lt;p&gt;&lt;pre&gt;&lt;code&gt;    id, name, age, gender
    1213, fake, 60, female
&lt;/code&gt;&lt;/pre&gt;
they would have&lt;p&gt;&lt;pre&gt;&lt;code&gt;    property_id, user_id, value
    1 (assume age), 1213,    60
    2 (gender),     1213,    female
&lt;/code&gt;&lt;/pre&gt;
This gives them the freedom to add more properties to the user without always having to add a column to the users table. When querying the database you&amp;#x27;ll have to do unions or joins.</text></item><item><author>orf</author><text>I don&amp;#x27;t quite get this. How fast was running this query:&lt;p&gt;&lt;pre&gt;&lt;code&gt;   Select loyaltyMemberID
   from table
   WHERE gender = x
   AND (age = y OR censor = z)
&lt;/code&gt;&lt;/pre&gt;
Why the random complexity with individual unions and a group? Of course that&amp;#x27;s going to be dog slow.&lt;p&gt;Sure, the filters can be arbitrary but with an ORM it&amp;#x27;s really really simple to build them up from your app code. The Django ORM with Q objects is particularly great at this.&lt;p&gt;Obviously I&amp;#x27;m armchairing hard here but it smells like over engineering from this post alone. Stuff like this is bread and butter SQL.&lt;p&gt;Edit: I&amp;#x27;ve just read the query in the post again and I really can&amp;#x27;t understand why you would write it like that. Am I missing something here?&lt;p&gt;Seems like a fundamental misunderstanding of SQL rather than a particularly hard problem to solve.</text></item></parent_chain><comment><author>siculars</author><text>If they are using some sort of middleware orm, which they may well be because of their model, they are most likely using an EAV[0] schema which, although flexible for writes, is horrendous for reads. The join plus pivot is a disaster on virtually any relational system.&lt;p&gt;[0]&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;en.wikipedia.org&amp;#x2F;wiki&amp;#x2F;Entity%E2%80%93attribute%E2%80%93value_model&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;en.wikipedia.org&amp;#x2F;wiki&amp;#x2F;Entity%E2%80%93attribute%E2%80...&lt;/a&gt;</text></comment>