Need arguments against consecutive integer indexes

Question

SQL

I'm on the cusp of a new project for my organization and I'm designing the architecture for this web application. At the same time, I had, or rather escalated again, a long-standing conflict with non-IT architects and future users: I want to hide record (object) IDs in the user interface and use GUIDs on the server side (in the database), because it will not work everywhere , and I don't want to give users a chance to know the structure and play around guessing the numbers (for example, if the record ID is 123, then it's probably 122 and 124). In the case of a GUID, many other things are also facilitated, such as database clustering in the future, and so on. (let's not argue about the performance of INT vs GUID for now, what is better to debug, etc.)

The problem is that everyone else doesn't just want integer sequential indexes, they want to see them everywhere so they can easily refer to them later in conversations and correspondence, like "Hey! Who is responsible for project 4096?”, despite the fact that the same project always has its own name and you can refer to it.

Alternatively, I offered them integer indexes that look random and have the same length (on the server, I would recode them on the fly into normal integer IDs), but they don't want to listen, as it's hard to remember.

In general, what other arguments are there to convince? How do you solve such a problem?

Answer 1

Generally speaking, using a uniqueidentifier as a Primary Key is a bad idea. I say this from my own experience. When the project was just starting, we thoughtlessly made all PKs with the uniqueidentifier type, and a year later, when the number of records began to number in the millions, the database began to incomprehensibly blunt. Then we learned what index fragmentation is. Clustered index fragmentation slows down inserts a lot. Speaking of fetching, banal joins of 100 by 100 records have become slow because the server has to do a lot of seeks on disk to get to the desired record. And don't talk about bad indexes, in this case we squeezed everything we could, and it was sikis that became a headache. Transferring a huge database to an SSD is also the safest operation. So for more than a year now we have been slowly changing the old Guids to int/bigint and remember that imprudent decision with pain.
I would recommend that you design an architecture with a good security check layer. And then enumeration of id will give nothing to the attacker. Also, no one bothers to add another SecureId column and use it in places that you really, really don’t want to show outside.

Answer 2

If the client wants numbers - give him numbers

Answer 3

Maybe you should make this project in Mongo, then your conscience will be clear? =)

Answer 4

In the case of an online store (I don't know what you have), it is obvious that the user ID and order ID should not be consecutive. Otherwise, by registering, I will receive an ID and find out the number of users, and after creating a couple of orders and seeing that the IDs are consecutive, I will see the number of orders in the store and be able to make an assumption about its turnover. And I don't even need any sorting.
For reference: CHAR(7) - a set of a-z0-9 gives 78364164096 variations.

Answer 5

Start talking to them from the other end: Say that you need to decide on the level of protection and security in the project. Give them some sort of gradation, and let them choose for themselves what they consider secret in the project and what is not. And when you decide with them on the security of individual parts of the project, you will be able to tell them “For such a degree of security, you need to take such and such measures in such and such places.”