The Need for DRE

  • Comments posted to this topic are about the item The Need for DRE

  • There are genuinely good reasons for adopting some of the NOSQL solutions.  The trick is to understand where the proposal to adopt a NOSQL solution is to satisfy a real need and with an appropriate solution.  I have seen some NOSQL adoptions as having no technical justification for moving from the established RDBMS.  There is an element of CV Driven Development and wishful thinking from the gullible end of the Gartner Hype Cycle.

    BUT.....there is also an element of rebelling against DBAs.  The irony is that NOSQL solutions require greater disciplines to be in place in order for them to be successful but the drive towards them is a rejection of those disciplines!
    Schemaless data stores require more thought with regard to data modelling precisely because you cannot rely on an enforced schema to help you or guard you from your own ineptitude.  The IT function has evolved from compartmentalised functions into a more homogeneous discipline.   As with any evolutionary process it isn't in a single state.  There are some IT departments that are the equivalent of Coelacanths but the trend is to a far more collaborative model of operation.  We simply cannot operate in isolation anymore.

    For me the most painful thing is when "my" discipline requires that something be done a certain way because I need to think of data in terms of flow but I am in a team where I am one voice amongst many.  My team's responsibilities end at the boundary of what they do.  There prime product is not something that flows anywhere.  The skills I need are more than technical, it is the ability to persuade and promote understanding.  I may be one voice in the crowd but equipped with the right "soft skills" I can bat above the average when it comes to putting my point across.

  • The idea of dumping and pumping data right into a visualization at the speed of some of these platforms is pretty appealing (at least to analytics who are constantly shifting their data requirements) compared to the traditional data warehouse where a lot of thought has to go into ingesting, conforming it to a relational model, and then exposing the data through a protected read-only layer (i.e.: cube, mart, etc).

    Both have great benefits though. The real challenge is knowing when one is better suited than the other as well adoption among the the organization when that choice is made.

  • If the intent is to persist to disk objects that traditionally were persisted to memory, like e-commerce shopping carts or a product catalog, then a NoSQL solution like MongoDB, Riak, or just XML/JPG makes sense. However, when the customer clicks the submit button and that shopping cart becomes a purchase order, then that's where the RDMS should come into the picture. There is a difference between a shopping cart and a purchase order.

    "Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

Viewing 4 posts - 1 through 3 (of 3 total)

You must be logged in to reply to this topic. Login to reply