6 ms·

> But these two camps of databases are slowly converging too, with JSON datatype support in MySQL and PostgreSQL, and pseudo-JOINs and transactions in MongoDB.

• mulmen 5y ago
  All you need for normalization is a consistent schema. SQL DDL on an RDBMS can do that but you could just do it with OO patterns. This is what my team does. My prediction is that the next fad in database land will be normalized NoSQL. We can call it NoNoSQL. e: Better idea. No2SQL.
  • gregjor 5y ago
    I’m not sure you understand normalization. A consistent schema is the product of proper normalization, not the other way around. Normalization is a logical process, part of database design. It’s not a by-product of a schema or design pattern, nor is it an implementation detail. OO is ultimately based on pointers, even when hidden as inheritance, or called something else (references, composition). That form of organizing data is not relational pretty much by definition. You can’t” just do that [normalization] with OO patterns.” I’m not even sure what that means.
    • pjmlp 5y ago
      I guess because in practice not everyone bothers to normalize, and many RDMS have native support for table inheritance.
      • jussij 5y ago
        While that is very true, it doesn't deter from the fact good relational database design relies on the design being well normalized. By skipping the normalization steps you end up with a design that is far from optimal.
        • pjmlp 5y ago
          Which is why query optimization engines try their best to work around that, and most RDMS support JSON as native types.
          • gregjor 5y ago
            JSON is a serialization format, not a database schema. We went through this exact same thing with XML, also widely supported as a type in relational databases. Some people didn't understand that XML is not a database and went ahead to write all kinds of nonsense around it. JSON is far less rigorous (and far less bloated) than XML, it's closer to a CSV file. It's a great format for a lot of things but it's not a database. From the Wikipedia article on JSON, right at the top: "JSON (JavaScript Object Notation) is an open standard file format and data interchange format that uses human-readable text to store and transmit data objects consisting of attribute–value pairs and arrays (or other serializable values). It is a common data format with a diverse range of functionality in data interchange including communication of web applications with servers." Looks like JSON schemas are in the works, so we'll probably go through the whole XML as a database bullshit all over again.
            • themulticaster 5y ago
              I think you're a little late to the party. JSON Schemas have been a thing for over 10 years now (source: https://datatracker.ietf.org/doc/html/draft-zyp-json-schema-01 https://datatracker.ietf.org/doc/html/draft-zyp-json-schema-..., see also https://json-schema.org/ https://json-schema.org/).
    • mulmen 5y ago
      No2SQL is just physically implementing a normalized logical model on a NoSQL database instead of an RDBMS. That can be done with classes, methods, and attributes (OOP) providing RDBMS functionality like constraints and data types. In DynamoDB you can use a single table model [1] to construct collections, which are similar to joins. The partition key is like a foreign key in an RDBMS. The sort key is like a combination of the normalized table identifier and primary key. All of this can be as transparent to the business logic as it is in an RDBMS. [1]: https://www.alexdebrie.com/posts/dynamodb-single-table/ https://www.alexdebrie.com/posts/dynamodb-single-table/
      • gregjor 5y ago
        That's an optimization known as denormalizing, often seen in BI systems intended for querying (no updates). It's not a different kind of normalization, it's explicitly denormalized to suite DynamoDB. The relational model is independent of physical implementation (by definition). It's a logical model. Designing for or around the physical implementation (storage or performance characteristics) may be necessary sometimes, but it's also a red flag. The article you linked repeats the canard about joins: "While convenient, SQL joins are also expensive. They require scanning large portions of multiple tables in your relational database, comparing different values, and returning a result set." Joins may be expensive, but in a well-designed relational schema joins are done on indexed columns, so there's no "scanning large portions of multiple tables" involved, the time complexity is O(log2 N), not exponential. The claim that SQL databases don't scale is rather obviously belied by the widespread (to the point of exclusive) use of large relational databases at scale. That doesn't mean relational databases address every business requirement, but they certainly do scale. When I hear this I assume the person saying it has never used Oracle or worked at a large company. The problem with NoSQL databases isn't so much (lack of) schemas, it's lack of ACID guarantees. Those may not make much difference in some applications, but to big companies with important databases something like MongoDB with "eventual consistency" doesn't cut it. I suppose someone could implement something that looks relational in OOP, but it's not a good fit. Imagine a class structure intended to implement customers and orders. How in the OO version do you do even simple things, like enforce uniqueness? How do you distribute this model, or replicate it? How do you accomplish joins without exponential time complexity? How do the objects persist (durability is the D in ACID)? Without ACID properties you don't even have a database, much less a relational database.
  • valenterry 5y ago
    Upvoted for the No2SQL pun.
• vlaaad 5y ago
  Datomic: https://www.datomic.com/ https://www.datomic.com/
• ausbah 5y ago
  Mongo has strong relational capabilities I believe