2 ms·

> For example, we have dynamic programming languages, but not dynamic RDBMS (that use SQL or a close variation). Why not? JSON datatypes essentially serve tha

by paulmd 7y ago

> For example, we have dynamic programming languages, but not dynamic RDBMS (that use SQL or a close variation). Why not? JSON datatypes essentially serve that need nowadays. Postgres even lets you write queries against them. Generally, a lot of the value from RDBMS in fact comes from strong guarantees that you can make about the data you're storing (datatypes, constraints, unique indexes, etc). That's what makes them inherently better than MongoDB or whatever. But if you really just want a "misc" column (or to use PG as a key-value-store) then you can do that with a JSON column. What use-case are you looking at that wouldn't be solved by a JSON column? > And we have XML as a fairly flexible meta-standard for data structures, but why not something comparable for C-like-syntax programming languages? You could roll your own programming language without creating a parser from scratch (and hopefully mix and match behavior based on "part kits"). Well, isn't that lex and yacc?

tabtab 7y ago
Re: JSON datatypes essentially serve that need nowadays. Postgres even lets you write queries against them. Yes, but JSON columns are treated mostly different than regular columns. They are like second-class citizens that require more verbosity to work with. Dynamic Relational won't have this dichotomy. Columns are columns. Re: Well, isn't that lex and yacc? No. You could make a parser for C, Lisp, Fortran, Datalog, etc. with them. They don't offer a standard. I'm proposing a standard syntax or meta syntax. Then the common existing languages could offer a parser for this meta language similar to how they offer an XML parser. You don't have to build the XML parser yourself nor give it the parsing rules for XML, like you have to with lex/yacc. You couldn't do that with lex and yacc in a practical way, they are too big and open-ended. Re: a lot of the value from RDBMS in fact comes from strong guarantees that you can make about the data you're storing There is a time and place for static and a time and place for dynamic. Further, Dynamic Relational can incrementally apply constraints to "lock down" various aspects, as I mentioned nearby. For example, you could add a "parse check" to a given column to ensure its parse-able as a integer upon insert and/or updates. Thus, out of the box it's loosey goosey, but doesn't have to stay that way. I'm working on a write-up to explain this all with SQL examples.

by paulmd 7y ago

tabtab 7y ago

Re: JSON datatypes essentially serve that need nowadays. Postgres even lets you write queries against them. Yes, but JSON columns are treated mostly different than regular columns. They are like second-class citizens that require more verbosity to work with. Dynamic Relational won't have this dichotomy. Columns are columns. Re: Well, isn't that lex and yacc? No. You could make a parser for C, Lisp, Fortran, Datalog, etc. with them. They don't offer a standard. I'm proposing a standard syntax or meta syntax. Then the common existing languages could offer a parser for this meta language similar to how they offer an XML parser. You don't have to build the XML parser yourself nor give it the parsing rules for XML, like you have to with lex/yacc. You couldn't do that with lex and yacc in a practical way, they are too big and open-ended. Re: a lot of the value from RDBMS in fact comes from strong guarantees that you can make about the data you're storing There is a time and place for static and a time and place for dynamic. Further, Dynamic Relational can incrementally apply constraints to "lock down" various aspects, as I mentioned nearby. For example, you could add a "parse check" to a given column to ensure its parse-able as a integer upon insert and/or updates. Thus, out of the box it's loosey goosey, but doesn't have to stay that way. I'm working on a write-up to explain this all with SQL examples.