Avoiding circular dependency, possibly with UUIDFields?

I currently iterate my way through migrations commenting out and uncommenting model fields so I can migrate models that have ForeignKeys to other models not migrated yet.

I’ve heard of some people just make detailed notes about their migrations so they know how to do it in future.

I know database design is a huge topic, something I need to become familiar with. However my question is if there is a recommended starting point to avoid circular dependency?

One solution I thought of is to use ForeignKeys and OneToOneFields sparingly and then search model objects by a UUID instead of adding more ForeignKeys which introduce circular dependency. Then to find for example a creator of a Product I could do:

profile = Profile.objects.get(slug=self.kwargs.get('slug'))
products_created = Product.objects.get(uuid=profile.uuid)


profile = Profile.objects.filter(uuid=self.request.user.uuid).first()

I’ve seen some conflicting information on stackoverflow about UUIDs not being good for performance, some have suggested to use a separate UUID field instead of making the pk a UUID.

Is this approach, searching by UUID instead of using ForeignKeys a good solution to avoiding dependency injection?

My goal is to avoid iterating through migrations commenting and uncommenting model fields, so I only do one makemigrations and migrate. My main question is if there’s a standard approach or if it’s the case that I need to read up on database design and apply a specific approach based on various factors.

So the issue is more fundamental. It doesn’t really matter what you use for primary / foreign keys. The root really gets down to how you define your tables and the relationships between them.

Frequently, what’s required is just looking at the entities involved in the models from a slightly different perspective to build a structure that avoids those circular relationships.

That’s not to say that it’s always easy, or that it doesn’t involve some compromises elsewhere - but it’s usually possible to do.

What makes this more difficult is that there aren’t any firm and fixed rules for how to do this. Often, it’s more art than science, which also means that it generally needs to be done in the context of a specific problem.