68 ms·

"Today in 2017, there is no real reason to use Oracle other than in prototyping. I am happily waiting until the final nail is put on the coffin of this overhype

"Today in 2017, there is no real reason to use Oracle other than in prototyping. I am happily waiting until the final nail is put on the coffin of this overhyped, flawed relational store." Point being you can say just about the same thing about any other database. They are all flawed for one reason or another. I happen to like Mongo quite a lot, but I rarely use it. You need to understand what situations it works best in and it's unfair to both it and yourself to generalize and wish it dead.

flavio81 9y ago
Oracle RDBMS isn't flawed. It is expensive, complex to configure/mantain/extend, expensive in licensing, expensive in storage, and also expensive. Did i mention expensive? PostgreSQL is eating Oracle's customers little by little. RDBMS aren't flawed at all, this is technology that has been perfected for the last 40 years. What is flawed is to think that relational data can be easily stored on a document store (typical mistake). I think document stores are a great thing; the only problem is that MongoDB isn't a good document store.
- STRML 9y ago
  > I think document stores are a great thing; the only problem is that MongoDB isn't a good document store. To add to that - you know when you need one. If you don't know you need a document store, you don't need it. When you try a good document store, like Solr, you realize how appallingly limited Mongo really is. It's not suited for any practical use outside of demo apps.
  - threeseed 9y ago
    Solr is not a document store. It's a search engine. If you actually tried using it as one you would realise how ignorant your comment is. Both the Solr and ElasticSearch have gone on record before stating that it should never be used as the source of truth.
    - tinix 9y ago
      THIS, so much this!!!! I'm working on overhauling (rewriting, from scratch) a project right now where the previous developer decided in his infinite wisdom that using ES as a database was a good idea. I have tried repeatedly to explain to him, and the product owner, why using a search engine as a storage database is a horrific idea. Owner gets it, dev doesn't. I asked that dev if he could overhaul the project, what would he do, and he said "not use SQL at all, and use ES 100%". <_< I think this is the problem with Mongo too... you have people misusing it, and then want to throw the baby out with the bath water and act like Mongo is the problem, when really, the problem is how they are using it.
    - STRML 9y ago
      And yet - it can be used as one. "If you actually tried using it" is a wholly inappropriate thing to say to someone you don't know. We used it in a large application indexing & faceting millions of documents, and it works just fine for the practical purpose of querying & retrieving those documents. Of course, we did mate it with Postgres to build the full app. Each tool to its strength. There's no need for the vitriol.
- optimuspaul 9y ago
  Spoken like someone who have never used Oracle with something other than Java. Also expensive seems like a flaw to me.
kentosi 9y ago
"You need to understand what situations it works best in" I always hear this, but with no "such as" examples given. Could you please provide some?
- nevi-me 9y ago
  The same example I provide everywhere. I have successfully used Mongo as a geospatial data store, where I have a public transit app/website, and most objects/documents have geospatial properties. Sure, there's PostGIS, but saving a GeoJSON multiline which I can slap an index on works for me. I have grown fond of Mongo because I've been using it for almost 5 years now. I know its limitations, and also what I can do in RDBMS that I can also do in it. I sometimes build OLAP logical models at work for clients, and most of what I touch at work is SQL, but sometimes when I start a project I use Mongo instead of SQL. It's only one use-case, but I hope it is something.
  - kentosi 9y ago
    Interesting. I haven't used JSON-stores because in my mind it always boils down to the question of how you would link entities together. I can't seem to get a good answer... so let me put this to you: In a standard RDBMS I would probably have a custom datatype for LatLon (or MGRS): create custom type LatLon(...) create table Person(id as int, name as string, location as LatLon) create table Shop(id as int, name as string, location as LatLon) Find everyone 10k around Macy's: select p.* from Person p inner join Shop s where s.name="Macy's" and with_distance(p.location, s.location, 10km) How would a JSON-store be better at managing this, given that with RDBMS systems you have indexes to help speed such cross-table looks?

flavio81 9y ago

Oracle RDBMS isn't flawed. It is expensive, complex to configure/mantain/extend, expensive in licensing, expensive in storage, and also expensive. Did i mention expensive? PostgreSQL is eating Oracle's customers little by little. RDBMS aren't flawed at all, this is technology that has been perfected for the last 40 years. What is flawed is to think that relational data can be easily stored on a document store (typical mistake). I think document stores are a great thing; the only problem is that MongoDB isn't a good document store.

STRML 9y ago
> I think document stores are a great thing; the only problem is that MongoDB isn't a good document store. To add to that - you know when you need one. If you don't know you need a document store, you don't need it. When you try a good document store, like Solr, you realize how appallingly limited Mongo really is. It's not suited for any practical use outside of demo apps.
- threeseed 9y ago
  Solr is not a document store. It's a search engine. If you actually tried using it as one you would realise how ignorant your comment is. Both the Solr and ElasticSearch have gone on record before stating that it should never be used as the source of truth.
  - tinix 9y ago
    THIS, so much this!!!! I'm working on overhauling (rewriting, from scratch) a project right now where the previous developer decided in his infinite wisdom that using ES as a database was a good idea. I have tried repeatedly to explain to him, and the product owner, why using a search engine as a storage database is a horrific idea. Owner gets it, dev doesn't. I asked that dev if he could overhaul the project, what would he do, and he said "not use SQL at all, and use ES 100%". <_< I think this is the problem with Mongo too... you have people misusing it, and then want to throw the baby out with the bath water and act like Mongo is the problem, when really, the problem is how they are using it.
  - STRML 9y ago
    And yet - it can be used as one. "If you actually tried using it" is a wholly inappropriate thing to say to someone you don't know. We used it in a large application indexing & faceting millions of documents, and it works just fine for the practical purpose of querying & retrieving those documents. Of course, we did mate it with Postgres to build the full app. Each tool to its strength. There's no need for the vitriol.
optimuspaul 9y ago
Spoken like someone who have never used Oracle with something other than Java. Also expensive seems like a flaw to me.

kentosi 9y ago

"You need to understand what situations it works best in" I always hear this, but with no "such as" examples given. Could you please provide some?

nevi-me 9y ago
The same example I provide everywhere. I have successfully used Mongo as a geospatial data store, where I have a public transit app/website, and most objects/documents have geospatial properties. Sure, there's PostGIS, but saving a GeoJSON multiline which I can slap an index on works for me. I have grown fond of Mongo because I've been using it for almost 5 years now. I know its limitations, and also what I can do in RDBMS that I can also do in it. I sometimes build OLAP logical models at work for clients, and most of what I touch at work is SQL, but sometimes when I start a project I use Mongo instead of SQL. It's only one use-case, but I hope it is something.
- kentosi 9y ago
  Interesting. I haven't used JSON-stores because in my mind it always boils down to the question of how you would link entities together. I can't seem to get a good answer... so let me put this to you: In a standard RDBMS I would probably have a custom datatype for LatLon (or MGRS): create custom type LatLon(...) create table Person(id as int, name as string, location as LatLon) create table Shop(id as int, name as string, location as LatLon) Find everyone 10k around Macy's: select p.* from Person p inner join Shop s where s.name="Macy's" and with_distance(p.location, s.location, 10km) How would a JSON-store be better at managing this, given that with RDBMS systems you have indexes to help speed such cross-table looks?