Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Primary keys of relational tables (relations) might have two types:</p> <ol> <li><p><strong>Natural</strong> - exists in subject area to completely determine each row of relational table. Natural primary keys might be <strong>simple</strong> (if consists of only one column), or <strong>complex</strong> (if consists more than one column). It is not recomended to set a natural primary key on large string column.</p></li> <li><p><strong>Artificial</strong> - special column, injected by database designer / developer to boost table performance, if natural key is complex, and have to be used in related table (is foreign key for something), or if it is simple, but is large and will produce data overhead while copied in related table as a foreign key, or if it is complex to search (for example, CRUD operations on <code>VARCHAR</code> IDs might be slower, than on <code>INT</code> IDs). There <em>might</em> be other reasons. <strong><em>TL;DR</em></strong>: Artificial key - one special column, serving to completely determine each row of relational table and boost it's performance for CRUD operations.</p></li> </ol> <blockquote> <p>We have an auto-increment as primary, but it is not really used. Is it a problem to remove it ? We will no have primary key if we remove it => How to identify a line ?</p> </blockquote> <p>If you do not need to reference your table to another tables (as source), then you may probably remove artificial key without any consequences. Still, I recomend you set any other <code>PRIMARY KEY</code> in this table to avoid data duplication, and for obviosity (if it matters).</p> <p>Your table by itself (if properly <a href="https://en.wikipedia.org/wiki/Database_normalization" rel="nofollow"><strong><em>normalized</em></strong></a>) will have natural key as one of "key candidates". It might be complex one (consist of few columns). It is normal. But don't set primary for strings, because <code>PRIMARY</code> always have index, which will produce data overhead. If it is combination of <code>INT</code> or "<em>small</em>" <code>VARCHAR</code> columns, then it is normal.</p> <p><strong>Consider as an option:</strong> <code>id_event</code> + <code>id_user</code> + <code>date</code>.</p> <hr> <blockquote> <p>We don't do bulk insert. Is it a good idea to insert in a Memory table without index and copy data every 5 minutes ?</p> </blockquote> <p>It is not a bad idea. But it is not good idea, until it properly tested. Try to perform load-test, before real use.</p> <p>If you not reference <code>MEMORY</code> table to others, then you still may join it with any other <code>InnoDB</code> table. But you will loose <code>InnoDB</code> functionality (<a href="http://en.wikipedia.org/wiki/Referential_integrity" rel="nofollow"><strong><em>referential integrity</em></strong></a>). If lose of parent table <code>ON DELETE CASCADE ON UPDATE CASCADE</code> is not a concern, then it might be done. As for me, <code>InnoDB</code> is not so slow to switch table engine, in your case.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload