4 ms·

Interesting. I wonder what does a NoSQL one look like?

by markus_zhang 2y ago

rcaught 2y ago
It looks like one you shouldn't implement.
- markus_zhang 2y ago
  May I ask why? Actually I never used a NoSQL one so curious.
  - irisgrunn 2y ago
    Because events are related to users and they both are related to timezones and events can be related to each other. MongoDB is really good for storing big blobs of data you want to retrieve quickly, with some basic search and index, but it's awful at relations between data.
    - markus_zhang 2y ago
      Ah I see what you mean. That makes sense!
  - Lutger 2y ago
    The for most people somewhat counter-intuitive answer is that NoSql is very rigid. It is counter intuitive, because having no required schema up front appears to be more flexible, not less. However, having your database not handle schema means your application must do it, there is no way around it. If you ask for an DayEvent and you get back something totally different, what do you do? The rigidness in most NoSql (assuming some form of document store like MongoDB) comes from its inability to combine data in new ways in a performant manner (joins). This is what SQL excels at. That implies you need to design your data in exactly the way it is going to be consumed, because you can't easily recombine the pieces in different ways as you iterate your application. Generally you must know your data access patterns in advance to create a well behaved NoSql database. Changes are hard. This is rigid. Thus, it actually makes more sense to go from sql to a nosql, as you gain experience and discover the data access patterns. The advantage of nosql is not flexibility, that is actually its disadvantage! The advantage is rather its horizontal scalability. However, a decent sql server with competently designed schema will go a very long way.
    - redwood 2y ago
      I think you have a very thoughtful take but believe it's a mistake to think of 'NoSQL' as a monolithic category.. There's a very wide spectrum from having an evolvable document oriented data model with evolvable strongly consistent secondary indexes, transactions, aggregations, and joins to simplistic key/value stores like DynamoDB and Cassandra that do force you into a very much waterfall posture that I think you are spot on in pointing out.
evnix 2y ago
I call it the "Build now, cry later" approach.
- shreddit 2y ago
  Second that, i’ve built multiple services with MongoDB just to port them now (and probably for some time) to postgres.
  - markus_zhang 2y ago
    Just curious why? I have never worked with NoSQL but I always envy the people who does that because they are a bit further away from business than us data warehouse modellers. They are usually our upstream, paid more and less hassle from business.
  - irisgrunn 2y ago
    That only makes sense if you wanted to store relational data in a NoSQL database (and that's not what Mongo is meant to do)
    - threeseed 2y ago
      And if your business is okay with all of your data living in a single instance. Because PostgreSQL is unacceptably poor at HA/replication compared to MongoDB.
      - spacebanana7 2y ago
        Is that really true these days? Setting up Postgres read replicas with automatic fail over across multiple machines is pretty trivial in the cloud with services like RDS, spanner etc. And although doing it in your own datacenter is still a big job it's far from impossible.
      - sgarland 2y ago
        Huh? Replicas are easy, and hot standby nodes aren’t that hard either. There are also various active-active solutions if you need that.
captn3m0 2y ago
I've been building something using a JSON-blob inside SQLite using the Schema.org/Event schema. It's turning out okay.
petalmind 2y ago
Up to chapter 6 the method is completely database-independent. In chapter 7, a classic relational table approach is explained. You can choose a different approach if you want to use something like Cassandra, MongoDB or DynamoDB (or some other NoSQL solution). I am not an expert in all three, but I hope some day to write "alternative ending" for this tutorial and show how it can be applied in those environments. Whatever database you choose, you still must do all the work of logical modeling (first six chapters) for your application. If you don't do that explicitly, you would have just to do that implicitly, intertwined with physical design and thus inherently more confusing.

Interesting. I wonder what does a NoSQL one look like?

rcaught 2y ago

It looks like one you shouldn't implement.

markus_zhang 2y ago
May I ask why? Actually I never used a NoSQL one so curious.
- irisgrunn 2y ago
  Because events are related to users and they both are related to timezones and events can be related to each other. MongoDB is really good for storing big blobs of data you want to retrieve quickly, with some basic search and index, but it's awful at relations between data.
  - markus_zhang 2y ago
    Ah I see what you mean. That makes sense!
- Lutger 2y ago
  The for most people somewhat counter-intuitive answer is that NoSql is very rigid. It is counter intuitive, because having no required schema up front appears to be more flexible, not less. However, having your database not handle schema means your application must do it, there is no way around it. If you ask for an DayEvent and you get back something totally different, what do you do? The rigidness in most NoSql (assuming some form of document store like MongoDB) comes from its inability to combine data in new ways in a performant manner (joins). This is what SQL excels at. That implies you need to design your data in exactly the way it is going to be consumed, because you can't easily recombine the pieces in different ways as you iterate your application. Generally you must know your data access patterns in advance to create a well behaved NoSql database. Changes are hard. This is rigid. Thus, it actually makes more sense to go from sql to a nosql, as you gain experience and discover the data access patterns. The advantage of nosql is not flexibility, that is actually its disadvantage! The advantage is rather its horizontal scalability. However, a decent sql server with competently designed schema will go a very long way.
  - redwood 2y ago
    I think you have a very thoughtful take but believe it's a mistake to think of 'NoSQL' as a monolithic category.. There's a very wide spectrum from having an evolvable document oriented data model with evolvable strongly consistent secondary indexes, transactions, aggregations, and joins to simplistic key/value stores like DynamoDB and Cassandra that do force you into a very much waterfall posture that I think you are spot on in pointing out.

evnix 2y ago

I call it the "Build now, cry later" approach.

shreddit 2y ago
Second that, i’ve built multiple services with MongoDB just to port them now (and probably for some time) to postgres.
- markus_zhang 2y ago
  Just curious why? I have never worked with NoSQL but I always envy the people who does that because they are a bit further away from business than us data warehouse modellers. They are usually our upstream, paid more and less hassle from business.
- irisgrunn 2y ago
  That only makes sense if you wanted to store relational data in a NoSQL database (and that's not what Mongo is meant to do)
  - threeseed 2y ago
    And if your business is okay with all of your data living in a single instance. Because PostgreSQL is unacceptably poor at HA/replication compared to MongoDB.
    - spacebanana7 2y ago
      Is that really true these days? Setting up Postgres read replicas with automatic fail over across multiple machines is pretty trivial in the cloud with services like RDS, spanner etc. And although doing it in your own datacenter is still a big job it's far from impossible.
    - sgarland 2y ago
      Huh? Replicas are easy, and hot standby nodes aren’t that hard either. There are also various active-active solutions if you need that.

captn3m0 2y ago

I've been building something using a JSON-blob inside SQLite using the Schema.org/Event schema. It's turning out okay.

petalmind 2y ago

Up to chapter 6 the method is completely database-independent. In chapter 7, a classic relational table approach is explained. You can choose a different approach if you want to use something like Cassandra, MongoDB or DynamoDB (or some other NoSQL solution). I am not an expert in all three, but I hope some day to write "alternative ending" for this tutorial and show how it can be applied in those environments. Whatever database you choose, you still must do all the work of logical modeling (first six chapters) for your application. If you don't do that explicitly, you would have just to do that implicitly, intertwined with physical design and thus inherently more confusing.