use ID or Pointers ?

texture ID, mesh ID, material ID, Entity ID?

or pointers,

or fileName? like test.png cube.obj...

which pattern is easy to maintain, I may store the data in the file. If use pointers to identify the resource , the pointers will differ when it reload from file.

If you're working in a team it's helpful to have ID numbers that stay the same across instances of your application. That allows people to share bug reports that clearly identify certain objects, to easily see in the debugger which object it is, etc.

I use handles for pretty much every resource that needs a direct link - I have different ways of managing them, but most of them are 32bit and store an index to an array of resources along with 8 bits or so reserved for a "magic" ID so I can track resource lifetime (i.e. if the resource is alive or freed). I think this might have been the first thing I read about it years ago: http://scottbilas.com/publications/gem-resmgr/. It's evolved since then but the premise is the same.

I tend to use hashes when serialising if one thing needs to look-up another. I've started to use a unique string index that's created at build time along with a dictionary (i.e. list) of all strings used. That can be used for compares + easy string lookup for tools and debugging, and saves having to keep the hash + string pointer around. However, it requires some additional management that i'm not sure is worth the pay-off yet.

T

use ID or Pointers ?

texture ID, mesh ID, material ID, Entity ID?

or pointers,

or fileName? like test.png cube.obj...

which pattern is easy to maintain, I may store the data in the file. If use pointers to identify the resource , the pointers will differ when it reload from file.

With the comment at the end it seems you already understand the trouble with pointers and persistence.

Pointers are the current, temporary, transitory location in memory. They make sense when you are referring to such temporary transitory things in your code, but rarely make sense anywhere else.

While they add an indirection and therefore add a minuscule performance penalty, handles or IDs or similar open up a wide range of solutions to applications. However, they take some time and effort to implement.

Tools that generated unique IDs for all game objects and then abstract away the links between models, textures, and scripts can work great. This allows for in-game streaming of assets, unloading them and reloading them as needed and using proxy objects when they are unloaded. IDs allow for persistence that you can (if implemented) handle assorted problems common during development where objects change or are updated or need to be corrected in some way. IDs allow for serialization between machines if you have networked systems. ID based systems can make it easy to dynamically reload the underlying assets when they change, giving easier development. IDs allow for many other fun and wonderful features once you pay their development cost.

You also do not have to use eigther - or. There is nothing wrong with having a pointer in your code, and when its about to be serialized, you can convert the pointer to an ID (for example via lookup). On deserialization, you perform another lookup to see which pointer to get from this ID.

I'm not saying that its the best option, but it certainly is a thing to consider. It still keeps the speed of pointers (in case you need the last inch of performance) and relative easeness for debugging (inspecting an object via handle in debugger can be more difficult), while being able to safely serialize/deserialize where needed.