4 ms·
The section, "The Problem with Schemaless," blames the technology instead of whoever put the data in there in the first place. If the code has to handle both p
by barce 12y ago
The section, "The Problem with Schemaless," blames the technology instead of whoever put the data in there in the first place.
If the code has to handle both page.title and page_title, this is a feature of using a schemaless technology.
Also, lots of the issues the author had with MongoDB are also to be found in MySQL, e.g. taking hours to recover from a corrupt database/datastore.
- acveilleux 12y agoIt's just that if you have a sizable team (or worse over a long time with low overlap) working on a product, you intrinsically get an accumulation of duplicates, deprecated, or both "keys" in your schema-less schema. With a DB that enforces a schema, the overhead of modifying the schema tends to moderate that nature. I once worked in a lab (Ph.D. students are atrocious programmers BTW) where I introduced a schema-less store (cheesy K/V store) to handle some mundane metadata caching on some medical imaging. It was intended to store 4-5 attributes per PK, I never touched it after setting it up for what I needed but showed it to colleagues. Fast forward 10 years and there were something like 3000 attributes defined. Several hundreds of which were serialized blobs. Huge amount of overlap between the different attributes. Almost all that because people didn't know what was already in there so they just did their own thing.