Jos works as Architect for JPoint. In the last couple of years Jos has worked on large projects in the public and private sector. Ranging from very technology focusses integration projects to SOA/BPM projects using WS-* and REST based architectures. Jos has given many presentations on conferences such as Javaone, NL-JUG, Devoxx etc., and has written two books for Manning: Open Source ESBs in Action and (published in the next couple of months) SOA Governance in Action. In this last book Jos shows how, with some good practical governance approaches, you can create great WS-* and REST based services and APIs. Besides this he has his own blog where he writes about interesting technologies and shares his ideas about REST, API Design, Scala, Play and more. Jos is a DZone MVB and is not an employee of DZone and has posted 51 posts at DZone. You can read more from them at their website. View Full User Profile

Stop Labeling Everything as an Impedance Mismatch!

05.30.2012
| 3196 views |
  • submit to reddit

I recently ran across an article that was talking (again) about the Object-Relational mismatch. And just like in many articles this mismatch is called the Object-Relational Impedance mismatch. This "impedance mismatch" label isn't just added when talking about object and relational databases, but pretty much in any situation where we have two concepts that don't match nicely:

  • the XML/OO impedance mismatch
  • noSQL/OO impedance mismatch
  • document/OO impedance mismatch
  • JSON Strongly typed language impedance mismatch
  • Developer/Non developer impedance mismatch
  • etc.

But what really is impedance mismatch? Impedance matching is something that comes from the world of electronics (or RF or audio):

"A technique of electric circuit design in which one component provides power to another, and the output circuit of the first component has the same impedance as the input circuit of the second component. Maximum power transfer is achieved when the impedances in both circuits are exactly the same. Impedance matching is important wherever power needs to be transmitted efficiently, as in the design of power lines, transformers, and signal-processing devices such as audio and computer circuits."

It comes down to the fact that power sources have their own internal resistance. Since we can't reduce the internal resistance to zero (unless you want to start playing with super conductors at -273 degree celcius). Because of this internal resistance some amount of power is wasted in the power source, instead of it all being transferred to the connected circuit (the load). If you look at the internal resistance and the resistance of the load in relation to the power that is lost in the generator we see the following:

Impedance mismatch

In this figure you can see that we get the maximum amount of power transferred when the load resistance matches the resistance of the power source. More generalized this means matching the source impedance with the load impedance. We use the term impedance here. Impedance really isn't anything more than a more general term for resistance that also includes reactance. Impedance can be used for both AC and DC current, resistance doesn´t cover everything with regards to AC (but that's a different discussion).

But is this all good? If you look at the graph, we still loose half the power in the generator. Even if we get maximum transfer of power we're not really efficient. In practice what you see is that in power station the load resistance is set higher than that of the source to waste as little power as possible. The same goes when we're connecting speakers to an HIFI amp. In that scenario we usually have a very low resistance at the source and a higher resistance at the speaker (8 ohm). This will result in minimal power loss and still cause most of the power being transferred to the speaker.

There are however cases where impedance matching is a good idea. I won't go into the technical details but when you're dealing with high frequency signals, is that if you don't match up the impedance between source and load not all the energy is transferred to the load, but is reflected back along the cable to the source. Which can cause all kinds of problems.

So is it a badly chosen name, since in many cases having an impedance mismatch is actually a good thing?

Yes it is a very badly chosen name!

At least I think it is. In the way we use it impedance mismatch sounds like a bad thing. In electrical engineering it is just a property of an electronic circuit. In some circuits you might need to have impedance matching, in others you don't.

Saying we have an object relation impedance mismatch doesn't mean anything. Yes we have a problem between the OO world and the relation world, no discussion about that. Same goes for the other examples I gave in the beginning of this article. But labelling it with the "impedance mismatch" doesn't tell us anything about the kind of problem we have. We have a "concept mismatch", a "model mismatch", or a "technology mismatch".

I propose we start promoting the term "developer-manager impedance mismatch", where developers with minimal resistance from management can be the most efficient and get the most done!

Published at DZone with permission of Jos Dirksen, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags:

Comments

Greg Brown replied on Thu, 2012/05/31 - 8:33am

I have heard this complaint a lot as well, and I agree that the expression is somewhat misapplied.

However, I personally don't see a mismatch between XML, SQL, or JSON and OO. XML elements, SQL rows, and JSON objects are all analgous to object instances, and XML attributes, SQL columns, and JSON key/value pairs are analogous to properties. I have always found it pretty easy to map from one to the other. I can't speak to noSQL since I haven't used it, but my guess is that there's probably a pretty clear mapping there as well.

Greg

 

Mark Unknown replied on Thu, 2012/05/31 - 6:07pm

I don't think it is a bad name. My understanding of it and your explaination seem to agree with my take on it.

Is it a perfect definition? No

 

Greg - SQL != Relational 

 

Greg Brown replied on Fri, 2012/06/01 - 8:32am in response to: Mark Unknown

> Greg - SQL != Relational 

Maybe not strictly speaking, but in most cases when someone says "SQL", "relational" is generally implied. From Wikipedia (http://en.wikipedia.org/wiki/Sql ):

"SQL...is a special-purpose programming language designed for managing data in relational database management systems (RDBMS)." 

 

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.