8 ms·

I do encourage any SQL user, who hasn't already tried MongoDB, to fire it up and try it themselves. Mongoid in Ruby is fairly fast to get started. I've been us

• bad_user 14y ago
  Experimenting with new technologies is encouraged, especially since cross-pollination of ideas happen this way. However I would actually advise developers to stop and think if they really need MongoDB or the latest fad, because their current relational database, such as PostgreSQL, does a mighty fine job for most of their needs. Why? Because I have never seen angry opinions about PostgreSQL losing people's data. Or about how the modeling tools and architecture exposed by PostgreSQL are insufficient for certain problems ... not until you're operating at Google's scale, and MongoDB won't save you there ;) give it a try before buying that you can do it all with Postgres tweaks My main problem with most NoSQL solutions is that I have to tweak the problems I have to fit the solution, instead of the other way around. Technologies that can be tweaked simply rock.
  • taligent 14y ago
    I guess if only I "woke up" I would realise that PostgreSQL is the answer to all my problems. Guess what. PostgreSQL is just another SQL database. It's definitely one of the best ones but it still stuffers from all the same issues, limitations and frustrations. Many of which stem not from the database itself but from the relational modelling and tools to support it. I use Java + MongoDB and life is significantly better now that I don't have to worry about the domain model so much. I can have lists, maps etc and can add classes or make changes seamlessly. It's worth the tradeoffs for me.
    • masklinn 14y ago
      > Guess what. PostgreSQL is just another SQL database. Uh... hstore says "I'm not quite sure what the bloody hell you're talking about". So does ltree.
    • gbog 14y ago
      Ahem, lists and maps seem a very easy thing to do in SQL. Where you get to the limits of the relational model is when three structure diversity is out of your hands, for instance a big bunch of parametrized messages.
      • taligent 14y ago
        Lists/Maps require extra tables which means more scripts, more migrations, more backups, more worry. With MongoDB all I have to do is add Map<String,String> myMap to a Java class and that's it.
        • dstorrs 14y ago
          Actually, Postgres has had an Array data type since at least v8.0. http://www.postgresql.org/docs/8.0/static/arrays.html http://www.postgresql.org/docs/8.0/static/arrays.html But yes, you're right that maps require a join table.
          • masklinn 14y ago
            > But yes, you're right that maps require a join table. Not in postgres: http://www.postgresql.org/docs/9.1/static/hstore.html http://www.postgresql.org/docs/9.1/static/hstore.html
    • einhverfr 14y ago
      I wouldn't call it just another SQL database. The extensible type system is actually really cool and you can do a lot with it, and the same goes for Listen/Notify. It's actually an application development platform in a box. But I guess here's the flip side. PostgreSQL is another relational database and and that means fundamentally it operates on sets of tuples. For anything where set operations are helpful, the relational model brings something that no other models bring to the table. I doubt I will ever see a viable ERP suite written on a NoSQL system. OTOH, there are plenty of areas where set operations are not that big of a deal. In this area, a networked, mostly reliable, multi-master replicated store of application state data is a really really cool thing. For example, imagine MongoDB as a backplane for an LDAP forest, replacing local BDB storage for something like OpenLDAP. The source data may be in a more mature data store somewhere and fed into MongoDB so if it gets lost it isn't the end of the world (just possibly some temporary business hicups). Same with, say, Root DNS root servers.
  • k_bx 14y ago
    > My main problem with most NoSQL solutions is that I have to tweak the problems I have to fit the solution, instead of the other way around. Technologies that can be tweaked simply rock. Well, I would disagree. While it's great that sql databases let you do lots of joins, I would lose imagination of my query complexity very fast (also, you can't review all sql-queries stopping people from doing joins and "where tablename.status=active" in every joined table). While MongoDB would restrict you from that, but gives you "documents". I'd say it's a lot of power of complexity-clarity (having no joins, but power-enough documents). p.s.: and yes, I agree with you that developers are ok with postgres on most of cases. more of that, it's better to have transactions and other stuff until it's performance-urgent to disable it).
  • hobb0001 14y ago
    > However I would actually advise developers to stop and think if they really need MongoDB or the latest fad, because their current relational database, such as PostgreSQL, does a mighty fine job for most of their needs. Every time I've had to use an ORM, it always became a headache sooner or later. It got to the point where I stopped even trying to perform an automatic mapping; I reverted back to using explicit SQL in my code and avoided the "abstraction" altogether. With a document store like MongoDB, though, the mapping between object and document is almost seamless. It's actually really quite comfortable.
    • mjallday 14y ago
      Can you give an example? I don't generally have these problems and would like to see if it's my way of thinking or if you're working with vastly different data to me.
      • hobb0001 14y ago
        Since the relational model is very set-oriented, it has always had a particularly hard time dealing with ordered lists. But that's really a minor thing, and is actually something an ORM can do well to abstract. My real headache with ORM has always been to get it to perform efficiently. For example, say I want to iterate through the GPA's of all the students. To do so, the ORM usually pulls in the full object model for each student - multiplying the cost of the desired operation by 10x or 100x. Now, each ORM tool usually has some tweaky knob or special declaration you can use to have it limit the fields queried, but by the time you figure out the right incantation you may as well have written the SQL yourself. But wait! The ORM tool often saves you from this sort of overhead by caching the object model in memory. Alas, therein lies my biggest headache with ORM. "There are only two hard things in Computer Science: cache invalidation, naming things, and off-by-one errors."
        • hobb0001 14y ago
          I should acknowledge that these issues apply just as much to a document store as to a relational database. However, you tend to interact with a document store differently, since there is no need for a mapping abstraction. You often just use the database primitives provided, instead of going through a 3rd party. It's akin to manually using SQL in your code, where the database naturally knows what you're asking for.
• dickeytk 14y ago
  I really wish I could agree with you, but in my experience, ActiveRecord is just way easier to deal with than Mongoid.
• mark_l_watson 14y ago
  I agree: Mongoid is great. I haven't done this in a few years, but Datamapper had the nice capability to map a singe model classes to multiple backends (e.g., use PostgreSQL for some attributes, MongoDB for others). PostgreSQL and MongoDB cover most of my data store requirements and are a pleasure to use.
  • semiquaver 14y ago
    I use datamapper pretty extensively to join mysql tables with mongodb collections, but I've always used associations between several models to do this. Do you have any links talking about this capability?
• vampirechicken 14y ago
  > SQL still has a place and MongoDB is no replacement Let's flip this: NoSQL is finding it's place in the database ecosystem. SQL is the name of a database query language, NoSQL is a term that identifies a set of new, ostensibly non-relational, data storage engines that so implement an SQL parser despite SQL being the Standard Query Language, with twenty years of history behind it. My opinion - They decided to call it NoSQL, not because SQL requires a relation database, but because writing a smart query optimizer is hard task. Much harder than writing the storage engine itself. I'd much rather access data from Mongo, Riak, Redis, and Couch using the SELECT, INSERT, UPDATE and DELETE statements that I have known since 1988, instead of having to learn four new database APIs.
  • einhverfr 14y ago
    "I'd much rather access data from Mongo, Riak, Redis, and Couch using the SELECT, INSERT, UPDATE and DELETE statements that I have known since 1988, instead of having to learn four new database APIs." Doesn't work because those are set operations which are meaningless outside the relational world. If you want to use set operations, use a relational database.
    • vampirechicken 14y ago
      I'm going to disagree. A partial implementation of SQL would go a long way to clearing the stigma of "You old RDBMS users don't know what you're doing" that NoSQL engenders. They are database operations, originally implemented against database management systems that attempt to map relational algebra (set operations) onto data stores. There is nothing in the SQL grammar that prevents its implementation outside RDBMS. > "Doesn't work because those are set operations which are meaningless outside the relational world. If you want to use set operations, use a relational database." I don't want to do set operations, I want to retrieve data. SELECT * FROM user_collection WHERE city = 'Bronx' expresses a desire for data, not a desire to perform a bunch of set operations, and should be functionality that is provided but the database vendor since we've had SQL since the 1980s and "everybody" knows SQL. Take a look at this page form MongoDB's web site: http://www.mongodb.org/display/DOCS/Mongo+Query+Language http://www.mongodb.org/display/DOCS/Mongo+Query+Language It is telling that they explain API examples in terms of SQL SELECT statements. I infer that if they wanted to do the work they could provide a SQL processor, and extrapolate to every other API-only datastore.
• shykes 14y ago
  Here's a quick an easy way to deploy both Mongo and Postgres, and start comparing them: git clone http://github.com/shykes/sqlwars cd sqlwars pip install dotcloud dotcloud create sqlwars dotcloud push sqlwars # Open mongo shell dotcloud run sqlwars.mongo mongo # Open postgres shell dotcloud run sqlwars.postgres psql Happy hacking!