> In my opinion this doesn't make sense.
> Part of writing SQL is also understanding the underling data. This won't address this issue.
I guess the endgoal for this is to make non-technical people also be able to efficiently work with databases. From a purely business/financial context this would save companies hours (i.e. money) onboarding/teaching employees to use their database, and even possibly remove the need to hire expensive data analysts because their lower-tier employers suddenly can interact with their databases as efficiently as they can.
edit: I also believe you're putting the cart before the horse with your reasoning. SQL and Legal English NEED to be exact, which makes them very 'complex' because you need to disallow any edge cases. This doesn't mean we WANT them to be complex. It is way more useful if it is easy and intuitive (like natural language). Matter of fact, this would save in both Legal and SQL cases a lot of time, because in both you'd often start with natural english, like 'I want to write a rent contract that protects me and my renter from legal trouble', or 'I want to know from this database which company had the highest net profit in the last quarter'. It's only then that you put money, effort and time into translating this into Legal English or SQL.
SQL is a tight, unambiguous language, that's why it exists.
This is like a legal document written in spoken English. It's only all fine when it works.
Part of writing SQL is also understanding the underling data. This won't address this issue.
This is also not replicable. Language changes in context and time.