3 ms·

Huh, weird stuff! Your linked image shows what appear to be tables, and the little arrows appear to represent entity-relationships between them. But I'm not su

by kiitos 1y ago

Huh, weird stuff! 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?

Philpax 1y ago
LLMs can infer a lot of details from "common sense" (i.e. statistical association). As a human, I can figure out what each field's types should be, so your frontier LLM could, too: https://chatgpt.com/share/680e3a90-8660-8003-998f-91ad98e32f9c https://chatgpt.com/share/680e3a90-8660-8003-998f-91ad98e32f...
- kiitos 1y ago
  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.
  - Philpax 1y ago
    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!)
    - kiitos 1y ago
      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.

by kiitos 1y ago

Philpax 1y ago

LLMs can infer a lot of details from "common sense" (i.e. statistical association). As a human, I can figure out what each field's types should be, so your frontier LLM could, too: https://chatgpt.com/share/680e3a90-8660-8003-998f-91ad98e32f9c https://chatgpt.com/share/680e3a90-8660-8003-998f-91ad98e32f...

kiitos 1y ago
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.
- Philpax 1y ago
  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!)
  - kiitos 1y ago
    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.