Don't let one random person dissuade you but my take is that while you consider your text format simple its one more thing I'd have to learn the structure and symbols for.
An other issue you have is that if someone understands the concept of foreign keys already then they've probably already figured out basic create table statements. Lastly, learning a new tool for something that is just a blip (table creation only) doesn't seem worth it.
So your audience for something like this is people that sort of get what a database is but don't know create table statements or people that struggle with tooling enough that an easier mechanism might be useful. I'd suggest pivoting to something like a spreadsheet2db tool. Where filename == database name, sheet name == table name, column name == column name. And the spreadsheet approach lets people actually provide data also. You can also roundtrip and have db2spreadsheet. Once you start supporting rows of data instead of just table creation you open up a lot more use-cases. Plus a lot of people have basic spreadsheet skills.
Everything above is completely off the cuff and I've done zero research to valid the idea. I know there are some integrations in Excel and some tools like SQL Developer partially support this. Another options (to support data in addition to table creation) might be to look into supporting markdown or restructured tables. Might be cool to be able to prototype a database from a basic doc page, markup2db.
I disagree partially. I like the idea of a simple way to get a barebones schema, and although I'd probably rather use a simplistic GUI than text, it's not bad.
My bigger problem is that the website feels unprofessional in a way that if I found it off a random google search I'd probably not come back:
1. Part of the website is a screenshot of text rather than actual text for seemingly no reason?
2. The examples aren't raw text and include HTML list elements which makes copy and pasting them awkward.
3. The rest of the website really needs to be run through a grammar checker and proofread.
4. The output of the tool is hard to read and poorly formatted.
An other issue you have is that if someone understands the concept of foreign keys already then they've probably already figured out basic create table statements. Lastly, learning a new tool for something that is just a blip (table creation only) doesn't seem worth it.
So your audience for something like this is people that sort of get what a database is but don't know create table statements or people that struggle with tooling enough that an easier mechanism might be useful. I'd suggest pivoting to something like a spreadsheet2db tool. Where filename == database name, sheet name == table name, column name == column name. And the spreadsheet approach lets people actually provide data also. You can also roundtrip and have db2spreadsheet. Once you start supporting rows of data instead of just table creation you open up a lot more use-cases. Plus a lot of people have basic spreadsheet skills.
Everything above is completely off the cuff and I've done zero research to valid the idea. I know there are some integrations in Excel and some tools like SQL Developer partially support this. Another options (to support data in addition to table creation) might be to look into supporting markdown or restructured tables. Might be cool to be able to prototype a database from a basic doc page, markup2db.