<table><tr><td style="">pablo added a comment.
</td></tr></table><br /><div><div><p><strong>Round #2 </strong></p>

<p>I've spot-checked the ERD's and they appear to be correct based on the provided SQL.  In fact, I pointed the ERD tool to my Neon VM and told it to reverse engineer the run-time akonadi database.</p>

<p><strong>Observations</strong></p>

<p><strong>[partTypeTable]</strong></p>

<ul class="remarkup-list">
<li class="remarkup-list-item">The Alternate Key is on (name, ns).  Is it necessary to  use both columns?</li>
</ul>

<p><em>Associative Tables do not have a Surrogate Key - slight anti-pattern</em></p>

<p>A logical many-to-many relationship is physically implemented by creating an <em>Associative Table</em>.  For example, in the ERD <em>PIMItemTagRelation</em> is such a table as it resolves the many-to-many between <strong>[PIMItemTable]</strong> and <strong>[TagTable]</strong>.</p>

<p>The anti-pattern is that most (not all) of these tables do not have a <em>surrogate key</em> (e.g. <strong>id</strong> defined as an <em>identity</em> data type) as the other tables.</p>

<p>Furthermore, If an associative table is a parent to another table, then it <strong>does</strong> gets a surrogate id.  I understand the variance.</p>

<p>An additional issue with these tables, those without a surrogate id, is the primary key is composed of the foreign keys.  Nearly all of these tables have two parents so we end up with an index like the following:  (FK1, FK2).  The problem is there is no supporting index should we Join only with FK.  To solve that, the model defines an index on FK2.</p>

<p>The exception to the above is <strong>[RelationTable]</strong>, it has three parents.  As expected, the composite key is on its three FK's and two additional indexes, one on FK2 and one on FK3 is created.</p>

<p>What I recommend we (eventually) do is:</p>

<ul class="remarkup-list">
<li class="remarkup-list-item">Ensure we can drop the existing, composite Primary Key</li>
<li class="remarkup-list-item">Add a surrogate id to each table and make it the Primary Key</li>
<li class="remarkup-list-item">Create separate indexes on each Foreign Key</li>
</ul>

<p>By doing the above, the optimizer/planner can determine the most selective index to use when determining an execution plan for a query.  Additionally, all the tables are consistent which means any functionally dependent code is also consistent.</p>

<p><strong>[CollectionTable]</strong></p>

<ul class="remarkup-list">
<li class="remarkup-list-item">I would investigate further whether the index on <strong>(name, parentId)</strong> is necessary.  It is possible it's necessary if we have an extremely high fan-out from the parent to the next level of children (e.g. 20, 50, 100 next-level children)?</li>
<li class="remarkup-list-item">Generally indexes on low cardinality columns (e.g. gender) are not helpful.  Unless of course one is fetching only by that column <strong>and</strong> perhaps a small percentage of the data qualifies by the value.  With this in mind, I would investigate if we need indexes on <em>enabled</em>, <em>syncPref</em>, <em>displayPref</em> and <em>indexPref</em>.  I suspect we should be able to drop them.  I'm curious to know the SQL which uses these columns.  I suspect other columns are used which would have existing supporting indexes.</li>
</ul>

<p><a href="https://phabricator.kde.org/F5687811" style="background-color: #e7e7e7;
          border-color: #e7e7e7;
          border-radius: 3px;
          padding: 0 4px;
          font-weight: bold;
          color: black;text-decoration: none;" rel="noreferrer">F5687811: akonadi-mysql.pdf</a></p>

<p><a href="https://phabricator.kde.org/F5687812" style="background-color: #e7e7e7;
          border-color: #e7e7e7;
          border-radius: 3px;
          padding: 0 4px;
          font-weight: bold;
          color: black;text-decoration: none;" rel="noreferrer">F5687812: akonadi-mysql-birds-eye.pdf</a></p></div></div><br /><div><strong>TASK DETAIL</strong><div><a href="https://phabricator.kde.org/T7846" rel="noreferrer">https://phabricator.kde.org/T7846</a></div></div><br /><div><strong>To: </strong>pablo<br /><strong>Cc: </strong>dvratil, kde-pim, pablo<br /></div>