Chris Wright wrote:
On Sat, 31 Dec 2016 19:24:31 -0800, Adam Wilson wrote:
My idea: Split the data storage systems out by category of data-store.
For example:
- SQL: std.database.sql (PostgreSQL, MySQL, MSSQL, etc.)
This is doable; SQL is an ANSI and ISO standard, and it strongly
constrains what you can do with your data.
- Document: std.database.document (Mongo, CouchDB, etc.)
- Key-Value: std.database.keyvalue (Redis, etcd2, etc.)
I'm not so certain about this. CouchDB has a rather different approach to
things than MongoDB -- possibly not as divergent as Mongo from MySQL, but
far more than Postgres from MySQL.
Likewise, there are many key/value stores in existence, and they support
many different operations. For instance, it looks like etcd2 has a notion
of directories, where you can list items in a directory. Redis just lets
you list keys with a given prefix. Redis lets you modify values in-place;
etcd2 doesn't.
We could define a common subset of operations for document databases and
key/value stores, but most people probably wouldn't be satisfied with it.
There's also a question of where you'd put Cassandra in that, since it's
decidedly not a SQL database but tries to pretend it is.
Given that the Cassandra folks wrote an ADO.NET provider for it, I would
suggest that it is easiest to treat it as a SQL database from an
interface standpoint.
4. We should hide querying from the developer because they are bad at
it, security flaws, etc.
My answer: While agree in principal, especially with the security
concerns, in reality what you are asking for is an ORM. In my opinion,
that is a separate concern from a database interface, and is typically
implemented as layer over the DB interface.
We can encourage people to use prepared queries with documentation and
naming.
Precisely, my focus would be an making the API as easy as possible to
use with Parameterized Queries, and if that makes it harder to write
non-parameterized queries, oh well. :D
--
Adam Wilson
IRC: LightBender
import quiet.dlang.dev;
