31–40 of 67 posts
These noSql people are missing the point of relational modeling, that you can easily incrementally evolve your data model. It's why object databases never caught on. SQL databases are absolutely beautiful and elegant when you think of them in terms of the codd relational model, in my opinion the best thing that computer science has produced so far. The only limitation of relational databases currently is their lack o…
I love the document record pattern. I use this on google app engine, which is a tad tricky to use as a relational db. It actually ends up being way simpler and faster. For instance, you can model an app with just one "table" (Kind). You can put say a user id primary key, then have blob binary data fields which store your serialized document records. The reason it's so fast is all you're doing is a simple index scan t…
Earlier quoted context omitted.
Appengine's GQL is a very limited subset of SQL. The only queries which can be performed are those that can scale well, so it's doubtful that even simple things like JOINs will be supported in the future. http://code.google.com/appengine/docs/python/datastore/gqlre...
Appengine datastore works by creating indexes for every query. In relational databases you make joins execute fast by creating indexes. I don't see why joins couldn't be added to appengine.
There is no explanation of why a filesystem is a bad place to store "binary blobs". If you're collapsing the metrics that you're storing IN SQL there is something really wrong going on. Logs are OK to store in SQL, assuming you're scraping your logs properly and are logging the proper things. Logging every clickthrough in a relational database is somewhat insane. Logging 10 minutes worth of aggregate clickthroughs is…
Earlier quoted context omitted.
Appengine datastore works by creating indexes for every query. In relational databases you make joins execute fast by creating indexes. I don't see why joins couldn't be added to appengine.
I believe there's a few reasons. one is that the google file system blocks that bigtable runs on and "reads" for your query could be on any number of machines. been a while since I read the google architecture papers but I would recommend it to all. it is fascinating how they implemented gfs, bigtable, chubby lock, etc. the work around is essentially to write your own code that does what a database does - something t…
There's definitely a lack of imagination when it comes to proponents of NoSQL solutions, and this article shows no exception. While we do want to store, for example, an entire e-commerce order in a single operation we also don't necessarily want to retrieve it that way. That type of storage makes otherwise simple operations considerably more difficult. Do you want to know how much you made in sales today? How many of…
Did you use any NoSQL solution seriously? Let's see some examples (imaginary python-like interface, so I don't have to be language/backend-specific). Like you say: Start writing code. Do you want to know how much you made in sales today? sum(amount in db.filter(type='order', date=xxx)) -vs- SELECT SUM(amount) FROM order WHERE date=? How many of widget #453 are still in stock? (IRL it's never that simple, but...) db.f…
sum(amount in db.filter(type='order', date=xxx))
As for API, you can hide the SQL pretty well behind an abstraction as well. But there is an advantage to using SQL itself -- the database engine analyzes your query and produces the most optimal way to get the answer you want. You're choosing to write poorly optimized code instead.
These noSql people are missing the point of relational modeling, that you can easily incrementally evolve your data model. It's why object databases never caught on. SQL databases are absolutely beautiful and elegant when you think of them in terms of the codd relational model, in my opinion the best thing that computer science has produced so far. The only limitation of relational databases currently is their lack o…
Earlier quoted context omitted.
And you can easily and incrementally evolve your data model in an object database too with the added benefit that the application is updated to match the new data model at the same time. > SQL databases are absolutely beautiful and elegant when you think of them in terms of the codd relational model And horrible and brittle in terms of the application model, which in 99% of cases is not relational.
"""And horrible and brittle in terms of the application model, which in 99% of cases is not relational.""" I refer you to Philip Greenspun's explanation of why object databases don't work - """After 10 years, the market for object database management systems is about $100 million a year, perhaps 1 percent the size of the relational database market. Why the fizzle? Object databases bring back some of the bad features…
Treating the data as if it's separate from the application just leads to a big ball of mud schema that many apps share and the whole mess becomes a big steaming pile of crap that no one wants to change for fear of breaking a bunch of applications. The temptation to share state through the database is too strong. By focusing on the program, OODB's push you towards having each app with it's own db and programs interacting with each other through services, a much better architecture that's much easier to evolve applications independently with.
Exporting data from the application to a relational database for reporting reasons is trivial for those times you need it. Greenspun is simply wrong, object databases do work, and they work well for their intended domain.
Earlier quoted context omitted.
SQLite scales down fine, FWIW. It's just not appropriate past a certain amount of concurrent writes, but it's great for prototyping and smaller services.
That is a clever idea I'd not thought of, but it isn't really multitenant -- it just pushes the problem down into the filesystem. It also requires a discontinuous transition to a different SQL database once you graduate from being a small-fry, and from there you're in the same boat as everyone else trying to scale that to multiple machines without application changes.
On the upside, SQLite will take disk space, memory, and CPU proportional to actual usage, and compared to (say) Ruby or Python, it's a drop in the bucket.
As to the discontinuous transition between it and a bigger system, sure. It's a trade-off. So is worrying about scalability plans during early prototyping, though.
Earlier quoted context omitted.
"""And horrible and brittle in terms of the application model, which in 99% of cases is not relational.""" I refer you to Philip Greenspun's explanation of why object databases don't work - """After 10 years, the market for object database management systems is about $100 million a year, perhaps 1 percent the size of the relational database market. Why the fizzle? Object databases bring back some of the bad features…
Which boils down to "relational databases are easier for non programmers to use", but I'm a programmer, I don't care. OODB's allow me to write applications much faster, and bugs affect both kinds of databases equally. Data corruption happens just as much in relational databases. I've used both, various relational db's for more than 10 years. I'm well aware of their strengths and weaknesses. Given the choice, I'll tak…
guess what - relational databases are based on the first order logic, which is the most common method for representing 'knowledge', look at prolog or opencyc.
When you write sql you're actually working in a very high level language, higher than python or ruby or the language du jour.
I doubt Philip Greenspun is wrong. He learned programming directly from people at the mit ai lab.