November 30, 2013 at 11:27 am
Comments posted to this topic are about the item Is Your Data Relational?
December 2, 2013 at 3:02 am
It is likely to be an unpopular opinion with some of the less trained in our industry but I believe that the overhead in utilising an experienced team1 far outweighs the expense of allowing an inexperienced2 team making suitable for release then maintaining and supporting a system where the application of tools was not properly evaluated and not properly implemented.
Also decisions based on CV Engineering are generally poor ones. It is certainly an unprofessional practice.
1 The team needs to be experienced overall but can include inexperienced team members that can learn through working with knowledgable colleagues.
2 Definition of inexperienced in this context is a team with little or no prior experience applying the tools and methodologies chosen in a similar system to the one being developed.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
December 2, 2013 at 3:47 am
You can't beat a good solid RDBMS! 😀
December 2, 2013 at 4:36 am
Gary Varga (12/2/2013)
It is likely to be an unpopular opinion with some of the less trained in our industry but I believe that the overhead in utilising an experienced team1 far outweighs the expense of allowing an inexperienced2 team making suitable for release then maintaining and supporting a system where the application of tools was not properly evaluated and not properly implemented.Also decisions based on CV Engineering are generally poor ones. It is certainly an unprofessional practice.
1 The team needs to be experienced overall but can include inexperienced team members that can learn through working with knowledgable colleagues.
2 Definition of inexperienced in this context is a team with little or no prior experience applying the tools and methodologies chosen in a similar system to the one being developed.
Well before others start harping on your opinion, let me say that I think you nailed it. I hate listening to people claim that "people skills" are more important, that anyone can learn technical skills, which is just one example of the issue.
On the specific topic of Mongo DB, YouTube has a video that I thought was funny when I saw it some time ago...
http://www.youtube.com/watch?v=URJeuxI7kHo
Dave
December 2, 2013 at 5:07 am
I'm baffled when people say that there are certain things that can't be done by a relational database that are easy to do in a document database. This was true before SQL Server 2005. but since we got XML support, and now with useful indexing into XML, all this is supported in SQL Server. OK. If you don't need ACID, then you don't need a relational database, but then you need to be Billy-Two-Brains to be able to accurately judge that you really don't need ACID and all that it implies. For the rest of us, it is best to stick with relational. Storing all the fluffy stuff in XML doesn't mean that you need to be hands-on. You can treat that XML column as atomic. Unless you are intent on doing something useful with a value within the XML fluffy-stuff, you can just treat it all as an atomic value.
Best wishes,
Phil Factor
December 2, 2013 at 6:47 am
Among our local OSS data guys, not one of them recommends or uses MongoDB. It's not that it's NoSQL, it's just not a mature solution for most problems it claims to solve. I still see it used by folks that are writing tools to scrap web sites.
December 2, 2013 at 7:14 am
chrisn-585491 (12/2/2013)
Among our local OSS data guys, not one of them recommends or uses MongoDB. It's not that it's NoSQL, it's just not a mature solution for most problems it claims to solve. I still see it used by folks that are writing tools to scrap web sites.
I presume you mean scrape...otherwise there are too many jokes 😛
(Edit to correct a spelling mistake. Ironically.)
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
December 2, 2013 at 8:33 am
I think this snippet from the MongoDB article sums it up nicely:
This was ultimately a communication problem rather than a technical problem. If these conversations had happened sooner, if we had taken the time to really understand how the client saw the data and what they wanted to do with it, we probably would have done the conversion earlier, when there was less data, and it was easier.
I'll be good and spare everyone the inevitable "Cool Hand Luke" reference...
____________
Just my $0.02 from over here in the cheap seats of the peanut gallery - please adjust for inflation and/or your local currency.
December 2, 2013 at 9:43 am
djackson 22568 (12/2/2013)
Well before others start harping on your opinion, let me say that I think you nailed it. I hate listening to people claim that "people skills" are more important, that anyone can learn technical skills, which is just one example of the issue.On the specific topic of Mongo DB, YouTube has a video that I thought was funny when I saw it some time ago...
You're conflating two things. The fact that people skills are more important, which I believe, doesn't imply that you choose employees without technical skills or experience. It's just saying that if I get two experienced people, technical skills rank second in how I judge them. It's not that they don't count, but that I'll take slightly less technical experience over much better people skills. However, I can teach you some technical stuff if you don't know it. I can't teach you to learn how to work with others very easily.
If both are really close, I'd have to make some judgement call.
The problem comes in when you replace technical skills with people skills.
December 2, 2013 at 11:33 am
Steve Jones - SSC Editor (12/2/2013)
djackson 22568 (12/2/2013)
Well before others start harping on your opinion, let me say that I think you nailed it. I hate listening to people claim that "people skills" are more important, that anyone can learn technical skills, which is just one example of the issue.On the specific topic of Mongo DB, YouTube has a video that I thought was funny when I saw it some time ago...
You're conflating two things. The fact that people skills are more important, which I believe, doesn't imply that you choose employees without technical skills or experience. It's just saying that if I get two experienced people, technical skills rank second in how I judge them. It's not that they don't count, but that I'll take slightly less technical experience over much better people skills. However, I can teach you some technical stuff if you don't know it. I can't teach you to learn how to work with others very easily.
If both are really close, I'd have to make some judgement call.
The problem comes in when you replace technical skills with people skills.
I think I recognize what you are saying about conflating two things. Unfortunately I had a few things come up while I was writing this, and couldn't spend as much time editing as I would have liked. I failed to convey that I was presenting an example.
You mentioned an issue where the developers didn't model things well. To me, that shows a lack of skill, although admittedly it can sometimes be due to other issues such as unreasonable time pressure, et cetera. When I point the finger at a lack of skills, bear in mind that the skills that are missing may be technical, but they are also frequently a lack of skills when it comes to proper planning. If we assume it was a skills issue, then we may look to blame the hiring process, or the training process, or even incomplete/inaccurate requirements being provided. There are a bunch of reasons, so in an effort to keep on target, let's assume it was either a skills issue, or not providing sufficient time to do proper modeling.
Given that assumption, my "insufficently documented example" above, was meant to convey my opinion that too many companies are abandoning the technical requirements in favor of soft skills. I think that is a big mistake. I understand that people skills are important - but to me, we should only look at people skills once we have a sufficient quantity of TECHNICALLY QUALIFIED applicants. My company recently did that, and chose a person with better soft skills after confirming he had the technical skills. Both met the technical requirements, one more than the other, but the one with lesser technical skills had far, far better people skills. I hear you saying that you agree it is fine to choose the person with better soft skills, as long as the tech skills are met.
I know of too many examples, though, where soft skills were looked at as the dominant criteria, and technical skills were pretty much excluded. Those hires either end up separating much sooner than necessary, or even worse, continuing employment at a substandard level of competence. The end result is higher costs. My opinion is that people hear someone say "people skills are more important" and they take that to mean there is no case where we should hire a person who isn't a superstar when it comes to people skills.
Lastly, in my experience in a number of fields and positions, I have found that far too often someone with "people skills" is really just someone who is a good salesman, and frequently they are able to sell themselves as being able to do a job that they are truly incompent at. Judging technical skills is relatively easy if you are willing to ask hard questions. Create a test that has easy, medium and hard questions, have some multiple choice, some essay, some code writing, whatever. It can be done in a way that allows you to find a group that appears to have what you need "technically". I know of no such reliable test for people skills, and IMO people skills are the easiest to fake.
So with respect to your opinion, I don't see myself swaying from my opinion that technical skills matter far more to me. I hope your opnion/method continues to deliver the results you have seen, just as I hope my choices do as well.
Dave
December 2, 2013 at 11:36 am
lshanahan (12/2/2013)
I think this snippet from the MongoDB article sums it up nicely:This was ultimately a communication problem rather than a technical problem. If these conversations had happened sooner, if we had taken the time to really understand how the client saw the data and what they wanted to do with it, we probably would have done the conversion earlier, when there was less data, and it was easier.
I'll be good and spare everyone the inevitable "Cool Hand Luke" reference...
Due to this being the day after a long holiday, I just saw this. My last post pointed to "skills" as being either pure technical or what I referred to as poor planning skills. To me, technical projects require technical planning skills, not just day to day planning skills. Technical projects are unique.
Back to fire fighting...
Dave
December 2, 2013 at 11:51 am
I work with Mongo daily, as well as MSSQL and MySQL and it's really just a question of understanding the strengths and weaknesses of each technology. Mongo is a less mature technology, in terms of the database itself, and supporting tools, but even more so in terms of developer understanding. Developers have spent decades writing to data stores (RDBMS) that had built in guarantees of data quality and consistency that they didn't have to think about much. The headache of mapping objects to normalized tables encapsulated the challenges of keeping the data consistent.
In mongo (or other document centered db's) you have to think about these problems up front. That's the new headache. You will denormalize. You will probably have to denormalize more than you planned to support different use cases. User centric versus feed centric in the linked article. And you need to plan how you are going to keep these in sync. If you need 100% referential integrity, then mongo et al are probably not your best choice. If you can deal with somewhat dirty data and performance or shardability are more important to your application, then mongo may be a better fit.
The real gotcha that I see is that often these choices aren't being driven by a rigorous look at the pro's and cons, but instead by engineering fashion. And that's when mistakes happen.
December 3, 2013 at 3:28 am
All technologies were immature once.
If your data looks like a document then use a document store. When it looks like a relational dataset use a relational store.
You can get off the ground and running with MongoDB at low cost and when it no-longer fits the bill migrate to something more appropriate and probably costly.
I was intrigued to see PostGres HStore mentioned. It seems to address a large number of concerns that MongoDB would be used for.
December 3, 2013 at 5:00 am
I work with both MSSQL & MongoDB. Please excuse me if I am repeating what was already said above.
My frustration is the same as other DBAs supporting MongoDB. Those that do not understand MongoDB, attempt to use it like a relational database. They are surprised & upset that when I inform them that standard functionality to a relational database, is not available in MongoDB. They some how in there minds think that if the software calls its self a database, that it has a minimal set of functionality (mostly what is common in relational database).
In my experience, MongoDB has worked an excellent document database. Again, it is a document not a relational database.
Viewing 14 posts - 1 through 13 (of 13 total)
You must be logged in to reply to this topic. Login to reply