Why New Database Technology Won’t Solve PLM Problems?

by Oleg on March 18, 2013 · 1 comment

Disruptive technologies and solutions. This is beloved topic by bloggers, analysts and vendors. We like to talk about how disruption will happen. For very long period of time, database technology was a stable element in the overall PDM/PLM technological architecture. The decision about usage of relational database was only about how to choose between Microsoft SQL, Oracle DB and IBM. However, recently, I started to hear voices about changes that might happen in the world of databases. I’m sure you’ve heard about noSQL. If not, you can catch up via this link – What PLM vendors need to know about noSQL databases? The question about the ability of noSQL or other alternative to SQL solution to disrupt PLM development and products is an interesting one. Yoann Maingon of Minerva is asking this question in his blog post – New database system for future of MDM. Yoann declares database as one of the inhibiting factors preventing users to move from one PLM solutions to another. Here is an interesting passage -

I hope the actual economy environnement will convince more people to invest time for helping the product development initiatives by solving Product Lifecycle Management related pending issues. Today’s article is about my thought on why it is always so complicated to move from a PLM solution to another, why are we changing tons of things and settings to in fact change a software cost or an interface. On of the reason is that all these elements are strictly related and the elements in a PLM solution can’t be dissociate. You can’t just keep you data and change the interface. From my previous experiences of migration, I’ve realized that I was moving data from a system to another with transformations but the data would still mean the same thing it is just that the software would handle it differently. Then speaking of standards would there be a standard for data management in PLM and should this define a technology or at least should it drive database system editors to push for one?

I’m in a bit disagreement with Yoann. In my view, all SQL, noSQL, XML and many other database flavors are providing an infrastructure that can be used in different ways. Yes, there are differences between noSQL and SQL databases. However, if we speak about building applications, the way application created will provide a much more significant factor on the efficiency and behavior of your application. Earlier this year, I’ve seen an interesting article, which focus on this specific question – NoSQL or Traditional Databases: Not Much Difference. Take you time and read it. You find it very educational. I absolutely liked the following passage -

I have spent considerable time tuning SQL statements and indexes, but in the end the best optimizations have always been those on the application and how the application uses the database. SQL Tuning almost always adds complexity and often is a workaround over bad application or data structure design. In the NoSQL world “SQL statement” tuning for the most part is a task of the past, but Data Structure Design has retained its importance! At the same time logic that traditionally resided in the database is now in the application layer, making application design even more important than before. So while some things have shifted, from an Application Performance Engineering Perspective I have to say: nothing really changed, it’s still about the application. Now more than ever!

What is my conclusion? No surprises. It is all about your application – logic, tuning, performance, mistakes and ability to create a reliable and efficient solution. Yes, different database techniques are requiring different technical skills. But if you have them, your ability to build PLM system on any of these platform will be almost identical. Just my thoughts…

Best, Oleg

Share
  • Ed Lopategui

    Oleg,

    My perspective on Yoann’s article is different. I believe his point was not to suggest that certain database technologies themselves are inhibiting PLM, but rather that there is no accepted standard in how PLM systems map their myriad objects and relationships into raw database tables. Migration from one vendor’s PLM software suite to another -even in a hypothetical ideal case where data models and backend databases are identical between vendors- is still difficult merely because the data was implemented differently in each database. How the tables have been instantiated are different. He argues that this presents an additional avoidable obstacle in data portability between different PLM implementations.
    Of course, Yoann is ignoring the fact that most PLM systems implement very different data models – and even implementations of the same vendor’s software at two different companies can be worlds apart. But he does touch on an important concept – in that the limitation of data portability (whether it be due to differing data models and/or physical database implementation) creates a barrier in PLM innovation – simply because it’s notoriously difficult to freely move from one system to another.

Previous post:

Next post: