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

Announcing MulletDB (Formerly NoNoSQL)

sheddingbikes.com

Post reply on HN
Print view View original

1–10 of 15 posts

Re: Announcing MulletDB (Formerly NoNoSQL)

#2

Post by JeffJenkins »

I don't really understand why I would want to use this. Why wouldn't I just use SQLite3, if that's what's powering the SQL searches? (maybe with a pretty layer on top for external access.)

The KV/document stores that have been coming out are trying to address shortcomings, perceived or real, with RDBMSs. I think some explanation of the trade-offs which each part of the "mullet" make and how they would be obviated by this system would be helpful. Right now there are a ton of KV/Document stores as well as SQL databases, and I don't know how this is going to be different or why I should pay attention to this project.

Re: Announcing MulletDB (Formerly NoNoSQL)

#6

Post by FraaJad »

JeffJenkins wrote: post #2

I don't really understand why I would want to use this. Why wouldn't I just use SQLite3, if that's what's powering the SQL searches? (maybe with a pretty layer on top for external access.) The KV/document stores that have been coming out are trying to address shortcomings, perceived or real, with RDBMSs. I think some explanation of the trade-offs which each part of the "mullet" make and how they would be obviated by…

* DB for persistence, kv for speed and disk for scaling(?). Different parts of your app might fit one of these cases. Why not have them all under one API?

* Use protocols to scale, not backends

* Single interface to talk to db/kv store and disk

* In addition, use an SQL-like interface, if that's what floats your boat.

* Moving data between db/kv/disk is a server side operation.

Re: Announcing MulletDB (Formerly NoNoSQL)

#8

Post by kez »

JeffJenkins wrote: post #2

I don't really understand why I would want to use this. Why wouldn't I just use SQLite3, if that's what's powering the SQL searches? (maybe with a pretty layer on top for external access.) The KV/document stores that have been coming out are trying to address shortcomings, perceived or real, with RDBMSs. I think some explanation of the trade-offs which each part of the "mullet" make and how they would be obviated by…

I don't think anyone else will understand why you would want to use it either.

More competition, more innovation, better products for us to use in the future?

You probably don't need to pay attention to this project. Did you pay attention to Google when it first launched, or Apple when it made the Newton? If you're not that interested in the database technologies, you can just not pay attention, and hope that it becomes unavoidable if it is truly remarkable in the future.

Re: Announcing MulletDB (Formerly NoNoSQL)

#10

Post by callahad »

icey wrote: post #9

So... what are the real impacts on a commercial website that uses AGPLed code?

I am not a lawyer.

If Zed does indeed release a Python driver under the MIT license, and you use that, it's essentially no different than using the LGPL in an end-user distributed app. You'd have to make any of your changes to MulletDB available to your end users, but your proprietary code could remain closed.

MongoDB takes this approach, and has written more at http://www.mongodb.org/display/DOCS/Licensing

Post reply on HN