Results 1 to 3 of 3

Thread: Types of Databases

  1. Top | #1
    Administrator lpetrich's Avatar
    Join Date
    Jul 2000
    Eugene, OR
    Total Posts
    Rep Power

    Types of Databases

    A database is a collection of data, a collection organized for easy retrieval and manipulation. There are several ways to organize databases, with some ways being very common.

    Data in a database can be treated as coming in a variety of formats, like various sizes of integer and floating-point numbers, and fixed-length and variable-length strings. Variable-length strings often have a maximum size, and a large one is often called a Binary Large Object or BLOB.

    There are several ways to organize the data in a database.

    A very common way is the relational database. In that one, the data resides in data tables, sort of like spreadsheet pages with named columns. There is a standard interface to relational databases, the Structured Query Language or SQL.

    There are other ways of organizing data, ways that are sometimes called NoSQL ("not SQL" or "not only SQL"), from needing some different interfaces.

    A simple one is key-value. The data values' "locations" in the database are the key values. One gives the software a key value to find its associated data value.

    A fancier one is document-oriented. A key can point to a list of values as well as a single value, and it can also point to sets of key-value pairs (a "document"), thus making possible the creation of a hierarchy of nested sets.

    A filesystem can be interpreted as a kind of document-oriented database.

    A graph database has a set of nodes and edges. Each node may have several edges, and each edge connects two nodes, and can be either directed or undirected. The nodes and edges can have properties, for holding the data in the database in key-value or document form.

    An object-oriented database has functions or methods associated with its data objects. One invokes an object's methods to do things with the object.

    Needless to say, one can do some kinds of databases with some other kinds of databases. It is easy to do a hierarchy or tree structure with a document-oriented database, and one can also do that with a graph database by making all the edges directed. For a relational database, one has to do something like have "Node ID" and "Parent ID" columns, and build the tree structure when one uses the database.

    Any experience with programming for databases?

  2. Top | #2
    Super Moderator
    Join Date
    Sep 2000
    Total Posts
    Rep Power
    Quote Originally Posted by lpetrich View Post
    Any experience with programming for databases?
    It can be a pain to figure out how to optimize your queries.

  3. Top | #3
    Join Date
    Nov 2017
    Rep Power
    One of the standard texts used to be Sorting And Searching by Knuth. I skimmed through it.

    A simple linked list can be a dara base.

    Data structure depends on what you want to do with data.

    A witness has a car color and a partial license plate. How do you search a DMV data base?

    Looks like there are two basic categories, relational and non relational. A spreadsheet is a relational database.

    A relational database is a digital database based on the relational model of data, as proposed by E. F. Codd in 1970.[1] A software system used to maintain relational databases is a relational database management system (RDBMS). Many relational database systems have an option of using the SQL (Structured Query Language) for querying and maintaining the database.

    The term "relational database" was invented by E. F. Codd at IBM in 1970. Codd introduced the term in his research paper "A Relational Model of Data for Large Shared Data Banks".[3] In this paper and later papers, he defined what he meant by "relational". One well-known definition of what constitutes a relational database system is composed of Codd's 12 rules. However, no commercial implementations of the relational model conform to all of Codd's rules[4], so the term has gradually come to describe a broader class of database systems, which at a minimum:

    Present the data to the user as relations (a presentation in tabular form, i.e. as a collection of tables with each table consisting of a set of rows and columns);
    Provide relational operators to manipulate the data in tabular form.
    In 1974, IBM began developing System R, a research project to develop a prototype RDBMS.[5][6] However, the first commercially available RDBMS was Oracle, released in 1979 by Relational Software, now Oracle Corporation.[7] Other examples of an RDBMS include DB2, SAP Sybase ASE, and Informix. In 1984, the first RDBMS for Macintosh began being developed, code-named Silver Surfer, it was later released in 1987 as 4th Dimension and known today as 4D.[8]

    The first systems that were relatively faithful implementations of the relational model were from:

    University of Michigan – Micro DBMS (1969)
    Massachusetts Institute of Technology (1971)[9]
    IBM UK Scientific Centre at Peterlee – IS1 (1970–72) and its successor, PRTV (1973–79)
    The first system sold as an RDBMS was Multics Relational Data Store (1978). Ingres and IBM BS12 followed.

    The most common definition of an RDBMS is a product that presents a view of data as a collection of rows and columns, even if it is not based strictly upon relational theory. By this definition, RDBMS products typically implement some but not all of Codd's 12 rules.

    A second school of thought argues that if a database does not implement all of Codd's rules (or the current understanding on the relational model, as expressed by Christopher J. Date, Hugh Darwen and others), it is not relational. This view, shared by many theorists and other strict adherents to Codd's principles, would disqualify most DBMSs as not relational. For clarification, they often refer to some RDBMSs as truly-relational database management systems (TRDBMS), naming others pseudo-relational database management systems (PRDBMS).

    As of 2009, most commercial relational DBMSs employ SQL as their query language.[10]

    Alternative query languages have been proposed and implemented, notably the pre-1996 implementation of Ingres QUEL.

    Relational model

    A NoSQL (originally referring to "non SQL" or "non relational")[1] database provides a mechanism for storage and retrieval of data that is modeled in means other than the tabular relations used in relational databases. Such databases have existed since the late 1960s, but did not obtain the "NoSQL" moniker until a surge of popularity in the early 21st century,[2] triggered by the needs of Web 2.0 companies.[3][4] NoSQL databases are increasingly used in big data and real-time web applications.[5] NoSQL systems are also sometimes called "Not only SQL" to emphasize that they may support SQL-like query languages, or sit alongside SQL databases in polyglot persistent architectures.[6][7]

    Motivations for this approach include: simplicity of design, simpler "horizontal" scaling to clusters of machines (which is a problem for relational databases),[2] finer control over availability and limiting the object-relational impedance mismatch.[8] The data structures used by NoSQL databases (e.g. key-value, wide column, graph, or document) are different from those used by default in relational databases, making some operations faster in NoSQL. The particular suitability of a given NoSQL database depends on the problem it must solve. Sometimes the data structures used by NoSQL databases are also viewed as "more flexible" than relational database tables.[9]

    Many NoSQL stores compromise consistency (in the sense of the CAP theorem) in favor of availability, partition tolerance, and speed. Barriers to the greater adoption of NoSQL stores include the use of low-level query languages (instead of SQL, for instance the lack of ability to perform ad-hoc joins across tables), lack of standardized interfaces, and huge previous investments in existing relational databases.[10] Most NoSQL stores lack true ACID transactions, although a few databases have made them central to their designs.

    Instead, most NoSQL databases offer a concept of "eventual consistency" in which database changes are propagated to all nodes "eventually" (typically within milliseconds) so queries for data might not return updated data immediately or might result in reading data that is not accurate, a problem known as stale reads.[11] Additionally, some NoSQL systems may exhibit lost writes and other forms of data loss.[12] Some NoSQL systems provide concepts such as write-ahead logging to avoid data loss.[13] For distributed transaction processing across multiple databases, data consistency is an even bigger challenge that is difficult for both NoSQL and relational databases. Relational databases "do not allow referential integrity constraints to span databases".[14] Few systems maintain both ACID transactions and X/Open XA standards for distributed transaction processing.[15]

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts