5 ms·

Can you elaborate for those of use who weren't around in 1980?

tomsthumb 14y ago
Or 1990.....
shin_lao 14y ago
Basically the guys from MongoDB are rebuilding databases as they existed in the 1980s with the motto "we will do better than relational databases!" or "Sybase, Oracle, prepare to die!". It's not clear which problem MongoDB is trying to solve or if it is an improvement over existing technology (this is my personal opinion).
- base698 14y ago
  I think it's pretty clear to anyone who's used it. It allows for rapid, low overhead changes to your data model in the very early stages of building something new. Of course, the further along you get those changes are no longer low overhead, but at the start of the new project it's very easy to get up and running.
  - gtaylor 14y ago
    I guess I just don't find schema that big a deal even in the early goings. A relational DB schema isn't necessarily hard to change and adapt on the fly. I don't feel like this is the best thing for Mongo to hang its hat on, and I'm not sure they really are. I think its users tend to point at this as a big feature more than they should. I feel like the other reasons to use Mongo should show up more in these discussions than this "It's easy to make schema changes". Perhaps these are easier scaling/sharding, I don't know, I don't use Mongo. I just see the schema part of this as a sidepoint (albeit an important one from an application design perspective). There are legitimate cases where supremely simple schema flexibility is desirable, but I suspect a lot of people who think they need this really don't (there are easy ways to do this with relational DBs), and are in fact making some things more complicated as a result. While it IS very easy to change your schema with Mongo, let's not forget that you're going to need to enforce certain schema-related rules in your codebase instead of the DB now.
  - pkulak 14y ago
    At the start of a project it's also really easy to change an SQL schema.
    - gtaylor 14y ago
      This. I don't understand why this isn't mentioned more often. Developer convenience and productivity are important things, but the future integrity of your application shouldn't be compromised for either. There are legitimate usage cases for a non-relational document store like MongoDB, but I suspect there are a non-trivial number of people using it that would be better served by a relational DB. Or even something like Postgres that has both relational and non-relational capabilities.
    - base698 14y ago
      It's not easier than nothing. You don't have to do ANYTHING in mongo. In any reasonable sized web app with a well designed ERD changing is going to result in you stopping coding and doing some ALTER TABLE, DROP INDEX, etc commands before you can start back with the coding. Also when you want to create a report you can just write a script aggregates the data and fills another collection on the fly without creating the table first. You can even try out 6 different reports at the same time, without issuing separate create table statements.
      - gregjor 14y ago
        QED.
    - gregjor 14y ago
      It's easy to change a relational schema if you understand relational databases. If you don't then Mongo et al. look like good ideas because they solve an actual developer problem: ignorance.
      - rimantas 14y ago
        Making problem less visible (for a while) is hardly a solution.
- deleted 14y ago
  [deleted]
- themgt 14y ago
  Which RDBMS can I use to do capped collection with entries streaming live in and out, supported in the client libs with a few lines of code?
  - ivanb 14y ago
    Postgresql http://stackoverflow.com/questions/10896699/mongodb-capped-collection-equivalent-in-postgresql http://stackoverflow.com/questions/10896699/mongodb-capped-c...
- tracker1 14y ago
  What comes into play for me, is that if you are working with data, that in a traditional RDBMS would be split across several tables, where the majority of said data really isn't queried on, or even used other than as a whole, MongoDB works out better. Example, where I work we have classified ads for cars... having a structure for a listing.. { listinginfo1:...,listinginfoN:..., vehicleinfo: {...}, sellerinfo: {...} } The above example sees sellerinfo as a duplicate, but the listing/vehicle info would be broken up into several tables for an ACID/SQL database, and is mostly read. Querying against a single dataset, returning singular results shaped how you need them in the application has huge performance advantages. (Note: the old database still used for edits/updates, then exported to mongo for search/display requires over 20 joins, and +N calls to get the shape of data for a search results display. I created a view with all the base data for easier export, it's too slow to actually search against (there was a "search" table updated every half hour that was being used), and the single record for each listing in MongoDB fits better, and searches as fast as the old version on a smaller server. Another example, is when you have to pull data from many different sources, with similar shapes.. for example tracking health issues, and chemical exposure data... the core data who/what/where would be similar, but additional details may vary. Allowing for this dynamic shaping of data is difficult in most RDBMS systems. Though Postgres does have inherited tables, you would still want your structure broken out, or too flat for proper structure in an SQL db. That doesn't even go into the option in support of sharding, and replication that's far easier to configure and use than what you get with other DBs, let alone for the free version, without commercial addons. Is it perfect, absolutely not.. is it the best solution for everything, no. But the above are just a couple of examples where a non-relational database can be a better fit than SQL.
  - shin_lao 14y ago
    It was my understanding that MongoDB had poor scalability.
    - tracker1 14y ago
      It depends on your data, and how you are using it... Worst case, it should perform similar to SQL or slightly worse. If you can reliably shard your data, and don't need result sets larger than 16MB (not sure if they raised this in 2.4), you can do pretty well. Again, it depends on your data, structure and use. In some cases a traditional RDBMS is a better call. In others, for mongo, having an additional collection with your indexed subset may be the best approach. It really does depend. I don't consider it best for all cases, but do consider MongoDB a really good fit for a lot of web based cases.
mindcrime 14y ago
The Wikipedia article on Pick[1] has some good background info. This stuff is pretty "old school" but is still in use in places. Funny thing... I did an A.S. in Computer Programming back in the early 90's and the community college I attended had a Prime mainframe in the IT department, and ran Pick databases. I did some "work study" stuff with the IT manager there, but never really had a chance to get deeply into the Pick stuff. I was always curious about it though, so seeing this story (and this comment) brings back memories... [1]: http://en.wikipedia.org/wiki/Pick_operating_system http://en.wikipedia.org/wiki/Pick_operating_system

Or 1990.....

Basically the guys from MongoDB are rebuilding databases as they existed in the 1980s with the motto "we will do better than relational databases!" or "Sybase, Oracle, prepare to die!". It's not clear which problem MongoDB is trying to solve or if it is an improvement over existing technology (this is my personal opinion).

base698 14y ago
I think it's pretty clear to anyone who's used it. It allows for rapid, low overhead changes to your data model in the very early stages of building something new. Of course, the further along you get those changes are no longer low overhead, but at the start of the new project it's very easy to get up and running.
- gtaylor 14y ago
  I guess I just don't find schema that big a deal even in the early goings. A relational DB schema isn't necessarily hard to change and adapt on the fly. I don't feel like this is the best thing for Mongo to hang its hat on, and I'm not sure they really are. I think its users tend to point at this as a big feature more than they should. I feel like the other reasons to use Mongo should show up more in these discussions than this "It's easy to make schema changes". Perhaps these are easier scaling/sharding, I don't know, I don't use Mongo. I just see the schema part of this as a sidepoint (albeit an important one from an application design perspective). There are legitimate cases where supremely simple schema flexibility is desirable, but I suspect a lot of people who think they need this really don't (there are easy ways to do this with relational DBs), and are in fact making some things more complicated as a result. While it IS very easy to change your schema with Mongo, let's not forget that you're going to need to enforce certain schema-related rules in your codebase instead of the DB now.
- pkulak 14y ago
  At the start of a project it's also really easy to change an SQL schema.
  - gtaylor 14y ago
    This. I don't understand why this isn't mentioned more often. Developer convenience and productivity are important things, but the future integrity of your application shouldn't be compromised for either. There are legitimate usage cases for a non-relational document store like MongoDB, but I suspect there are a non-trivial number of people using it that would be better served by a relational DB. Or even something like Postgres that has both relational and non-relational capabilities.
  - base698 14y ago
    It's not easier than nothing. You don't have to do ANYTHING in mongo. In any reasonable sized web app with a well designed ERD changing is going to result in you stopping coding and doing some ALTER TABLE, DROP INDEX, etc commands before you can start back with the coding. Also when you want to create a report you can just write a script aggregates the data and fills another collection on the fly without creating the table first. You can even try out 6 different reports at the same time, without issuing separate create table statements.
    - gregjor 14y ago
      QED.
  - gregjor 14y ago
    It's easy to change a relational schema if you understand relational databases. If you don't then Mongo et al. look like good ideas because they solve an actual developer problem: ignorance.
    - rimantas 14y ago
      Making problem less visible (for a while) is hardly a solution.
deleted 14y ago
[deleted]
themgt 14y ago
Which RDBMS can I use to do capped collection with entries streaming live in and out, supported in the client libs with a few lines of code?
- ivanb 14y ago
  Postgresql http://stackoverflow.com/questions/10896699/mongodb-capped-collection-equivalent-in-postgresql http://stackoverflow.com/questions/10896699/mongodb-capped-c...
tracker1 14y ago
What comes into play for me, is that if you are working with data, that in a traditional RDBMS would be split across several tables, where the majority of said data really isn't queried on, or even used other than as a whole, MongoDB works out better. Example, where I work we have classified ads for cars... having a structure for a listing.. { listinginfo1:...,listinginfoN:..., vehicleinfo: {...}, sellerinfo: {...} } The above example sees sellerinfo as a duplicate, but the listing/vehicle info would be broken up into several tables for an ACID/SQL database, and is mostly read. Querying against a single dataset, returning singular results shaped how you need them in the application has huge performance advantages. (Note: the old database still used for edits/updates, then exported to mongo for search/display requires over 20 joins, and +N calls to get the shape of data for a search results display. I created a view with all the base data for easier export, it's too slow to actually search against (there was a "search" table updated every half hour that was being used), and the single record for each listing in MongoDB fits better, and searches as fast as the old version on a smaller server. Another example, is when you have to pull data from many different sources, with similar shapes.. for example tracking health issues, and chemical exposure data... the core data who/what/where would be similar, but additional details may vary. Allowing for this dynamic shaping of data is difficult in most RDBMS systems. Though Postgres does have inherited tables, you would still want your structure broken out, or too flat for proper structure in an SQL db. That doesn't even go into the option in support of sharding, and replication that's far easier to configure and use than what you get with other DBs, let alone for the free version, without commercial addons. Is it perfect, absolutely not.. is it the best solution for everything, no. But the above are just a couple of examples where a non-relational database can be a better fit than SQL.
- shin_lao 14y ago
  It was my understanding that MongoDB had poor scalability.
  - tracker1 14y ago
    It depends on your data, and how you are using it... Worst case, it should perform similar to SQL or slightly worse. If you can reliably shard your data, and don't need result sets larger than 16MB (not sure if they raised this in 2.4), you can do pretty well. Again, it depends on your data, structure and use. In some cases a traditional RDBMS is a better call. In others, for mongo, having an additional collection with your indexed subset may be the best approach. It really does depend. I don't consider it best for all cases, but do consider MongoDB a really good fit for a lot of web based cases.

mindcrime 14y ago

The Wikipedia article on Pick[1] has some good background info. This stuff is pretty "old school" but is still in use in places. Funny thing... I did an A.S. in Computer Programming back in the early 90's and the community college I attended had a Prime mainframe in the IT department, and ran Pick databases. I did some "work study" stuff with the IT manager there, but never really had a chance to get deeply into the Pick stuff. I was always curious about it though, so seeing this story (and this comment) brings back memories... [1]: http://en.wikipedia.org/wiki/Pick_operating_system http://en.wikipedia.org/wiki/Pick_operating_system