This is more of an open-ended and possibly subjective question regarding performance and organization.
Let’s say I have a music database of songs, albums, and artists. All three have names. In a relational database this is straightforward with columns and FKs.
In Dgraph I can use two basic options. I can have a single Name predicate which can be attached to any of the three. Or I can have SongName, AlbumName, ArtistName, etc. for each node type I’ll be storing.
Are there any pros/cons when all other factors are equal (indexing requirements, etc.)?
A prefix is the best option in my view. Cuz you can spread the predicates into different groups and also Dgraph won’t waste time going through the whole tablet to find something.
Also, you could for some reason want a type of index in some of the names and others not. So that separation turns out to be beneficial.
I know this is tagged Dgraph, but what @MichelDiz is mentioning is basically the decisions that drove the GraphQL API to auto generate predicate with type dotted notation. That is discussed in other places on Dgraph learn, docs, and here on discuss. The main problem it handles is what was already mentioned, but I just wanted to add that there was some backwards compatibility that was added in to allow GraphQL fields from multiple types to map to a single predicate name. This is used primarily for converting a pre-existing DQL schema to a GraphQL schema, but it goes to show that there may be times when you could want multiple types to use the same predicate name, and that is also acceptable. So like you said, this is very open-ended and there is not a wrong way and a right way. Whatever works best for you, just be aware of what changes you can and cannot do if you decide to go down one path or the other.