Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Comparing Database Types

prisma.io

Post reply on HN
Print view View original

71–80 of 176 posts

Re: Comparing Database Types

#71

Post by mitchtbaum »

triska wrote: post #56
nikolasburk wrote: post #48

Earlier quoted context omitted.

Thanks for the hint, we'll update the article! :)

Related to the logical view, it would also be great to include deductive databases : https://en.wikipedia.org/wiki/Deductive_database Deductive databases derive logical consequences based on facts and rules . Datalog and its superset Prolog are notable instances of this idea, and they make the connection between the relational model and predicate logic particularly evident. Codd's 1979 paper Extending the Database Re…

It seems these rules refine the data outside the database itself. But they're so tightly integrated between the database and the application that the lines separating them become blurred.

Re: Comparing Database Types

#72

Post by kristoff_it »

> To store data, you provide a key and the blob of data you wish to save, for example a JSON object, an image, or plain text. To retrieve data, you provide the key and will then be given the blob of data back. The database does not evaluate the data it is storing and allows limited ways of interacting with it.

Definitely not a good description of Redis, even though they cite it as the first example of a Key-Value DB.

Re: Comparing Database Types

#73

Post by triska »

mitchtbaum wrote: post #71
triska wrote: post #56

Earlier quoted context omitted.

Related to the logical view, it would also be great to include deductive databases : https://en.wikipedia.org/wiki/Deductive_database Deductive databases derive logical consequences based on facts and rules . Datalog and its superset Prolog are notable instances of this idea, and they make the connection between the relational model and predicate logic particularly evident. Codd's 1979 paper Extending the Database Re…

It seems these rules refine the data outside the database itself. But they're so tightly integrated between the database and the application that the lines separating them become blurred.

Interestingly, when defining pure relations in Prolog, there is no "outside the database itself":

Both rules and facts are instances of a single unifying language element, a logical clause, which is also terminology from predicate logic.

This is useful from a conceptual perspective, and also for performance: Many automatic optimizations that deductive database systems perform apply equally to facts and rules. For instance, argument indexing is a notable feature of virtually all Prolog systems. It is similar to indices in relational databases, and can replace a linear scan of the knowledge base with a fast hash-based lookup that is performed in O(1).

Re: Comparing Database Types

#74

Post by woolcap »

tlarkworthy wrote: post #61
taffer wrote: post #47

> Relational databases get their name from the fact that relationships can be defined between tables. This is a widespread misconception. Relational databases get their name from relations in the mathematical sense[1], i.e. sets of tuples containing facts. The basic idea of the relational model is that logical predicates can be used to query data flexibly without having to change the underlying data structures. The b…

What is the relation? The table? (I.e. the tuples describing the rows). Or is it the joins? (In which case the article is correct). The columns?

One way to think about it is with a mathematical relation, like 'X > Y'. A relational database relation representing this relation would consist of a header tuple, , and a set of tuples whose values satisfy the relation, such as , , . In more common terms, the rows of this table would contain pairs of numbers in which the value of the X attribute is greater than the value of the Y attribute. This table describes the relation(ship) of certain pairs of numbers.

"Each tuple in a relation represents an n-ary relationship...among a set of n values..., and the full set of tuples in a given relation represents the full set of such relationships that happen to exist at some given time--and, mathematically speaking, that's a relation."[1]

[1] Chris Date, Database in Depth, page 46

Re: Comparing Database Types

#75

Post by tempWinHater »

ska wrote: post #58
Nican wrote: post #21

I am really tired of articles that talk about the different types of databases. People can make a graph databases act like relational databases, and vice-versa. Computers, in the end, are just a Turing machine. Just pay attention that the query that you are executing is actually doing the optimal solution. I wish more time would be spent talking about the underlying algorithms that the different query languages use t…

> Computers, in the end, are just a Turing machine. Famous last words :) Detail, in the end, really matter.

Especially when you consider that computers are approximations of Turing machines.

Edit: typo

Re: Comparing Database Types

#76

Post by [deleted] »

woolcap wrote: post #74
tlarkworthy wrote: post #61

Earlier quoted context omitted.

What is the relation? The table? (I.e. the tuples describing the rows). Or is it the joins? (In which case the article is correct). The columns?

One way to think about it is with a mathematical relation, like 'X > Y'. A relational database relation representing this relation would consist of a header tuple, , and a set of tuples whose values satisfy the relation, such as , , . In more common terms, the rows of this table would contain pairs of numbers in which the value of the X attribute is greater than the value of the Y attribute. This table describes the…

[deleted]

Re: Comparing Database Types

#77

Post by bradly »

Nican wrote: post #21

I am really tired of articles that talk about the different types of databases. People can make a graph databases act like relational databases, and vice-versa. Computers, in the end, are just a Turing machine. Just pay attention that the query that you are executing is actually doing the optimal solution. I wish more time would be spent talking about the underlying algorithms that the different query languages use t…

> I am really tired of articles that talk about the different types of databases.

I read this article and learned things I didn't know.

What would you like to have done differently? The author not write the post? Or someone not post it to HN? I don't understand your complaint. If you'd like a different article, write a different article.

Re: Comparing Database Types

#78

Post by mitchtbaum »

triska wrote: post #73
mitchtbaum wrote: post #71

Earlier quoted context omitted.

It seems these rules refine the data outside the database itself. But they're so tightly integrated between the database and the application that the lines separating them become blurred.

Interestingly, when defining pure relations in Prolog, there is no "outside the database itself": Both rules and facts are instances of a single unifying language element, a logical clause , which is also terminology from predicate logic. This is useful from a conceptual perspective, and also for performance: Many automatic optimizations that deductive database systems perform apply equally to facts and rules. For in…

> Both rules and facts are instances of a single unifying language element, a logical clause, which is also terminology from predicate logic.

Yeah; I'd like to see these general application layers more seamless and united in simple semantic units.

Like a higher level abstraction over code block elements, database record structures, and configuration setting ensambles; simply as phrases (..??) ....

Re: Comparing Database Types

#79

Post by jrapdx3 »

tlarkworthy wrote: post #61
taffer wrote: post #47

> Relational databases get their name from the fact that relationships can be defined between tables. This is a widespread misconception. Relational databases get their name from relations in the mathematical sense[1], i.e. sets of tuples containing facts. The basic idea of the relational model is that logical predicates can be used to query data flexibly without having to change the underlying data structures. The b…

What is the relation? The table? (I.e. the tuples describing the rows). Or is it the joins? (In which case the article is correct). The columns?

As a non-mathematician I've always conceived of the relations among data as existing in the queries. In a SQL query the "relation" is specified by matching columns in the tables containing the data we're looking. Conceptually indexes, etc., are system implementation details.

That's certainly not a rigorous definition but helped me keep my head straight about what I was doing.

Re: Comparing Database Types

#80

Post by minitoar »

How would you categorize something like ClickHouse or Interana or Druid? Columnar I guess, but then the description of Column-family in the article doesn't match up with my experience of how those work.
Post reply on HN