When building complex systems in Rust, one of the fundamental challenges developers face is how to organize their data structures to maintain type safety, avoid code duplication, keep their API clean, and remain flexible to changes. This article explores six different approaches to data modeling using a search engine as our example, examining the trade-offs between each approach where fields between search types are overlapping.

An interesting article that lays out a problem and goes through a few different solutions, some of which I haven’t thought about much before.

I’m working on a video game in Rust, and I’m running into this kind of modelling problem when it comes to keeping track of the game state. So far I’ve refactored something that resembles Approach 5 into something that looks more like Approach 3. As I get more confident about the final shape of the data, it (seemingly) becomes a better idea to represent it in a more structured way.

  • livingcoder@programming.dev
    1·
    3 days ago

    This was a good blog post. I have started using approach #3 as well for just about every situation where I was originally planning on just using a enum type by itself. Inevitably I end up needing to apply shared state to all of my enums (create date, parent table ID, etc.) and this approach has really worked out very well. You can also add some convenience functions for returning if the kind is one of the variants (ex: IsKeywordSearch) to make if-statements easier to read (and a match on the type enum is overly verbose when you don’t need the properties contained within the enum itself).