MySQL transaction table : use auto increment key or not?

Question

I'm looking for an insight as I'm a bit stuck.

Right now I'm using auto increment ID's in all of my MySQL innoDB tables. Even for transaction tables (large volume tables).

In my application, someone enters a financial journal which contains of a few transaction lines which are saved in a transaction table.

Now I get requirement requests that the users want to be able to change those transactions rather then insert a total correction for that journal and insert new lines.

No problem for my procedures, but one question arises for me: what if the number of transaction lines for that journal particular changes? If they are the same I could just overwrite the lines with the current auto increment IDs that they already have.

But what if there are more or less journal lines than the first time they were inserted?

Sure, I can delete all previously inserted lines and insert new ones which the auto increment ID field handles fine. But it leaves a gap in the IDs.

I've read before about peoples opinions about the gap I'm talking about, where things go from 'don't worry about it, you'll never run out' to 'oh my, a problem'.

Is it a bad thing if i leave out the auto increment ID as I do not even need it in this trans-table? I always find the rows in the trans-table through the journal number, which is unique.

Are there any drawbacks with leaving out an auto increment ID field on this table?

All I can think if that it maybe may slow down queries on that table (and am not sure of that), but can't think of anything else.

For reference, my trans table looks somewhat like this:

ID --> auto increment bigint
Journal --> int(11)
JournalLineNumber --> int(3)
Description --> varchar (50)
Amount --> decimal
etc. etc.

By the waym I still do not know how to insert things like tables for displaying mysql table info in my questions in stackoverflow, does anyone know? Googled it again just now but all kinds of confusing tools seems to be needed to simple enter a table of information....but hopefully I'm wrong.

Answer 1

The important thing is that you have a primary key, and that it is reasonably compact. UUID isn't too great because it's big; bigint is fine. int is great. If your have an int or bigint journal number, you can use that as the PK, and you don't need an auto_increment. As long as you have a PK and it isn't huge, performance will not be negatively impacted.

Note that signed (default) int(11) is only good for up to 2^31 (~2bn). Given that your auto_increment was bigint, will you need more than -2bn to +2bn range for this? Should it be unsigned for 0 to 4bn instead? Is 4bn going to be enough for the foreseeable future? ALTER TABLE on 4bn rows is going to take a while .

Paste the output of SHOW CREATE TABLE . To show it as a block, make sure each line is prefixed with at least 4 spaces. Or just use the formatting toolbar.