
<html>

<head>

<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">

</head>

<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif; ">

<div>Solum community,</div>

<div><br>

</div>

<div>I notice that we are using String(36) UUID values in the database schema as primary key for many new tables that we are creating.  For example:</div>

<div><a href="https://review.openstack.org/#/c/68328/10/solum/objects/sqlalchemy/application.py">https://review.openstack.org/#/c/68328/10/solum/objects/sqlalchemy/application.py</a></div>

<div><br>

</div>

<div>Proposal: Add an int or bigint ID as the primary key, instead of UUID (the UUID field remains if needed), to improve database efficiency.</div>

<div><br>

</div>

<div>In my experience (I briefly pinged a DBA to verify), using a relatively long field as a primary key will increase resource utilization and reduce throughput.  This will become pronounced with the database will no longer fit into memory which would likely

 characterize any medium-large Solum installation.  This proposal would relatively painlessly improve database efficiency before a database schema change becomes difficult (many pull requests are in flight right now for schema).</div>

<div><br>

</div>

<div>In order to prevent the auto-incrementing ID from leaking usage information about the system, I would recommend using the integer-based ID field internally within Solum for efficiency and do not expose this ID field to users.  Users would only see UUID

 or non-ID values to prevent Solum metadata from leaking.</div>

<div><br>

</div>

<div>Thoughts?</div>

<div><br>

</div>

</body>

</html>