Strong and Weak Typing With Graph Databases
Whether programming systems should be strongly typed or weakly typed has been one of the longest-running controversies in the history of computer science going back something like 50 years. Generally speaking, strongly typed systems tend to require more programmer effort up-front, in exchange for earlier or more definite error reports.
We also need to distinguish between static typing and dynamic typing: a dynamically typed system enables changes of types at run-time, while a statically typed system can’t do that.
Not surprisingly, typing for graph databases (or any other kind of NoSQL database) can be implemented in different ways, too:
| Weakly typed | Strongly typed | |
|---|---|---|
| Dynamically typed |
At development time: types may be declared but are not checked except perhaps rudimentarily. At run-time: errors may occur, which may or may not be discovered; mis-interpretations of data are possible; data corruption is likely in case of programming errors. |
At development time: types are declared and checked as well as possible. At run-time: all operations are checked for type safety; types can be discovered dynamically; type mis-interpretations are not possible. |
| Statically typed |
At development time: only rudimentary checking, if at all At run-time: errors may occur, which may or may not be discovered; mis-interpretations of data are possible; data corruption is likely in case of programming errors. |
At development time: all type errors are caught; additional developer effort is required; some types of data are hard to represent At run-time: no checking required due to “correctness by construction”. |
Let’s insert some systems into this table:
| Weakly typed | Strongly typed | |
|---|---|---|
| Dynamically typed | Most NoSQL systems | InfoGrid |
| Statically typed | SQL database (if used as intended) |
Side note: when NoSQL proponents argue that weakly typed systems are much better than stronger-typed SQL, they sometimes throw out the baby with the bath water: there are four choices, not two. We agree that statically, strongly typed systems like a typical SQL database has considerable disadvantages in a fast-moving world, but so do weakly typed systems; the only difference is the type of disadvantage. In our view, a strong but dynamic type system is the best compromise for most applications with a non-trivial schema, which is why InfoGrid V2 implements it. (There are some applications that do not require a non-trivial; web caching for example.)
In a graph database like InfoGrid, the following items can be typed:
- Nodes
- Edges
- Properties
In other graph databases, only a subset of these items may be typed. More in the next post on types.
Leave a comment: