I need the highest article ID in the column "db_art_id".

No, you don't. Or at least, you should not need it.

An ID column should be just that - an identifier, uniquely identifying a single record. It should have no other meaning, no other value, no ordering. It should not matter if the ID is a number or any other unique collection of bits. It should not matter how the ID is generated. The generator simply must never return an ID value more than once.

A common idea that I've heard by way too many database users in the last few decades is to get the maximum of an ID column, increment it by 1, and use that value as the ID value for the next record to be inserted - or worse - to predict the next ID that will be used by the database engine for that column. It sounds like it would work, and the most evil part of this idea is that it will actually work for a while. But then, parallel access and/or rollbacks will happen and things will go horribly wrong.

Yes, in theory, you really could get away with max(id_col)+1 - if you add a lot of locking and transaction handling to that. Things you can't do in SQL, and must do in your application. In other words: If you re-invent what has already been implemented in the database engine. And you can be very sure that the implementation in the database has been tested way better than anything you can come up with, including UUIDs. (And no, UUIDs aren't guaranteed to be unique, UUID collisions are just unlikely. The same is true for hash functions like the SHA family.)

See Re^2: Perl DBI and Foreign Keys, Re^6: Perl DBI and Foreign Keys, and SELECT LAST_INSERT_ID does not work for details.

Alexander

Footnote: It is sometimes really hard to make people not use max(id)+1. I had to threaten to change database sequences to begin at MAXINT and decrement by 3, 7 or 11 just to stop collegues from using max(id)+1.