|
Over the past several years there has been an enormous amount of press over NoSQL, which is a way to store and retrieve data found in a less structured and less consistent form than relational databases. "If you hype something and it succeeds, you're a genius, it wasn't hype; if you hype it and it fails, then it's just a hype."
|
|
|
|
|
My only relationship (harhar) to NoSQL was when I was part of a conference call for an interesting website idea and the geeks on the call were wondering what kind of database to use. Someone (not me) said "let's use NoSQL!" and everyone (again, not me) said, "Yeah, Cool, Awesome!" without any thinking behind why we would do that.
And frankly, that experience is enough to keep me away from anything and everything in NoSQL land. I can handle unstructured structured data easily with a standard relational database, thank you very much, and quite frankly, the vast majority of data is structured, it's just that people are too lazy to work out the structure. In my HUMBLE opinion.
Marc
|
|
|
|
|
Yeah, there was a stretch there where the answer to every question seemed to be NoSQL. I think it falls happily into the "fast iteration, maybe we'll get an app out of it" mindset where "we don't need to think about the schema, we'll figure it out as we go along." Fine while you're fiddling, but I can't see how it really can compete long term with a relational db.
--------------
TTFN - Kent
|
|
|
|
|
<Rant>
Broadly speaking I am in favour of the NoSQL movement, but not in the way these guys think about it.
SQL is, strictly speaking, not a relational language and, in spite of their naming, most modern DBMS are not truly relational. Codd, who invented Relational DB's, defined 12 rules (0 to 12) that are requirements for a DB to be called relational. Codd's 12 Rules[^].
Unfortunately, marketing won and we got left with the results of Oracle rushing to market and inflicting SQL on us. Many of the results still plague us today. One example of SQL's not-relational nature is the support for duplicate rows in a relation (that includes result sets as well as tables). There is no meaningful way of distinguishing between those rows. It is often argued that these are needed for aggregate functions, but again that is a deficiency of the design of aggregation in SQL.
Christopher Date et al., in 1995, proposed The Third Manifesto[^]. This uses one of Codd's ideas Domains (for example, a measurement in inches has a different domain to a quanity of parts, and it is an error to compare the two) to produce a model of DB's that totally avoids the Object/Relational Impedance problem. Sadly, there are precious few implementations of this.
There are numerous other issues, but this is probably the earliest example of Oracle ruining a promising technology. It is a shame more people aren't aware of this.
Its just a shame to me that all the NoSQL movement has done is move to models of DB that throw away most of the benefits of the Relational Model, rather than correct the deficiencies of the current implementations of it.
</Rant>
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
Rob Grainger wrote:
SQL is, strictly speaking, not a relational language
Yeah, I've commented to people when I teach them about databases that SQL is neither Structured, nor just Query, and definitely not a Language. 
Rob Grainger wrote: One example of SQL's not-relational nature is the support for duplicate rows in a relation
Isn't that something that a unique constraint could handle? I've definitely been bitten by duplicate rows when I haven't used constraints properly, and it sure is a PITA to delete all but one. At least Oracle had a Row ID, which SQL Server was lacking a similar concept many years ago. But perhaps I'm missing what you mean here.
Rob Grainger wrote: for example, a measurement in inches has a different domain to a quanity of parts, and it is an error to compare the two
Exactly! To do some of the automation I like to do, I end up coding a "metaschema" that allows me to provide, among other things, a much richer type definition for columns and tables.
Great post, BTW! Not a rant at all, IMO.
Marc
|
|
|
|
|
"Isn't that something that a unique constraint could handle?"
That's certainly true, but in the Relational Model, duplicate rows are expressly forbidden - even in queries. Row IDs are really a workaround, rather than a solution to the issue, and also violate the constraint that their should be no ordering in base relations (tables).
This hit me this week at work, where a (pre-existing) query was actually returning two rows rather than one and effectively selecting which one actually gets returned by some logic I was unaware of. This was then updated in code, leading directly to data inconsistencies. Had the original developer used UNIQUE, the result would not have been updateable and the problem could not occur.
Another key feature of domains is also worth considering. Each PK in the database is a unique domain. Joins can only be performed based on data from a common domain - this is (rightly) much more restrictive than the joins as implemented in mainstream DBMS. Again, I have seen this error occur in practice (although only once) with disastrous consequences.
Further, in V2 of the Relation Model (which has more rules and features), PK domains are database-wide: multiple tables may draw PK values from the same domain - but each PK value is still a unique identifier, that may be a PK value in more than one table. This feature could really help with object-relational mapping, so a table representing a subclass can share a PK with the table representing the base class without the need for special work to maintain consistency between the two. (It brings many other benefits too).
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
Rob Grainger wrote: Each PK in the database is a unique domain. Joins can only be performed based on data from a common domain
Oi, that's brilliant. I think I'll hijack that idea.
Marc
|
|
|
|
|
With so many tools in every developer’s chain, it's difficult to tell which ones are actually improving overall product quality and predictability. This graph shows the effects various tools have on predictability, and that version control and IDEs are still the kings of developer tools. Two quarts of French Roast, and a #18 needle
|
|
|
|
|
I find it more than a little odd that code quality is at 56% when it's not monitored, and only goes up 7 percentage points, to 63%, when "Fix all". A 7% increase for what is probably a very costly and time consuming process seems rather ineffective. Gee, could that be an indicator of the "quality" of Java, or the metrics used to determine code quality?
What I glean from this is, even when "fixed all", the code quality of Java code still sucks. Hmmm... 
Marc
|
|
|
|
|
I think the main flaw in the article occured in the pre-keyboard stage. Java is no worse than, and no better, other languages for having problems in quality. There are many ways to improve quality, none are perfect and all are applicable.
speramus in juniperus
|
|
|
|
|
Nagy Vilmos wrote: Java is no worse than, and no better, other languages for having problems in quality.
I do actually think that a language and quality are at least somewhat interconnected, and I would imagine that Java actually has a higher quality rating than some certain other languages. 
Nagy Vilmos wrote: There are many ways to improve quality, none are perfect and all are applicable.
It would be interesting to see if there is something intrinsic about a language that can degrade (or improve) quality. The "quality" of code I see in VB, for example, is atrocious, but is that the language itself? I can say the same for Ruby, but I also know that I can write high quality Ruby code, so it seems more of a discipline and skill issue.
Marc
|
|
|
|
|
More productive in compare to who?
Maybe to the Java developer of the last year?
I can't see how these numbers and graphs says anything about productivity. It talks about habits and try to show the impact of that habits on code quality...
I'm not questioning your powers of observation; I'm merely remarking upon the paradox of asking a masked man who he is (V).
|
|
|
|
|
I interpreted it as "What makes some Java developers more productive than others", but it could have been phrased better.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
Our survey of more than 3,000 developers and managers shows that after several years of being flat, salaries are on the rise once again "I got a little change in my pocket going ching-a-ling-a-ling"
|
|
|
|
|
Here is another salary review for the O+G Industry 2013, it shows how the various sectors are fluctuating and also which regions are in demand. As you would imagine there is a huge service industry sitting behind this of which IT is a part of it, so it has a direct bearing on a lot of areas.
http://hays.clikpages.co.uk/Oil_and_Gas_Salary_Guide_2013/[^]
|
|
|
|
|
Can't wait for the death of oil, long live green energy
<a href="http://www.software-kinetics.co.uk"><span style="font-family:Arial, Helvetica, sans-serif; color:#006C97;">Software Kinetics</span></a> - <span style="font-family:Arial, Helvetica, sans-serif; color:#333;">Dependable Software</span>
<a href="http://blog.software-kinetics.co.uk/"><span style="font-weight:bold;font-family:Arial, Helvetica, sans-serif; color:#333;">news</span></a>
|
|
|
|
|
As long as it sees me through to my retirement I'll be happy (maybe longer, depends what my kids end up wanting to do).
|
|
|
|
|
OT - Your signature broken.
|
|
|
|
|
Kent Sharkey wrote: salaries are on the rise once again
Yet income isn't. That's called "inflation".
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
Thank you. I think I'll go jump off a cliff now.
Comments from work:- "Why can't you just do it like everybody else?"
- "Well, we haven't had any complaints yet."
- "I just want to get it into production."
- "It only matters if it’s important to someone who matters."
|
|
|
|
|
I don't know what the cost-of-life in the US but I would like even the 2010 salary he mentions in the article...
I'm not questioning your powers of observation; I'm merely remarking upon the paradox of asking a masked man who he is (V).
|
|
|
|
|
Meh. That's even more useless to me[^] than the one from GlassDoor[^] posted last month. Since that one was broken down by city it was at least explicit that all it showed was that people in areas in areas with significantly higher costs of living were paid significantly more than I am. If I didn't know about urban/rural cost of living differences this one could've goaded me into making stupid and impossible to meet demands of my manager/HR/etc.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|
|
Microsoft is killing off its controversial stack-ranking system today. While it could be viewed as an internal change that won’t affect consumers directly, it will have a broad effect on current and future Microsoft employees that may just shape the future of the company. For years Microsoft has used a technique, stack ranking, that effectively encourages workers to compete against each other rather than a collaborative Microsoft that CEO Steve Ballmer is trying to push ahead of his retirement. "And there was much rejoicing"
|
|
|
|
|
Makes me a heck of a lot more likely to consider working for them. Having worked at another company that used forced stack ranking it was horribly demoralizing. It totally sucks if a manager has a great team of high-performers. I once had a fantastic year and accomplished great things, but at my review my manager explained to me that due to the stack ranking I had to be ranked low, since it was someone else's "turn" to be ranked high since she had had to be ranked low the year before, and I was new to to the team. He'd make it up to me next year. She deserved high ranking, no question, and I totally sympathized with my manager who despised the system. But with a small team of talented people HR forces you to screw someone.
|
|
|
|
|
Yes, this is one of the scenarios where it absolutely falls flat. It's horribly alienating for a group of high achievers, and becomes a disincentive. Also in mixed skill level groups, it becomes a battle of "who can become more visible?"
I'm so glad they got rid of it. I still have little desire to return, but this is good news for those still in there.
--------------
TTFN - Kent
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
