dido:public:s_cli:05_contents:01_prt:02_basics:01_commondef:data_object
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision | |||
|
dido:public:s_cli:05_contents:01_prt:02_basics:01_commondef:data_object [2022/02/09 05:11] nick |
dido:public:s_cli:05_contents:01_prt:02_basics:01_commondef:data_object [2022/02/09 05:19] (current) nick |
||
|---|---|---|---|
| Line 47: | Line 47: | ||
| [[dido:public:ra:xapend:xapend.a_glossary:n:nosql]] Datastores, as the name implies, generally do not rely on SQL, though some may use SQL-like languages. Some, in fact, say NoSQL stands for "Not only SQL." NoSQL Datastores are generally less structured, more diverse, and newer overall than their SQL counterparts. Some common examples are listed below. (See Grant) | [[dido:public:ra:xapend:xapend.a_glossary:n:nosql]] Datastores, as the name implies, generally do not rely on SQL, though some may use SQL-like languages. Some, in fact, say NoSQL stands for "Not only SQL." NoSQL Datastores are generally less structured, more diverse, and newer overall than their SQL counterparts. Some common examples are listed below. (See Grant) | ||
| - | <html> | + | ^ Wide Column | Wide Column Stores are similar to SQL Datastores in that they use tables of rows and columns (i.e., [[ dido:public:ra:xapend:xapend.a_glossary:d:dm | Data Model ]]). The columns, however, can change with each row, creating a 2-dimensional effect.(See Grant) | |
| - | <dt>Wide Column [[ dido:public:ra:xapend:xapend.a_glossary:d:dm | Data Model ]]</dt> | + | ^ Key-Value | Key-Value Datastores are essentially hash tables, both of which can be compared to a dictionary, in which one key (a word entry) corresponds to many underlying fields of information. The underlying fields for the keys in Key-Value Datastores can vary from key to key, lending the system a great deal of flexibility in the data it can store. The key-value-pair system matches well with object-oriented programming, and since a key's values are not predetermined with placeholders as in a table, Datastores of this type perform very well in certain circumstances.(See Grant)| |
| - | <dd>Wide Column Stores are similar to SQL Datastores in that they use tables of rows and columns. The columns, however, can change with each row, creating a 2-dimensional effect.(See Grant) | + | ^ Graph Data Model | Graph Datastores are suited for data that is highly interconnected, because of the "relationships" (also known as "edges") it maintains between nodes. As a result, complex data lookup can perform very highly because of the existing connections between data. Since SQL Datastores implicitly compare tables of highly ordered data, SQL is poorly suited to the nature of Graphs, in which the relationships are a concrete part of the [[dido:public:ra:xapend:xapend.a_glossary:d:datastructure|data structure]]. Graphs, in fact, do not have a standardized language, and usually rely on a proprietary system.(See Grant) | |
| - | </dd> | + | ^ Document Data Model | Document-Oriented Datastores are one of the most prominent types of non-relational Datastores and are actually a variety of Key-Value Datastores. They differ mainly in the way the Datastores engine processes the data, rather than their structure. Documents are very closely related to objects in [[dido:public:ra:xapend:xapend.a_glossary:p:programlang|programming languages]], and documents are very flexible. They can have any number of fields and fields can vary between documents. Documents themselves each have a unique key used to retrieve the documents themselves, and the keys often have an index to hasten lookup. (See Grant) | |
| - | <dt>Key-Value</dt><dd>Key-Value Datastores are essentially hash tables, both of which can be compared to a dictionary, in which one key (a word entry) corresponds to many underlying fields of information. The underlying fields for the keys in Key-Value Datastores can vary from key to key, lending the system a great deal of flexibility in the data it can store. The key-value-pair system matches well with object-oriented programming, and since a key's values are not predetermined with placeholders as in a table, Datastores of this type perform very well in certain circumstances.(See Grant)</dd> | + | |
| - | + | ||
| - | <dt>Graph Data Model</dt> | + | |
| - | <dd>Graph Datastores are suited for data that is highly interconnected, because of the "relationships" (also known as "edges") it maintains between nodes. As a result, complex data lookup can perform very highly because of the existing connections between data. Since SQL Datastores implicitly compare tables of highly ordered data, SQL is poorly suited to the nature of Graphs, in which the relationships are a concrete part of the [[dido:public:ra:xapend:xapend.a_glossary:d:datastructure|data structure]]. Graphs, in fact, do not have a standardized language, and usually rely on a proprietary system.(See Grant) | + | |
| - | </dd> | + | |
| - | + | ||
| - | <dt>Document Data Model</dt> | + | |
| - | <dd>Document-Oriented Datastores are one of the most prominent types of non-relational Datastores and are actually a variety of Key-Value Datastores. They differ mainly in the way the Datastores engine processes the data, rather than their structure. Documents are very closely related to objects in [[dido:public:ra:xapend:xapend.a_glossary:p:programlang|programming languages]], and documents are very flexible. They can have any number of fields and fields can vary between documents. Documents themselves each have a unique key used to retrieve the documents themselves, and the keys often have an index to hasten lookup. (See Grant) | + | |
| - | </dd> | + | |
| - | + | ||
| - | </html> | + | |
| ===== DIDO Data Object Datastores ===== | ===== DIDO Data Object Datastores ===== | ||
dido/public/s_cli/05_contents/01_prt/02_basics/01_commondef/data_object.1644401488.txt.gz · Last modified: 2022/02/09 05:11 by nick
