 usa2kBlessedPremium,MVM join:2003-01-26 Canton, MI kudos:3 Reviews:
·VOIPo
·WOW Internet and..
| Interesting: Use a non-SQL db? They seem to go to great pains selling their DB concept. They seem to think SQL is a 1975 technology!
»www.couchbase.com/why-nosql/nosql-database
I'm not making a judgement; just thought I would share the link. |
|
 DC DSLThere's a reason I'm Command.Premium join:2000-07-30 Washington, DC kudos:2 Reviews:
·Covad Communicat..
·Verizon Online DSL
| Actually, it is. RDBMS and SQL date to the early 1970s (I was at Berkeley and IBM when it was being fleshed-out). BTW, SQL is not an actual database technology but a command language/semantics used to manipulate the contents of database containers. -- "Dance like the photo isn't being tagged; love like you've never been unfriended; and tweet like nobody is following." |
|
 PetePumaHow many lumps do you wantPremium,MVM join:2002-06-13 Arlington, VA | reply to usa2k Most technology in automobiles has been around since the 30's; it doesn't mean we shouldn't be driving cars any more. -- Fight fire with water. |
|
|
|
 cdruGo ColtsPremium,MVM join:2003-05-14 Fort Wayne, IN kudos:5 Reviews:
·Frontier FiOS
| reply to usa2k You use the best tool for the job. Many of the "benefits" Couchbase touts as advantages of NoSQL I see as disadvantages of an enterprise database for most users. While a "rigid" database schema can have it's disadvantages, I'm not sure if I'm ready for my database to have no schema or can quickly be added to as needs changed. I would think that you'd probably want to script out changes, test, stage, etc. Yeah that may not work quite the same way when you're Google or Amazon and have more servers then most of the rest of the world combined. But 99% of applications out there don't need to handle that type of infrastructure. |
|
 | 99% of most applications on the web don't need a database at all but people use one because they were told they were supposed to with no reason given. |
|
 usa2kBlessedPremium,MVM join:2003-01-26 Canton, MI kudos:3 Reviews:
·VOIPo
·WOW Internet and..
| Interesting thoughts. Thanks for the replies! I tend to think of SQL as an industry standard to interacting with a database. If you are a mega-corporation, gobbling up companies, or merging with them, I expect SQL might make customer lists and inventories easier to combine.
CouchDB seems to want to reinvent that concept is what I am gleaning from this information.
I also agree that most CMS web pages likely do not need a full RDBMS. Still, the separation, and organization of content does cry out for a database. Mere user posts may not seem like the kind of thing to hide in a database when many UNIX/LINUX tools are great at processing files and text.
I remember a cool book and UNIX program on SUN I played with years ago (early 90s) called /rdb. I see I still have the book. Some day if I get bored, I should give it another read. Lots of UNIX scripting examples.
I see it got more expensive ($84) I'm sure I would have paid under $40 back then! --
Jim, VoIP 12/2002, VOIPo 2/2007 FAH-Tool~Pets~Join Artist-247 |
|
 PToN join:2001-10-04 Houston, TX | reply to usa2k I am working on a project that uses both, they all have their pros and cons; and not everything needs a RDBMS and not everything can suited for a NoSQL DB. |
|
 cdruGo ColtsPremium,MVM join:2003-05-14 Fort Wayne, IN kudos:5 Reviews:
·Frontier FiOS
| reply to usa2k said by usa2k:Interesting thoughts. Thanks for the replies! I tend to think of SQL as an industry standard to interacting with a database. If you are a mega-corporation, gobbling up companies, or merging with them, I expect SQL might make customer lists and inventories easier to combine. How the database is interacted with has very little to do with a larger merger, acquisition, partnership, etc. And SQL is an industry standard for interacting with relational databases.
CouchDB seems to want to reinvent that concept is what I am gleaning from this information. No. They are just wanting to look at the "problem" in a different way. It's the database equivalent of procedural vs. functional vs. object oriented programming. All 3 are capable of creating an application, it's just different approaches to the same problem.
To increase capacity with a traditional RDBMS based on SQL, you throw more powerful hardware at the problem. It works to a point, and there is load balancing, clustering, etc that works to an extent. But it doesn't scale indefinitely. Databases like CouchDB and Big Table are designed to scale horizontally, however they often lack the relational integrity and ACID properties a RDBMS is suppose to maintain.
For something like Google not having each database server node having the same set of webpage versions parsed identically across all nodes isn't a problem. For a bank having all servers having the same current account balance is quite important.
I also agree that most CMS web pages likely do not need a full RDBMS. Still, the separation, and organization of content does cry out for a database. Mere user posts may not seem like the kind of thing to hide in a database when many UNIX/LINUX tools are great at processing files and text. What's a full relational database? The original base requirements for a relational database actually is fairly basic: union, intersection, difference, cartesian product, selction, projection, join, relational division. Obviously there are a lot of features that are available with today's popular RDBMS, but they build on the base features that really are the core.
Sure you can duplicate that functionality with text files, but depending on what the data is you are storing, it can be cumbersome to access. If your site has any level of dynamic content that is frequently modified (e.g. a blog with comments) then just multiple "commits" can be a problem as the file grows. Searching for a particular record also is a linear process that grows and grows the more records you add, unless you maintain some type of an index. And in doing so, you've just increased your complexity of accessing data, writing new data, etc. |
|
 jfmezeiPremium join:2007-01-03 Pointe-Claire, QC kudos:22 Reviews:
·ELECTRONICBOX
| reply to usa2k
Re: Interesting: Use a non-SQL db? Had Unix come with indexed file support out of the box, the need for database engine would have been relegated to only the largest applications such as airline reservation systems etc.
Indexed file support on VMS (RMS) and MVS (VSAM) made it very easy to make databases where you feed it a key and get the record with far less overhead than a database engine.
But because database software is profitable to software companies, they will convince you to get database software for your apps instead of using simpler indexed files. So most companies go with SQL products. And because of that, most software is written to need/support an SQL engine |
|
 cdruGo ColtsPremium,MVM join:2003-05-14 Fort Wayne, IN kudos:5 Reviews:
·Frontier FiOS
| said by jfmezei:Indexed file support on VMS (RMS) and MVS (VSAM) made it very easy to make databases where you feed it a key and get the record with far less overhead than a database engine. I got a feeling you look like the guy on the right in the comic below.

But because database software is profitable to software companies, they will convince you to get database software for your apps instead of using simpler indexed files. So most companies go with SQL products. And because of that, most software is written to need/support an SQL engine Yes, it's a conspiracy to get you to buy their software. Nevermind all the other advantages the database (RDBMS or not) give you over an indexed file. Or that there are millions of instances of databases that run on free (as in open sourced) or free (as in money) databases. |
|
 Reviews:
·Cogeco Cable
| reply to usa2k I've never looked at Couch, but I have done some work with Neo4j, a graph database product, which is a slightly different category of no-sql as Couch.
SQL is great, but has some very well known areas of 'suck' (like arbitrary depth queries on hierarchies). The graph databases seem to handle this much better. They have some other very interesting features as well, like node-level schemas and attributes on relationships.
That said, I use Neo4j mostly as a call-out when I encounter one of those 'areas of suck' in my traditional rdbms. Neo4j is a little loose for my tastes when it comes to defining my data domains. |
|