It\u2019s the name of a talk I will be giving in the coming weeks. It\u2019s basically about data modelling for unstructured or semi-structured data.<\/p>\n
If you are interested I will be giving it at the following conferences:<\/p>\n
\u00a0<\/p>\n
If you have some time to spare, this is basically a write up of the talk introduction:<\/p>\n
Promises of agility and schema-less data are always around the corner for NoSQL databases. And the thing is this is all true. You can store unstructured data easily. But you\u2019ll need to apply structure when you come to actually use the data. There are various ways to apply that structure. And we\u2019re going to talk about it today.<\/p>\n
But first let\u2019s get into the Structured VS Unstructured topic. Structured data as we know it in databases traditionally refers to columns. A column has a name and a type and is grouped by table. When you try to insert a new line in that table, all of the elements on this line have to correspond to the name and type of each column. You can\u2019t add a new one on the fly or change the type dynamically.<\/p>\n
Well you could probably store everything as Strings but it kind of defeats the purpose of using database columns (it\u2019s also worth mentioning most of the column store are coming up with a Json type). So it\u2019s like having a schema. And if what you are trying to store does not fit that schema you\u2019ll get an error.<\/p>\n
Being schemaless on the other hand would let you store anything of any type. If you think about programming and data structures like Maps or Dictionaries, they are schemaless structures. If you think about a key\/value store, the value can be anything. It can be binary encoded image, a serialized object, JSON, XML, a number, etc..<\/p>\n
While there might not be any structure embedded in a binary encoded file, there is one for JSON and XML. We usually refer to it as semi-structured data. They both give you named, typed field and flexibility to add any field at any given time. It\u2019s like an implicit schema. And they both have actual schema specifications like XSD or JSON-SCHEMA.<\/p>\n
So most of the time in databases, when you hear about schemaless, it\u2019s actually closer to semi-structured data.<\/p>\n
And of course since you are storing data, you\u2019ll want to use it at one point. So that means roughly three things:<\/p>\n
\u00a0<\/p>\n
These three points coupled to the architecture of the store you are using will raise more questions:<\/p>\n
\u00a0<\/p>\n
These points will all have an impact on how you structure your data. And to do that you can add all the specifics of your domain design.<\/p>\n
I\u2019ll try to answer these questions as much as possible and by taking Couchbase as example. Couchbase is a distributed Key\/Value store and a Document database and makes a good candidate for that.<\/p>\n
So join me to learn more about Data Modeling!<\/p>\n","protected":false},"excerpt":{"rendered":"
It\u2019s the name of a talk I will be giving in the coming weeks. It\u2019s basically about data modelling for unstructured or semi-structured data. If you are interested I will be giving it at the following conferences: Java Days Kiev […]<\/p>\n","protected":false},"author":49,"featured_media":13873,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[1],"tags":[1447],"ppma_author":[9023],"class_list":["post-2003","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uncategorized","tag-data-modeling"],"acf":[],"yoast_head":"\n