Let’s say I am making an app that has table Category and table User. Each user has their own set of categories they created for themselves. Category has its own Id identity that is auto-incremented in an sqlite db.
Now I was thinking, since this is the ID that users will be seeing in their url when editing a category for example, shouldn’t it be an ID specific only to them? If the user makes 5 categories they should see IDs from 1 to 5, not start with 14223 or whichever was the next internal ID in the database. After all when querying the data I will only be showing them their own categories so I will always be filtering on UserId anyway.
So let’s say I add a new column called “UserSpecificCategoryId” or something like that - how do I make sure it is autogenerated in a safe way and stays unique per user? Do I have to do it manually in the code (which sounds annoying), use some sort of db trigger (we hate triggers, right?) or is this something I shouldn’t even be bothering with in the first place?
i think youre missing a table.
you have categories, you have users, and then you have an ‘assignment’ table that contains a user key and a category key… maybe its own auto incrementing identifier
Plus I’d suggest having a slug so the user doesn’t have to memorize a meaningless number, instead a similar sounding string.
Instead of having 12345, something like category-1 for “Category 1”.
Specially for sharing with a URL, it’s more meaningful to share " domain.tld/search/categories/cat-1" than any other form of id (I’m annoyed with lemmy for not having a slug for posts, it feels so shady to share anything haha)
This is something I’ve been considering too, since the name is in this case unique per user I can just use it for everything in frontend rather than the ID. It’s not always a good solution though so I was wondering how would I solve it with IDs alone
You shouldn’t use the name as a replacement for the ID, you need to use a slug.
The name should be stored as the user sets it, and the slug is autogenerated by your code removing any problematic character, so usually it only contains letters, numbers, and dashes, which makes it perfect to be a substitute for the numeric ID.
There should be libraries to handle this for you.
And ID is just something to identify a resource, so your ID in this case would be the slug.
I have a use case where the ID is generated by two fields, adapting it to your case would be something like /users/{user}/categories/{category}
So, whatever you define to be a unique way of working with an entity will be the identifier (ID) of that entity.
I have a join table between Category and other entities that can be categorized in this way, but I dont think I need one between User and Category? Different users can’t share the same category so it’s a 1-n relationship, not n-n.
Even if I did though I still have the same issue since I have to figure out how to autoincrement it, only now in the join table rather than the Category table.
if cats are unique to a person, you would just use your auto-created id for the category table. sounds like you need to separate your internal IDs from your external (human readable IDs)…
if you need something human-readable, you would concat an additional field in the category table with a ‘category display id’ or somethin
Your description of the problem makes sense. If you think improving the user experience in this way is worthwhile, then go for it. Just remember, most users don’t pay attention to the address bar.
For implementation, I suggest creating a new table, something like ‘tb_user_category_index,’ with userId as a foreign key and an integer that increments each time it’s used. Automating this process in the database would be ideal: set it up once and let it run on its own, keeping things simple.
However, don’t confuse this cosmetic index with a primary key. The primary key should only serve as a unique identifier for a record and hold no other information.
I think you shouldn’t bother. First, as another user already said, the normal user does not look much at the address bar. Second, how will you work with deletions? Say user created 4 categories 1-4 and deletes category 2. Now you either have a hole or you “reindex” the categories to 1-3, which is probably bad since it breaks any bookmarks the user created.
This is basic database 101 stuff, I’d recommend watching some videos on SQL. It will go through what a bridge table is.
User(Id, name etc) 1 — * UserCategory(UserId, CategoryId) * — 1 Category(Id, name etc)
