5 ms·
> oh, so you're implementing schema in your application? Isn't that where the schema belongs? Each document represents a conceptual whole. It doesn't contain
by radicalbyte 15y ago
> oh, so you're implementing schema in your application?
Isn't that where the schema belongs? Each document represents a conceptual whole. It doesn't contain fields which have to be NULL simply because they weren't in previous versions of the schema.
I've been an rdbms guy (datawarehousing/ETL) for a long time now, I've seen a lot of large databases which have been in production for considerable time. They get messy. Really messy. They become basically unmaintainable. Apples, oranges and pears all squashed into a schema the shape of a banana.
It's a pretty elegant solution, and is the problem XML/XSD were designed to solve.
The cleanest solution that I've seen in production used a relational database as a blob storage for XML-serialized entities. Each table defined a basic interface for the models, but each model was free to use its own general schema. After 10 years it contained a set of very clean individual entities which were conceptually correct.
As opposed to the usage as a serialization format for remoting, which has been largely replaced with JSON.
- alexchamberlain 15y agoI am a schemaless believer. BUT (big BUT) have you ever tried to program to a schema that has a XML blob? It's really difficult and painfully slow on the app side. The ops guys like it, because it's easy for them to maintain.
- radicalbyte 15y agoI find it much easier, but then I rely on a framework for serialization/de-serialization..
- trimbo 15y ago> isn't that where the schema belongs? [In the application] Well, unless you have, you know, multiple applications accessing said data. Then it's kind of important to keep it in sync, which is why RDBMS exist and operate the way they do. In my experience, on a long enough timeline, the probability of needing multi-application access for your data goes to 1.
- matthewcford 15y agobuild an api
- mbreese 15y agoSo you want to put an API in place to access your schema-less database? So that multiple applications can access your database in a consistent manner? That makes sense. You know what though... you may want to use multiple programming languages, and maintaining an API in multiple languages sucks. So, why not just make a service that each application can connect to, and then let it talk to your database. Then you just need to define a simple protocol that language can use to connect to your service. Or, you could just skip a few steps and use an actual database to begin with.
- verroq 15y agoBuilding an API is still a great choice no matter how good your database is. Why would you not have an API if you are using the data store from 5 difference languages?
- quadhome 15y agoIt's a shame this comment is pithy, because I think it's dead-on. There times to integrate at the database level. But, the default should be single-application databases. The rationale is the same as the grandparent's rationale FOR database integration. The odds of needing to share data over time are 1. Given that shared belief, the problem with database integration is that MANY applications need to share facets of the same data. The single database ends up having a huge surface area trying to satisfy every application's needs. The resulting schema will have definitions relevant for applications A, B, and C but X, Y and Z. But, worse, there are dependencies between each application's working schema. This means ensuring integrity becomes harder with every application that integrates. Finally, integration points are the hardest to change after-the-fact. The more services that integrate, the less ability to make the inevitable model changes necessary to fix mistakes/scale/normalize/denormalize/change solutions. Thus, "build an api" is the best solution. Well-defined APIs and data-flows between applications helps data and process locality and avoids most of the problems I just listed. The trade-off is you're now meta-programming at the process level— the complexity doesn't disappear, it's just reconceptualised.
- sausagefeet 15y ago> They get messy. Really messy. They become basically unmaintainable. Apples, oranges and pears all squashed into a schema the shape of a banana. Moving it to your application doesn't solve this problem, it just pushes it out of the DB.
- fabioferrari 15y agoExactly! In the best place you have to handle it. A nice API can make sense about the operation on the data and help it evolve. These discussions always creates in my mind a picture of someone saying that we should be refilling all the forms that you have in a cabinet full of hand filled forms because someone decided that a new version of the form requires a new field like an e-mail address.