3 ms·

I think this article does a good job in capturing the complexities of generating test data for real world databases. Generating mock data using LLMs for individ

I think this article does a good job in capturing the complexities of generating test data for real world databases. 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. And it's even harder for databases such as MongoDB, where the relationships across collections are often implicit and can best be inferred based on the names of the fields.

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 ago
  Well 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.

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 ago
Well 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.