4 ms·

I use RethinkDB as the backing database for a API server written in Haskell. So I have pretty strong guarantees that the data which enters the database is sane,

I use RethinkDB as the backing database for a API server written in Haskell. So I have pretty strong guarantees that the data which enters the database is sane, and when I read it out Haskell automatically validates it against a very strict schema. SQL schemas are not expressive enough to describe the data types which I want to store in the database. The argument SQL vs NoSQL becomes moot when any database is degraded to essentially pure blob storage. What matters to me is ease of use, administration/maintenance burden, and of course speed. How strictly the database verifies the schema isn't even on the picture.

teej 12y ago
> SQL schemas are not expressive enough to describe the data types which I want to store in the database For my own edification, can you expand on this?
- stingraycharles 12y ago
  You will have to educate yourself on Haskell's type system and type category theory in general. The bottom line is that you can be very, very expressive using higher level types that simply is not possible in any database at all. Personally I like foreign keys, a lot, and couldnt live without them. I dont think Haskell's type system would be a replacement to that, and would rather use a hybrid of those two.
  - SamReidHughes 12y ago
    You don't need to learn anything about category theory to use Haskell well.
- wereHamster 12y ago
  I suspect with (non-standard?) SQL extensions and pl/sql functions you could add enough validation that is otherwise inexpressible (in standard SQL). But then you have to replicate some of that logic in your application code and the database. Anyways, let's start with something simple: sumtypes. While simple sumtypes could be described using enums, what if the alternatives have more data attached to them? data User = Anonymous | Registered UserData data UserData = UserData { userName :: UserName , registredAt :: UTCTime } Foreign keys is something that can't be easily verified in Haskell code. So that's something where a proper database still is useful.
jlarocco 12y ago
> SQL schemas are not expressive enough to describe the data types which I want to store in the database. I'm incredibly skeptical that SQL doesn't support your data types but JSON and RethinkDB do. A quick glance at the docs for PostgreSQL and RethinkDB, and the RethinkDB types are a small subset of the PostgreSQL types. It sounds to me like you just don't want to break out nested objects into separate tables. http://www.postgresql.org/docs/current/static/datatype.html http://www.postgresql.org/docs/current/static/datatype.html http://www.rethinkdb.com/docs/data-types/ http://www.rethinkdb.com/docs/data-types/
- stingraycharles 12y ago
  He's saying that Sql or NoSql dont matter in this case, since he is using Haskell's type system to verify integrity. A document database is often a better fit for data structures than a relational database, if you are not using the integrity features of a relational database anyway.
- wereHamster 12y ago
  Neither database natively supports the types I need. The decision which database to use was not at all based on that criteria. I suspect either one would be suitable (from a purely technical perspective). It is not realistic to create a separate table for each type. You'd end up with hundreds of tables (and would have to replicate the types in two places). You can only break down the types so much, at some point you'll want to have columns with your own special types which you want to treat as primitives.
NDizzle 12y ago
If you are just doing blob stores, I can get behind a document style database. I know of some people doing a lot of work with blobs that use relational databases. I know of a "Diablo clone" online RPG that uses SQL Server to store the character blobs for the people playing the game. They have a logically partitioned table, GUIDs for IDs (used for the partitioning), and just a big ass blob (somewhere between 32k and 128k) assigned to that id. I'm sure there are other items associated with the row, but that's the gist of it. They handle all of the funky stuff in the application. I don't see why that wouldn't work in a document style database, and I'm not entirely sure what the design decision was to use SQL Server. I'd like to see if they handle items in a relational manner or all of that is in the application. I wish more companies were a bit more open about their schemas and design decisions. I have done a lot of things a lot of different ways, and I'm always curious about how others have tackled similar problems.

teej 12y ago

> SQL schemas are not expressive enough to describe the data types which I want to store in the database For my own edification, can you expand on this?

stingraycharles 12y ago
You will have to educate yourself on Haskell's type system and type category theory in general. The bottom line is that you can be very, very expressive using higher level types that simply is not possible in any database at all. Personally I like foreign keys, a lot, and couldnt live without them. I dont think Haskell's type system would be a replacement to that, and would rather use a hybrid of those two.
- SamReidHughes 12y ago
  You don't need to learn anything about category theory to use Haskell well.
wereHamster 12y ago
I suspect with (non-standard?) SQL extensions and pl/sql functions you could add enough validation that is otherwise inexpressible (in standard SQL). But then you have to replicate some of that logic in your application code and the database. Anyways, let's start with something simple: sumtypes. While simple sumtypes could be described using enums, what if the alternatives have more data attached to them? data User = Anonymous | Registered UserData data UserData = UserData { userName :: UserName , registredAt :: UTCTime } Foreign keys is something that can't be easily verified in Haskell code. So that's something where a proper database still is useful.

jlarocco 12y ago

> SQL schemas are not expressive enough to describe the data types which I want to store in the database. I'm incredibly skeptical that SQL doesn't support your data types but JSON and RethinkDB do. A quick glance at the docs for PostgreSQL and RethinkDB, and the RethinkDB types are a small subset of the PostgreSQL types. It sounds to me like you just don't want to break out nested objects into separate tables. http://www.postgresql.org/docs/current/static/datatype.html http://www.postgresql.org/docs/current/static/datatype.html http://www.rethinkdb.com/docs/data-types/ http://www.rethinkdb.com/docs/data-types/

stingraycharles 12y ago
He's saying that Sql or NoSql dont matter in this case, since he is using Haskell's type system to verify integrity. A document database is often a better fit for data structures than a relational database, if you are not using the integrity features of a relational database anyway.
wereHamster 12y ago
Neither database natively supports the types I need. The decision which database to use was not at all based on that criteria. I suspect either one would be suitable (from a purely technical perspective). It is not realistic to create a separate table for each type. You'd end up with hundreds of tables (and would have to replicate the types in two places). You can only break down the types so much, at some point you'll want to have columns with your own special types which you want to treat as primitives.

NDizzle 12y ago

If you are just doing blob stores, I can get behind a document style database. I know of some people doing a lot of work with blobs that use relational databases. I know of a "Diablo clone" online RPG that uses SQL Server to store the character blobs for the people playing the game. They have a logically partitioned table, GUIDs for IDs (used for the partitioning), and just a big ass blob (somewhere between 32k and 128k) assigned to that id. I'm sure there are other items associated with the row, but that's the gist of it. They handle all of the funky stuff in the application. I don't see why that wouldn't work in a document style database, and I'm not entirely sure what the design decision was to use SQL Server. I'd like to see if they handle items in a relational manner or all of that is in the application. I wish more companies were a bit more open about their schemas and design decisions. I have done a lot of things a lot of different ways, and I'm always curious about how others have tackled similar problems.