NoSQL

[Chiefcrowe]

I think this belongs here. anyway here is an interesting article on databases.

NoSQL, Heroku, and You

http://blog.heroku.com/archives/2010/7/20/nosql

 

[Cogman]

Interesting read. I've always felt that working with SQL databases is, well, cluncky. Especially dealing with the ODBC drivers. The whole notion of preparing statements and writing a language within a language just to interact with a database really seams like too much.

What I'd like is the ability to write in whatever language I like, that languages syntax. For example. It would be nice in c/c++ to just be able to say something like

select(tablename, dataname, columnname, ect)

or even

Myobject.store();
Myobject.retrieve();

instead, we have all this malarkey with parameter binding, ect.

 

[jvroig]

Yes, interesting. Database performance certainly varies on the application - or sometimes, in large, sprawling applications that normally encompass the enterprise, it varies between certain functions of the application.

We've tried remedying this initially by optimizing queries and the database schema. It's a big trade-off - sometimes, you get a lot of performance, sometimes not so much. What happens consistently, though, is that changing schema leads to unhappy programmers, so it rarely happens unless the new requirement/report/analysis tool really crawls and will get a 10x speedup with the schema change.

Our latest remedies so far have been dealing with those data in memory by manipulating them through arrays. In effect, a hard-coded, application-specifc NoSQL implementation. Unhappy programmers again. In fact, only very few programmers can manage to really be comfortable pulling all data in a table and just manipulating them in a couple of multidimensional arrays. Eats up memory like no tomorrow, but gets to be an order of magnitude faster in a fair number of cases.

Our next step is to try these real NoSQL solutions. We held off on it for a bit due to reluctance to invest in yet another technology (it doesn't matter if they are free or not in terms of money, but in programmers' time it is never free).

 

[jvroig]

or even

Myobject.store();
Myobject.retrieve();

instead, we have all this malarkey with parameter binding, ect.

I think some frameworks allow for that, or some ORM plug-ins/add-ons, depending on what you are working with. Haven't worked with Microsoft code for a while, but I know Microsoft had their own ORM, too.

Still feels clunky, though. Honestly, however, I like the fact that every language I've worked with didn't implement their own "datastore language". I don't know, it's just that having SQL remain the same, consistently, throughout all programming languages makes it easier for me to deal with them, even if the way the syntax for parameter binding may differ a little.

 

[PhatoseAlpha]

What kind of reliability do you get for in-memory databases like those being pointed to? The future he's pointing to is cloud services with databases in RAM. The cloud alone is enough to get me reliability concerns.

 

[beginner99]

Interesting read. I've always felt that working with SQL databases is, well, cluncky. Especially dealing with the ODBC drivers. The whole notion of preparing statements and writing a language within a language just to interact with a database really seams like too much.

What I'd like is the ability to write in whatever language I like, that languages syntax. For example. It would be nice in c/c++ to just be able to say something like

select(tablename, dataname, columnname, ect)

or even

Myobject.store();
Myobject.retrieve();

instead, we have all this malarkey with parameter binding, ect.

http://www.grails.org/

The command is:
new MyClass(property1:"string",property2:12.34).save()
and voila stored in the Database.

Query:
http://grails.org/GORM+-+Querying

Pretty cool to me but I must admit I'm not a developer just look at this stuff out of personal interest. So can't tell if it really works that easly. But there are real websites out there based on grails.

But the more complicated your application gets, the more you need to tweak it manually plus DBAs probably will never like ORM stuff.

 

[BoberFett]

SQL is fantastic, it's just not the answer to everything. You should always to use the best tool for the job, sometimes it's SQL sometimes it's not.

I worked for a company from around 2002 to 2004 who was going through serious growing pains with their software. They were a small company with two programmers on staff. The lead programmer's credentials were that he had written a game in BlitzBasic. /facepalm This guy abused SQL like I had never seen. He had set up a database with hundreds of tables all containing similar data from different sources and variable numbers of columns. Within those columns, comma delimited text. The front end systems would then build massive SQL statements with potentially hundreds of OR COLUMN79 LIKE '%,data,%' clauses. The website was riddled with SQL injection vectors, naturally.

I plugged the obvious holes, fixed some serious memory leaks that were forcing daily, quickly becoming hourly IIS resets. I wanted to rebuild that portion of the software from scratch, using a proper server/client architecture and storing the data in indexed XML files. The owner was focused on website bells and whistles instead of fixing the core, so I left and one of my subordinates was promoted to my old position. While I was still there, this guy used to argue with me that SQL was the right tool, the database just had to be normalized properly. A good programmer and a really nice guy, we're still friends, but we just disagreed on the technology. Earlier this year I talked to him and they're still limping along with the old SQL database. They've spent tons of money on hardware due to the poorly implemented searching and they need to muscle through every search. They're now considering moving to indexed XML.

 

[KIAman]

Interesting read. I've always felt that working with SQL databases is, well, cluncky. Especially dealing with the ODBC drivers. The whole notion of preparing statements and writing a language within a language just to interact with a database really seams like too much.

What I'd like is the ability to write in whatever language I like, that languages syntax. For example. It would be nice in c/c++ to just be able to say something like

select(tablename, dataname, columnname, ect)

or even

Myobject.store();
Myobject.retrieve();

instead, we have all this malarkey with parameter binding, ect.

That would be great if possible but one drawback is conventional programming logic vs set logic. There are some great optimizations for a relational system that takes advantage of set math and aren't possible using conventional programming.

I'm frankly surprised that set based logic has not spawned another programming paradigm considering the trade-off between relational data and memory/cpu usage.

 

[Markbnj]

Why the name "NoSQL?" Is SQL bad? I don't think misanthropic old geezers like Oracle and SQL Server care what people think, but pity poor MySQL: it used to be one of the popular kids.

People have been trying to dethrone SQL for years. Now we have some big data transacters who have popularized the notion that SQL doesn't necessarily work for all types of data, and particularly doesn't work well for frequently read, infrequently written, partially unstructured data. We certainly have been shoehorning such data into SQL, and so from that perspective this is probably a good thing to think about, but "polyglot persistence" isn't a new idea among companies that have moved and delivered large amounts of data to disparate and non-colocated consumers.

SQL is going to remain the business standard for a long time, probably longer than I'll be alive, because it's robust, efficient, secure, well-understood, and business data often naturally decomposes into compatible formats. I don't see the strict separation of data and application layers as a liability in most cases, and while I would always like to have easier access to SQL from code (and to a great extent I've been getting it), in my experience data usually outlives the applications built to use it. So it makes sense to store it in a system with its own universal means of query and access.

 

[BoberFett]

Well said Mark.