Not for the rapid update that broke everything.
See post incident report:
How Do We Prevent This From Happening Again?
Software Resiliency and Testing
-
Improve Rapid Response Content testing by using testing types such as:
-
Local developer testing
-
Content update and rollback testing
-
Stress testing, fuzzing and fault injection
-
Stability testing
-
Content interface testing
-
Add additional validation checks to the Content Validator for Rapid Response Content.
-
A new check is in process to guard against this type of problematic content from being deployed in the future.
-
Enhance existing error handling in the Content Interpreter.
Rapid Response Content Deployment
-
Implement a staggered deployment strategy for Rapid Response Content in which updates are gradually deployed to larger portions of the sensor base, starting with a canary deployment.
-
Improve monitoring for both sensor and system performance, collecting feedback during Rapid Response Content deployment to guide a phased rollout.
-
Provide customers with greater control over the delivery of Rapid Response Content updates by allowing granular selection of when and where these updates are deployed.
-
Provide content update details via release notes, which customers can subscribe to.
Source: https://www.crowdstrike.com/falcon-content-update-remediation-and-guidance-hub/
Ultimately, I don't see any need for users to care about ids. I'd just make a user ID column in the category table and use that for selecting categories. Rather think about a display name that is either known or made by the user.
The only problem with increasing numbers is if you don't properly limit access to creator account and a user can just edit the url bar to get others categories. It's still a problem with other unique stuff, but less easy to crack when it's not sequential.
If you really want it, just replace ID in the url with the category name, if that is a simple string without any special characters. Actually useful for users visually, avoids numbers, users only see what they care about, still no bridging table. And the query is still a simple where user_id = x and category_name = y. This actually means non-unique names, but you are always filtering on users, so you can instead use a constraint or unique composite index on user_id and category name.
Personally i would stick with IDs because they are simple, and don't change so they are not prone to renaming, special character issues, and whatever else string handing deals with. And it's probably slower.