3 ms·

This is an as wide discussion as static vs dynamic typing in programming languages. Both approaches come with their pros and cons and their impact varies from p

This is an as wide discussion as static vs dynamic typing in programming languages. Both approaches come with their pros and cons and their impact varies from project to project. (re-reading this part feels pretty plain unfortunately) It's also interesting to mention that there are multiple sub-topics related: 1. schema vs no-schema 2. type checking 3. referential integrity 4. data integrity Now in reverse order: 4. every database should guarantee data integrity (i.e. you get back what you put in). 3. referential integrity is an interesting and challenging problem in the space of distributed systems that has impact on the trade-offs that the system has to make 2. type checking: while I'm not aware of any non-relational database supporting this, it is a feature that could be added at some point by basically tagging specific fields/attributes with typing information. For the time being I think people that use non-relational databases and requiring type checking are implementing it in the database access layer. But there's no good reason why it couldn't or shouldn't be supported by the database itself. 1. schema vs no-schema: IMO these two represent the two ends of a spectrum where what I think would actually make sense is support for optional schema definitions--in a way this could be similar to the way Protocol Buffers/Thrift/Avro define their protocol. alex @ rethinkdb

jdoliner 14y ago
Tagging fields in json as different types is actually something we've talked about (as you may well know given they you're my coworker). But there's another aspect of it that I think is worth mentioning. Right now RethinkDB has a very limited number of types that it can return, it's limited to JSON types so basically just object, array, strings and numbers. There are several other types that could be encode as these but you're going to wind up needing to do conversions when you insert and extract this values from the database. For example you might wind encoding and RGB value as an array of 3 numbers and your code will wind up looking like: table.insert({"color" : colorToArray(c)}).run() arrayToColor(table.get(...).run()["color"]) This obviously is cumbersome. This is the type of problem that an ORM seeks to solve. However ORMs have the big flaw of being limited to a single language and needing to be kept in sync with the database. If you did this in the database layer by having the driver convert the color object to a tagged array then it would know to return it as a color object rather than an array. Other languages could do it too using the same database since they would see the tag and could convert it to a color type in their language.
- saurik 14y ago
  The OP mentioned check constraints: what I would be looking for as a bare minimum, and which I'd imagine is low-hanging fruit, is being able to put a function on the server (as I often have numerous clients in numerous languages, and thereby want my "last stand" on data integrity to be a single piece of code written in one language as close to the data as possible) that verified the data before letting me write it; it then does not matter if the data being stored only has four data types: I can have my verifier at least check that I am storing an array with four numbers that are all integers between 0 and 255, even if I can't express "a color".

jdoliner 14y ago

Tagging fields in json as different types is actually something we've talked about (as you may well know given they you're my coworker). But there's another aspect of it that I think is worth mentioning. Right now RethinkDB has a very limited number of types that it can return, it's limited to JSON types so basically just object, array, strings and numbers. There are several other types that could be encode as these but you're going to wind up needing to do conversions when you insert and extract this values from the database. For example you might wind encoding and RGB value as an array of 3 numbers and your code will wind up looking like: table.insert({"color" : colorToArray(c)}).run() arrayToColor(table.get(...).run()["color"]) This obviously is cumbersome. This is the type of problem that an ORM seeks to solve. However ORMs have the big flaw of being limited to a single language and needing to be kept in sync with the database. If you did this in the database layer by having the driver convert the color object to a tagged array then it would know to return it as a color object rather than an array. Other languages could do it too using the same database since they would see the tag and could convert it to a color type in their language.

saurik 14y ago
The OP mentioned check constraints: what I would be looking for as a bare minimum, and which I'd imagine is low-hanging fruit, is being able to put a function on the server (as I often have numerous clients in numerous languages, and thereby want my "last stand" on data integrity to be a single piece of code written in one language as close to the data as possible) that verified the data before letting me write it; it then does not matter if the data being stored only has four data types: I can have my verifier at least check that I am storing an array with four numbers that are all integers between 0 and 255, even if I can't express "a color".