4 ms·

So why not just use a RDMS from day one?

by 6nf 7y ago

scarface74 7y ago
Because we had data that fit better in a non relational store. We stored data that created from user generated forms and we loaded data back into those forms. Why use a relational store? If you’re working with a system that will only be read and written by an object based language? Why keep converting back and forth between a relational model and an object oriented model? In C# var seniorMales = from c in context.Customers where c.Age > 65 && c.Sex == “M” Would be translated at runtime to either MongoQuery, Sql, a foreach loop, etc depending on what “context” represented. You get autocomplete and compile time checks. When you want to add an record to your Mongo collection, you work with strongly typed IMongoCollection<Customer> And the compiler will ensure that your collection stays consistent.
- 6nf 7y ago
  That doesn't make sense - how are you eventually moving to a RDBMS if your data is not suited to it?
  - scarface74 7y ago
    What do you mean how? Anything that you can store in object database you can normalize and store in an RDMS. ORMs have been translating relational models back and forth to object models for decades. In the case of Mongo, you just create one object containing other objects, lists, arrays etc and the driver serializes it to a JSON like structure and stores it as is in the collection. In the case of an RDMS, you create your C# classes to model your tables and relationships. The driver translates the LINQ to the appropriate query language.
- liability 7y ago
  > Why use a relational store? If you’re working with a system that will only be read and written by an object based language? Why keep converting back and forth between a relational model and an object oriented model? Well I can't tell you what the right choice in your system is, but in the general case I think going with a relational model by default generally makes sense because it's rather future proof. By that I mean a relational model gives you the most flexibility in the future to evolve your system in ways you couldn't/didn't anticipate when the system was initially designed.
  - scarface74 7y ago
    If your data store is behind an API you modify the API. You’re often using a different database for your OLAP and OLTP anyway.
  - xchaotic 7y ago
    I think you got it backwards. A relational schema change is required and probably a data reindex or reload when you change a data model so relational is the least flexible as opposed to something like Mongo nosql?
    - Spivak 7y ago
      If you’re just talking about storing and retrieving documents in a hierarchy with a semi-fixed format then aren’t you asking for a filesystem?
      - scarface74 7y ago
        How do you propose that you query a filesystem? In this context, we are referring to a “document” as a structured JSON document. You still have a semi known structure with fields that you can index and query.
    - irishsultan 7y ago
      A schema change can handle changes needed to existing data, if you don't do that then sure Mongo is easier, but then you've broken data in your system.
- eloff 7y ago
  I worked on a project with similar requirements. I just serialized the data with protobufs, encrypted it, and stashed it in S3. It was sensitive data so this also had the advantage of being easy to secure and audit. No point using a relational db for that kind of thing.
  - scarface74 7y ago
    And then when you need to do reports on the data and query it?
    - jaequery 7y ago
      Why not just use Postgres, set a field as jsonb, done?
      - scarface74 7y ago
        Why use Postgres just to store JSON? The entire tooling around Mongo is better for JSON Data. Not to mention the LINQ driver.... And you can’t do updates on individual JSON fields in Postgres.
        mateuszf 7y ago
        Yes you can - this is an article crated in 2017 https://www.idalko.com/crud-operations-postgres-jsonb/ https://www.idalko.com/crud-operations-postgres-jsonb/
        scarface74 7y ago
        From the article, The problematic part with PostgresSQL JSONB is modifying a JSONB column content. In any case, we totally replace the old content by a new one. So, the update operations turn to the complex queries that can lose the content. You can avoid this by performing the full JSON reorganization before the persistent operation. You still don’t have the richness of MongoQuery and the aggregation framework and the tooling around working with JSON data isn’t there. Let alone the native driver support.
zxcvbn4038 7y ago
A lot of people have difficulty trying to organize complex hierarchical data into rows and columns. A lot of places make you go through a dba to create or change a database which rubs power users the wrong way - and admittedly most of the dbas I’ve worked with are a lot more concerned with making backups fast then in your applications performance. Mongodb doesn’t make you do any of that. It doesn’t make you have authentication either. I think that’s a big reason why it got so popular.
- scarface74 7y ago
  Database versioning and migrations are a pain. I’ve tried both home grown and commercial database systems to make database changes part of the CI/CD process. I haven’t found one that I liked. When I did implement a system with C#/Mongo, I fell in love with changing my database schema just by changing my C# objects. With the C# driver you can include a Dictionary as part of your object to round trip unmapped fields. Not to mention that after you go through all of your modeling and figuring out your aggregate roots, you can just store the entire object graph with one .Add and the entire object is stored atomically without having to worry about transactions, table locks, etc. Unlike with an RDMS where your beautiful aggregate root has to constantly be composed and decomposed.
- Spivak 7y ago
  I think it’s funny that web devs pretty much abandoned hierarchical databases since they are the OG database style. I think it’s just going to take somebody shaking the cobwebs off of their X.500 manuals and making the query syntax and schemas a little more ergonomic for them to come back en vogue. It’s one thing to have the ability to mold your DB to model hierarchical data but have your DB engine support it non-awkwardly might be a game changer. People are already used to apps needing a DB, cache, queues, S3, filesystem, service discovery, that adding one more thing would hardly break the bank.

So why not just use a RDMS from day one?

by 6nf 7y ago

So why not just use a RDMS from day one?

Because we had data that fit better in a non relational store. We stored data that created from user generated forms and we loaded data back into those forms. Why use a relational store? If you’re working with a system that will only be read and written by an object based language? Why keep converting back and forth between a relational model and an object oriented model? In C# var seniorMales = from c in context.Customers where c.Age > 65 && c.Sex == “M” Would be translated at runtime to either MongoQuery, Sql, a foreach loop, etc depending on what “context” represented. You get autocomplete and compile time checks. When you want to add an record to your Mongo collection, you work with strongly typed IMongoCollection<Customer> And the compiler will ensure that your collection stays consistent.

6nf 7y ago
That doesn't make sense - how are you eventually moving to a RDBMS if your data is not suited to it?
- scarface74 7y ago
  What do you mean how? Anything that you can store in object database you can normalize and store in an RDMS. ORMs have been translating relational models back and forth to object models for decades. In the case of Mongo, you just create one object containing other objects, lists, arrays etc and the driver serializes it to a JSON like structure and stores it as is in the collection. In the case of an RDMS, you create your C# classes to model your tables and relationships. The driver translates the LINQ to the appropriate query language.
liability 7y ago
> Why use a relational store? If you’re working with a system that will only be read and written by an object based language? Why keep converting back and forth between a relational model and an object oriented model? Well I can't tell you what the right choice in your system is, but in the general case I think going with a relational model by default generally makes sense because it's rather future proof. By that I mean a relational model gives you the most flexibility in the future to evolve your system in ways you couldn't/didn't anticipate when the system was initially designed.
- scarface74 7y ago
  If your data store is behind an API you modify the API. You’re often using a different database for your OLAP and OLTP anyway.
- xchaotic 7y ago
  I think you got it backwards. A relational schema change is required and probably a data reindex or reload when you change a data model so relational is the least flexible as opposed to something like Mongo nosql?
  - Spivak 7y ago
    If you’re just talking about storing and retrieving documents in a hierarchy with a semi-fixed format then aren’t you asking for a filesystem?
    - scarface74 7y ago
      How do you propose that you query a filesystem? In this context, we are referring to a “document” as a structured JSON document. You still have a semi known structure with fields that you can index and query.
  - irishsultan 7y ago
    A schema change can handle changes needed to existing data, if you don't do that then sure Mongo is easier, but then you've broken data in your system.
eloff 7y ago
I worked on a project with similar requirements. I just serialized the data with protobufs, encrypted it, and stashed it in S3. It was sensitive data so this also had the advantage of being easy to secure and audit. No point using a relational db for that kind of thing.
- scarface74 7y ago
  And then when you need to do reports on the data and query it?
  - jaequery 7y ago
    Why not just use Postgres, set a field as jsonb, done?
    - scarface74 7y ago
      Why use Postgres just to store JSON? The entire tooling around Mongo is better for JSON Data. Not to mention the LINQ driver.... And you can’t do updates on individual JSON fields in Postgres.
      - mateuszf 7y ago
        Yes you can - this is an article crated in 2017 https://www.idalko.com/crud-operations-postgres-jsonb/ https://www.idalko.com/crud-operations-postgres-jsonb/
        scarface74 7y ago
        From the article, The problematic part with PostgresSQL JSONB is modifying a JSONB column content. In any case, we totally replace the old content by a new one. So, the update operations turn to the complex queries that can lose the content. You can avoid this by performing the full JSON reorganization before the persistent operation. You still don’t have the richness of MongoQuery and the aggregation framework and the tooling around working with JSON data isn’t there. Let alone the native driver support.

zxcvbn4038 7y ago

A lot of people have difficulty trying to organize complex hierarchical data into rows and columns. A lot of places make you go through a dba to create or change a database which rubs power users the wrong way - and admittedly most of the dbas I’ve worked with are a lot more concerned with making backups fast then in your applications performance. Mongodb doesn’t make you do any of that. It doesn’t make you have authentication either. I think that’s a big reason why it got so popular.

scarface74 7y ago
Database versioning and migrations are a pain. I’ve tried both home grown and commercial database systems to make database changes part of the CI/CD process. I haven’t found one that I liked. When I did implement a system with C#/Mongo, I fell in love with changing my database schema just by changing my C# objects. With the C# driver you can include a Dictionary as part of your object to round trip unmapped fields. Not to mention that after you go through all of your modeling and figuring out your aggregate roots, you can just store the entire object graph with one .Add and the entire object is stored atomically without having to worry about transactions, table locks, etc. Unlike with an RDMS where your beautiful aggregate root has to constantly be composed and decomposed.
Spivak 7y ago
I think it’s funny that web devs pretty much abandoned hierarchical databases since they are the OG database style. I think it’s just going to take somebody shaking the cobwebs off of their X.500 manuals and making the query syntax and schemas a little more ergonomic for them to come back en vogue. It’s one thing to have the ability to mold your DB to model hierarchical data but have your DB engine support it non-awkwardly might be a game changer. People are already used to apps needing a DB, cache, queues, S3, filesystem, service discovery, that adding one more thing would hardly break the bank.