NoSQL: a non-SQL RDBMS
|
NoSQL: a non-SQL RDBMS
|
|
Data typesUnlike most other database systems, NoSQL knows nothing about data types. Everything is just a string, that occurs between one TAB character and the next one. This was done on purpose, of course, as NoSQL tables can be accessed in a number of ways, even directly with a text editor. NoSQL has no way of enforcing any data typing that we may possibly establish, so why bother about types at all. This model goes well with the plethora of text utilities that come with most Unices, and with Linux in particular, and is a very natural way of representing data, more on the human level than other conventions. The drawback is that it is up to the application to enforce data types if necessary. As I have already pointed out, NoSQL should be seen just as a simple data dictionary toolkit. Its main purpose is to attach names to slices of an otherwise flat data file. Having a dictionary means that you can reference individual pieces of data by name rather than by their physical position in the file, thus attaining a basic level of information abstraction. A table column can contain anything except physical tabs and newlines. The data itself can be anything that is considered to be text according to the local character set. A field can even contain an entire text-encoded file, i.e.the encoded equivalent of a "BLOB". Common encodings are uuencode, base64 and quoted-printable. Large fields may of course break AWK or the other utilities, but that must be seen as a limitation in those programs or in the operating system, not something pertaining to the paradigm. A valid NoSQL table needs always to contain the header. Keeping the latter in a separate file is possible but strongly deprecated. Table editing/writing/locking/unlocking/versioning should not be seen as core NoSQL features, but simply add-on facilities. In real applications the locking policy may become quite complicated and very application-specific. Locking should be provided by the application program itself according to its needs. The same is true for modifying/versioning a table and ensuring overall database consistency. The structure of a NoSQL table is record oriented, so that it can easily be manipulated by means of the countless existing UNIX utilities, which are mostly record oriented. This does not mean that a table cannot map a more complicated structure, like an XML document or any other hierarchical tree-like structure. Such "higher order" dictionaries will not pertain to the paradigm though, but rather to the application that uses the table. Trackbacks (1) | New trackback | Comments (0) | Print |
