The Conformist Developer
In a data center, in a cluster, in a server, in RDBMS instance, in a schema, in a table, in a row, in a field... comes the story of an orphan data and a select statement that will change its life forever and brings its value to the user....
Everyone loves the relational database, Oh My God! , tables, views, triggers and stored procedures.
No You Don't!!!
Many years ago, when I was in college, my smart ass colleagues kept talking about how studying and mastering relational databases is pretty much essential to the success of your career and probably how you perform in bed.
It does not end there, but they also brag about how large the tables they have to work on and how long their join statements are, believe me, if you keep listening to them, you are going to have some sort of a database envy.
Your Database is So Small, It's A Shame If You Stick It Out!!!
Relational database huggers keep working with complex tabular structures with endless foreign keys. If you dare question their sacred normalization methods, you are not going to hear the end of it.
Do You Live a Lie?
Select Statement: Mr. Field, I came here to bring you with me to a different world, you were chosen!
Mr. Field: Hmm, finally someone has come to bring me out of this dump... but why?
Select: You see, you live in a row which is in a table which is a part of large matrix of tables which are divided on each other. I was sent by the creator to summon the chosen ones.
Mr. Field: But... why has not the creator put the chosen ones together in the first place, why must he (or she) create us divided on each other and send you every time to summon us!
Select: Um...Uh... The creator is a conformist, I guess.
They Call It Impedance Mismatch!!!
If you have read a book or even a tutorial about the object - relational mapping frameworks, first thing they usually mention is always the impedance mismatch problem.
I interviewed a lot of people, most of them are fresh graduates but some of them are senior developers with more than 4 years of experience under their belt. Here I quote from a certain interview with a senior that worked on handful of mid sized projects.
Me: What do you know about domain aggregates?
Him: hmm... is it the diamond thingy in UML?
Me: um... maybe!
Him: pff, you know... this interview is getting weirder by the minute!!! I feel like being back to college... You hang on things from the past man!
So, what are you saying exactly?
If you work with aggregates, isn't going to be much easier if you persist the aggregate as one atomic entry and address it with a global identity?
One Aggregate, One Entry, One Identity and end it!!!
Yeah, I use fancy document oriented database which is not as mature as the good old relational database.
No, you can actually do much with document oriented databases. It is not for simple applications.
Yeah, it can scale to serve lot of users.
No, it not difficult to work with, in the matter of fact, it is much easier than good old relational databases.
Yeah, it supports analytical transaction processing, but not as good as the relational databases.
Anyway, Stop Being a Conformist!!!
In a data center, in a cluster, in a server, in RDBMS instance, in a schema, in a table, in a row, in a field... comes the story of an orphan data and a select statement that will change its life forever and brings its value to the user....
Everyone loves the relational database, Oh My God! , tables, views, triggers and stored procedures.
No You Don't!!!
Many years ago, when I was in college, my smart ass colleagues kept talking about how studying and mastering relational databases is pretty much essential to the success of your career and probably how you perform in bed.
It does not end there, but they also brag about how large the tables they have to work on and how long their join statements are, believe me, if you keep listening to them, you are going to have some sort of a database envy.
Your Database is So Small, It's A Shame If You Stick It Out!!!
Relational database huggers keep working with complex tabular structures with endless foreign keys. If you dare question their sacred normalization methods, you are not going to hear the end of it.
Do You Live a Lie?
Select Statement: Mr. Field, I came here to bring you with me to a different world, you were chosen!
Mr. Field: Hmm, finally someone has come to bring me out of this dump... but why?
Select: You see, you live in a row which is in a table which is a part of large matrix of tables which are divided on each other. I was sent by the creator to summon the chosen ones.
Mr. Field: But... why has not the creator put the chosen ones together in the first place, why must he (or she) create us divided on each other and send you every time to summon us!
Select: Um...Uh... The creator is a conformist, I guess.
They Call It Impedance Mismatch!!!
If you have read a book or even a tutorial about the object - relational mapping frameworks, first thing they usually mention is always the impedance mismatch problem.
I interviewed a lot of people, most of them are fresh graduates but some of them are senior developers with more than 4 years of experience under their belt. Here I quote from a certain interview with a senior that worked on handful of mid sized projects.
Me: What do you know about domain aggregates?
Him: hmm... is it the diamond thingy in UML?
Me: um... maybe!
Him: pff, you know... this interview is getting weirder by the minute!!! I feel like being back to college... You hang on things from the past man!
So, what are you saying exactly?
If you work with aggregates, isn't going to be much easier if you persist the aggregate as one atomic entry and address it with a global identity?
One Aggregate, One Entry, One Identity and end it!!!
Yeah, I use fancy document oriented database which is not as mature as the good old relational database.
No, you can actually do much with document oriented databases. It is not for simple applications.
Yeah, it can scale to serve lot of users.
No, it not difficult to work with, in the matter of fact, it is much easier than good old relational databases.
Yeah, it supports analytical transaction processing, but not as good as the relational databases.
Anyway, Stop Being a Conformist!!!
