3 ms·
+1 for a SQL layer/interface. Would massively increase utility of FDB.
by DLA 8y ago
+1 for a SQL layer/interface. Would massively increase utility of FDB.
- whatshisface 8y agoI remember this being talked about since before the fist FDB release. I think the only reason we don't have one yet is because SQL is not nearly as cool as everything else in Foundation. ;)
- htfy96 8y agoHaven't tested yet, but I was wondering if it's possible to use TiDB as SQL layer. [0] [0]: https://github.com/apple/foundationdb/issues/198 https://github.com/apple/foundationdb/issues/198
- amirouche 8y agohttps://forums.foundationdb.org/t/sql-layer-in-foundationdb/94?u=amirouche https://forums.foundationdb.org/t/sql-layer-in-foundationdb/...
- zzzcpan 8y agoHave you tried CockroachDB, TiDB? Or why do you think SQL could increase utility? It would make things slow and unpredictable, something distributed databases already struggle with.
- DLA 8y agoI am a huge fan of CockroachDB. Using it in two projects currently and it’s been fantastic. Having a SQL interface to FDB would be the glue needed to integrate FDB into many domains as a viable solution. FDB has solid k/v interfaces now, handles clustering and failures, adding a SQL layer increases its potential utility and lowers the bar for many users. To your point about slow and unpredictable sure that can be an issue - perhaps a limited SQL interface INSERT, UPDATE, DELETE, SELECT to start. Make it dirt simple to do CRUD ops.