Your linked image shows what appear to be tables, and the little arrows appear to represent entity-relationships between them. But I'm not sure how you'd get useful DDL out of it -- none of the columns have types, no indices, etc.!
Maybe an LLM could sketch out a DDL skeleton from a picture, which someone could use as a starting point?
You and a LLM can guess at what the types might be, but those guesses are a suggestion that a human needs to evaluate, they're not something you can just pass thru as assumptive defaults. In your link, for example, I would definitely not want CategoryID to be an INT, or UnitPrice to be a DECIMAL, or etc.
Sure, yeah - but just like with a human, I can provide additional domain context that can clarify its answer. I see your point - you need to know what to provide in order to get the result you want - but I think that today, that makes it a very useful tool, and tomorrow, it'll be able to make those clarifications itself.
(Out of curiosity, what would you use instead? I'd default to INT/DECIMAL respectively myself - would love to know what your thinking is here!)
I'd default to CategoryID being a string, with uniqueness constraints defined on the categories table. And UnitPrice to be a composite type, containing a [u]int amount and a string denomination, e.g. `10000 USD_CENT` or something like that.
But what you or I or anyone thinks is the right type for these or any columns, is totally beside the point. The point is that the type for a column isn't really assume-able by an LLM, at least not automatically.
Your linked image shows what appear to be tables, and the little arrows appear to represent entity-relationships between them. But I'm not sure how you'd get useful DDL out of it -- none of the columns have types, no indices, etc.!
Maybe an LLM could sketch out a DDL skeleton from a picture, which someone could use as a starting point?