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

Why I love databases

medium.com

Post reply on HN
Print view View original

161–170 of 172 posts

Re: Why I love databases

#161

Post by jldugger »

sklogic wrote: post #122
Pxtl wrote: post #83

I love databases, but I loathe SQL. And no, I don't mean NoSQL is better - that's throwing out the baby with the bathwater. To me, SQL is the Common Lisp of relational languages - a brilliant invention of its time that has since long-overstayed its welcome and should be replaced by modern considerations of the problem it solves. The difference is that there are a million rethinks and descendents and redesigns of LISP…

Use hierarchical DBMS is you need trees. Relational does not fit here.

TABLE tree { id INTEGER, data VARCHAR(8), left INTEGER, right INTEGER, PRIMARY KEY(id), FOREIGN KEY(right) REFERENCES tree(id) ON DELETE CASCADE FOREIGN KEY(left) REFERENCES tree(id) ON DELETE CASCADE }

Re: Why I love databases

#162

Post by AlisdairO »

cfolgar wrote: post #52

Since we're discussing databases...is there any "golden standard" learning resource/introduction to PostegreSQL? As a college student, I do not have much experience with them yet but I am aware of how important it would be to be comfortable with them in your day to development. Something tells me that my usual approach of diving in and tinkering by building out an idea wouldn't serve me as well for db's; it just seem…

Apologies for the self-plug, but you might find http://pgexercises.com/ useful for the SQL side of learning Postgres. In terms of rest of the concepts, the Postgres documentation is actually really rather good!

Re: Why I love databases

#163

Post by marknadal »

lucian1900 wrote: post #154
marknadal wrote: post #150

Earlier quoted context omitted.

CRDTs are probably the best thing out there, and the most understandable. They focus on data that does not require complicated leader election algorithms - and this is coming from Facebook and the Cassandra team. Why? Because these systems are very weak and prone toward failure, just check out some of http://aphyr.com/ 's stuff, he tears a lot of popular databases apart. Even if the theories are "proven right" the im…

None of the systems that failed aphyr's tests used a proven consensus algorithm correctly. If you look the Zookeeper test, it performed perfectly, as expected. Even etcd/Consul would pass if they chose to, the defaults are merely bad by choice. CRDTs are useful for salvaging consistency out of an inconsistent database, but they're not the only choice possible.

Good point. BUT that is a tautology - of course systems that implement it correctly are correct. Unfortunately, there are very few of those things out there... and Zookeeper etcd/Consul are all relatively new, too.

This second point goes back to my statement regarding "strong consistency can be built from eventually consistent systems, but you can't go from a strong system to an eventually consistent system." And this is where and why gun makes sense. Start with an eventually consistent system, because it is far far easier and covers 98% of the use cases out there. And only then, when you need consensus on edge-case data, build it out but make sure you understand what you are doing.

Re: Why I love databases

#164

Post by jernst »

Pxtl wrote: post #83

I love databases, but I loathe SQL. And no, I don't mean NoSQL is better - that's throwing out the baby with the bathwater. To me, SQL is the Common Lisp of relational languages - a brilliant invention of its time that has since long-overstayed its welcome and should be replaced by modern considerations of the problem it solves. The difference is that there are a million rethinks and descendents and redesigns of LISP…

Amen amen amen.

Re: Why I love databases

#165

Post by sklogic »

jldugger wrote: post #161
sklogic wrote: post #122

Earlier quoted context omitted.

Use hierarchical DBMS is you need trees. Relational does not fit here.

TABLE tree { id INTEGER, data VARCHAR(8), left INTEGER, right INTEGER, PRIMARY KEY(id), FOREIGN KEY(right) REFERENCES tree(id) ON DELETE CASCADE FOREIGN KEY(left) REFERENCES tree(id) ON DELETE CASCADE }

Now try to convince any CAD company to use this abomination to store their naturally hierarchical geometrical data. Good luck. Your RDBMS will choke to death on even most liberal performance constraints.

Re: Why I love databases

#166

Post by sklogic »

rpedela wrote: post #159
sklogic wrote: post #158

Earlier quoted context omitted.

Very interesting indeed. Is your thesis published? Btw., have you considered using a uniform memory architecture (e.g., Intel HD, or an embedded GPU)? And I still cannot understand why do you need the "R" in "RDBMS" in your case. Sound like you could have been benefited from a simple tuple storage (see a bit of discussion in this thread). I doubt you need indexes and relations.

It is published and you can find it somewhere in Purdue's library. It is not online though. It is a regret of mine that we didn't publish at a conference or journal, but at the time I was too concerned with getting out of there. I like school and research, but I didn't like the poverty. At the time (2006), embedded GPUs were not available or just becoming available. In this case, I didn't need relations but given the…

So, back to my point - you did not need specifically RDBMS. I have nothing against tuple storages, stream DBMSes, berkeley-db style caches, etc. All my hate is reserved to the relational crap.

Re: Why I love databases

#167

Post by rpedela »

sklogic wrote: post #166
rpedela wrote: post #159

Earlier quoted context omitted.

It is published and you can find it somewhere in Purdue's library. It is not online though. It is a regret of mine that we didn't publish at a conference or journal, but at the time I was too concerned with getting out of there. I like school and research, but I didn't like the poverty. At the time (2006), embedded GPUs were not available or just becoming available. In this case, I didn't need relations but given the…

So, back to my point - you did not need specifically RDBMS. I have nothing against tuple storages, stream DBMSes, berkeley-db style caches, etc. All my hate is reserved to the relational crap.

Oh I see. Specifically for RDBMS and graphics: video game engines. Game engines are a bit weird because sometimes you need hierarchical data structures, stream processing, multi-core processing (e.g. physics), etc. I worked on a game engine for a few years, but again I did not know RDBMSes would be helpful. As far as I am aware, most game engines still do not use RDBMSes, but I think there are cases where they would make life a lot easier because parts of the game engine are relational.

For example, a game object often has many properties and those properties relate to other game objects or pieces of the game engine itself. A game object usually has a graphical representation, a physical representation, a representation related to animation, etc. And you need to keep these different representations in sync. If the physical representation moves, then the other representations have to be moved in sync with the physical one. If one of the representations gets deleted, then they all need to be deleted. So tables and foreign keys would make this a lot easier. It is necessary? No because you can do it with OO, inheritance, trees, but it is actually a lot of effort to do it that way.

That is one example, but I think there are several areas where RDBMSes can be helpful inside a game engine. Just to be clear, there are several areas in a game engine where RDBMSes make no sense too.

Re: Why I love databases

#168

Post by sklogic »

rpedela wrote: post #167
sklogic wrote: post #166

Earlier quoted context omitted.

So, back to my point - you did not need specifically RDBMS. I have nothing against tuple storages, stream DBMSes, berkeley-db style caches, etc. All my hate is reserved to the relational crap.

Oh I see. Specifically for RDBMS and graphics: video game engines. Game engines are a bit weird because sometimes you need hierarchical data structures, stream processing, multi-core processing (e.g. physics), etc. I worked on a game engine for a few years, but again I did not know RDBMSes would be helpful. As far as I am aware, most game engines still do not use RDBMSes, but I think there are cases where they would…

Disclaimer: I don't know much about the graphics stuff.

Judging only by my experience in the other areas (which include CAD/CAE and GPGPU as the closest things to graphics), every time I needed to do something relational in nature, it was only dynamic data, never a relational storage. So I used quite a lot of Datalog. Never needed anything like SQL.

Re: Why I love databases

#169

Post by Pxtl »

sklogic wrote: post #165
jldugger wrote: post #161

Earlier quoted context omitted.

TABLE tree { id INTEGER, data VARCHAR(8), left INTEGER, right INTEGER, PRIMARY KEY(id), FOREIGN KEY(right) REFERENCES tree(id) ON DELETE CASCADE FOREIGN KEY(left) REFERENCES tree(id) ON DELETE CASCADE }

Now try to convince any CAD company to use this abomination to store their naturally hierarchical geometrical data. Good luck. Your RDBMS will choke to death on even most liberal performance constraints.

The point is that relational algebra happily models trees quite well.

The fact that the actual RDBMS and SQL support for trees is piss-poor should be considered a failing of those systems - users very often have data that mixes the relational model and a tree model, because a tree is a special case of a relational model. Splitting that data between two systems would be a bad solution.

Re: Why I love databases

#170

Post by sklogic »

Pxtl wrote: post #169
sklogic wrote: post #165

Earlier quoted context omitted.

Now try to convince any CAD company to use this abomination to store their naturally hierarchical geometrical data. Good luck. Your RDBMS will choke to death on even most liberal performance constraints.

The point is that relational algebra happily models trees quite well. The fact that the actual RDBMS and SQL support for trees is piss-poor should be considered a failing of those systems - users very often have data that mixes the relational model and a tree model, because a tree is a special case of a relational model. Splitting that data between two systems would be a bad solution.

> models trees quite well.

Not quite. Performance is far from acceptable, comparing with the heavily tuned hierarchical DBMSes, and I suspect it won't be easy to ever overcome it. Overhead is too big.

> because a tree is a special case of a relational model

There are many applications which do not need a relational part, when everything fits hierarchical model well. Of course, if there is a need to mix both worlds, there is no other choice but to stay within relational model.

Post reply on HN