Is it best practice to perform CRUD with IDs as defaulted by framework or its better to use own unique
fields? Taking into consideration system users can guess the next number. See edit snippet below:
public function edit($id)
{
$tenant=Tenant::find($id);
return view('pages.tenants.edit')->with('tenant',$tenant);
}
For blog posts and articles you can use UUID but for back office applications that looks weird.
Taking into consideration system users can guess the next number.
@kenprogrammer Yes. It’s an attack vector too if you have an application with information that a competitor can scrape automatically by just incrementing an ID and issuing a GET request.
I personally use slugs on the front-end and UUIDs in the back-end. The reason for UUIDs in the back-end is because if admins are changing the names of title fields, then a slug would change. One example is videos in a video on demand platform I have. I send an email when a video has finished processing that includes a link to the edit video page. If I used a slug on this page, the slug would change (and break the URL in the email) when an admin updated the video’s title. Whereas if I use a UUID, that will stay constant and that link in the email will work so long as the video exists.
@martinbean One more thing,consider the snippet below:
class Post extends Model
{
/**
* Get the comments for the blog post.
*/
public function comments()
{
return $this->hasMany(Comment::class);
}
}
If am using UUIDs do I still need to save the ID of the parent table into the child table for the relationship to work?
The relationship expects comments table to have post_id column.