2 ms·
> Generating mock data using LLMs for individual tables based on the naming of the fields is one thing, but doing it across multiple tables, while honoring comp
by gopher_space 2y ago
> Generating mock data using LLMs for individual tables based on the naming of the fields is one thing, but doing it across multiple tables, while honoring complex relationships across them (primary-foreign keys across 1:1, 1:N, and M:N with intermediate tables) is a whole another level of a challenge.
So much so that I'm wondering about the context and how useful the results would be if the idea was self-applied. The article talks about mocking data for a number of clients, and I appreciate that viewpoint, but I'm struggling to picture a scenario where I wouldn't have the time or desire to hand-craft my own test data.
- SkyVoyager99 2y agoWell a few scenarios come to mind - 1) keeping the test data up-to-date as the schema changes takes a fair amount of work, especially if it's a schema that's actively changing and being worked on in a team by more than one developer. 2) Not everyone wants to necessarily craft their own test data even if they can, because well they would rather spend their time doing something else. 3) test data generation at even modest scale can be quite painful to hand-craft (and keep up-to-date). 4) capturing all the variances across the data e.g. combinations of nulls across fields, lengths of data across the fields, etc.