I can at least answer that: Using ‘just’ a timestamp caps you to a certain number of maximum inserts per second, and requires you to pay good attention to your clock. However, there certainly are common approaches to create timestamp-base IDs. A common one is the Snowflake ID, for which there exists an Elixir implementation.
As to when it makes sense to use UUIDs vs auto-incrementing IDs: personally I agree with the arguments of this blog post that boil down to UUIDs are larger than traditional SQL auto-increment ID fields, but they have several benefits such as better scalability, they still work in a distributed setting, you can move to a different underlying database without having to create new ids, etc.
Yes and no. You cannot vary what fields exist in a Mnesia table. You can however vary what data is stored inside, and this data might be any Erlang/Elixir term including (nested) lists, maps (including structs), tuples, etc. This gives you flexibility to store varying data in a certain field.
The main disadvantage of storing denormalized data is that you cannot (at least not easily) query this data. Depending on what you want to store vs. what you want to search on, this is usually not a problem.
I’d say: start with the simplest thing that works and only make it more complex if you hit against its limits.
