|
Kornfeld Eliyahu Peter wrote: The post related to the current weekly poll...
I see.
|
|
|
|
|
jschell wrote: So, for example, that is why many people jumped on the NoSQL bandwagon because they do not know how to use a relational database correctly.
So, while I largely agree with your point about how individual performance with tech may vary, I think you're falling victim to the same hypothesis in regards to NoSQL. The fact is that if you don't understand relations, and by extension a relational database, you cannot succeed with a document store.
"There are three kinds of lies: lies, damned lies and statistics."
- Benjamin Disraeli
|
|
|
|
|
Nathan Minier wrote: The fact is that if you don't understand relations, and by extension a relational database, you cannot succeed with a document store.
I doubt that in general.
First many smaller (data) apps can get by just fine with a less than optimal relational database. And the same applies to a NoSQL database.
However when one runs into an unusual problem with the relational database, then one is likely to attempt to solve it in the database, and without the skill, that is problematic. NoSQL, for most, means the solution must be external to the database so it seems 'better' to those without the SQL skill.
Note as well that at least anecdotally I have the experience to back this up as I know individuals who do not like relationals because of the skill level required (they specifically say that) so they choose NoSQL.
Other than that I can also hypothesize that object models map directly to NoSQL whereas one must consider more carefully how to do such a mapping with relationals. With skill the relational mapping is easy but without out it, a failure to map can lead to problems that would not necessarily show up with NoSQL.
And because those without the skill might have encountered the various problems, due to lack of skill, and problems that cannot exist with NoSQL they think it is better. Doesn't mean that the incorrect implementation that lead to the problem in the first place was not needed to solve some other problem, but they neglect to properly take into account the need to solve the original problem.
|
|
|
|
|
I'm sorry, that's simply not factual. Entity relationships are still a very real concern in an object store because they can lead to serious concurrency issues if not handled properly. Data structure design is just as important, and not even handled all that differently. It just doesn't have a safety net that SQL does; it will not immediately fail when a relationship mapping is not performed correctly.
As the most basic example would include an object property that references a specific entity. Unless you map that relationship properly you will end up with a copy of that entity stored in the data model, in the state that it was in when serialized, rather than a reference to an entity in another collection, which is what you want as that will be the master source for state on that entity.
Yes, it will appear to work, but you have a giant bug that might not be detectable until the system encounters a concurrency error between the real state of the object and the state tracked by the copy attached to the entity that you're working with. If you don't understand the data relations, you will never find the bug in this system.
That's what I meant in the section of text you quoted. Appearance of functionality is not success; actual functionality is success.
"There are three kinds of lies: lies, damned lies and statistics."
- Benjamin Disraeli
|
|
|
|
|
Nathan Minier wrote: Entity relationships are still a very real concern in an object store because they can lead to serious concurrency issues if not handled properly.
Yes. They can. But not that they will. Which is what I was trying to convey.
Smaller domains are less likely to experience those sorts of problems. And that is relevant when the implementer doesn't have enough skills to understand why it is important from the beginning. But in the same way, for some domains, it might never be important.
Nathan Minier wrote: Appearance of functionality is not success; actual functionality is success.
Again I can only repeat that I know people that are choosing NoSQL because they had problems with SQL. Not because the business solution required NoSQL. And from what I have been able to see of the business, in general, SQL would have been a better choice.
|
|
|
|
|
jschell wrote: Tiobe index only places C# at 5% and Java is only 12%. However given the spike in the numbers this year I expect that there is a data collection problem (which happened years ago also.)
TIOBE Index | TIOBE - The Software Quality Company[^]
I find it amusing that Visual Basic is #14. For a language that so many dismiss, it's been dead for 15 years and yet it's still in the top 20.
In 1981 I had a professor tell the class that COBOL was a dead language and no one should waste time learning it. I have a friend who has come out of retirement 3 times for COBOL projects. 
|
|
|
|
|
I saw a new job posting in the last couple of weeks where they were looking for a RPG programmer. No other language skills were listed.
|
|
|
|
|
I've seen ads for Clipper. Lot of old code out there which is low enough in priority to not get replaced.
I know someone who has software in production that runs on a 286. It doesn't run on newer technology (not that anyone thinks of a 386 as "new") so they have kept the same 286 in production since 1992. still works fine ... although when the hardware dies (when, not an if) things should get interesting.
|
|
|
|
|
IMHO:
- It's expensive, not all companies can afford Microsoft (small companies would rather go for open source platforms)
- It's dependent on Microsoft support team for any deep internal bugs (can result in bad planning at the very least, doesn't always work for big companies with super strict deadlines)
- It's somehow limited, meaning that you cannot always do the thing you want to do because it's been decided for you (our domain is about learning, adapting, innovating, and frameworks that do not allow this are generally frown upon)
- Mobile is out
|
|
|
|
|
You definitely never read a word about .NET Core...
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
Comedy gold!
"There are three kinds of lies: lies, damned lies and statistics."
- Benjamin Disraeli
|
|
|
|
|
.NET Core 'is' the OS version of .NET. Welcome to 2017.
|
|
|
|
|
I'll let myself out...
Delete post
Delete account
Delete browser
Delete keyboard
Remove the plug
... Wake up in a futuristic world
No but seriously, I never read a word, sorry about that, I was thinking about .NET framework in general. I'll have a read at the core.
Now is it comedy gold? well to each his own.
|
|
|
|
|
3. I'm in the middle of a project and there is no benefit to switching technologies in mid-stream, only unnecessary problems.
4. Core is too new, it's in flux, and it's (IMO) not yet proven.
I like bleeding edge technology. It's fun to play with and it gets me in on the ground floor ... assuming the technology makes it (some do, some don't). *I* accept that a technology may change rapidly and in unforeseen directions, which may cause rework when a new version comes out.
However, my job as a developer is not to play with the cool Tinker Toys, it's to provide stable solutions for business problems. As a young, inexperienced developer I didn't really understand this. As a mature developer, I realize that my employer needs are first priority.
Core was released a year ago, a new major upgrade has just been released. A year from now when my current project has been in production a while and we've shaken out the defects that testing didn't catch ... I'll give Core a serious look. If it's the right tool for the job I will recommend it for future projects.
|
|
|
|
|
I started to build a new version of our sample web API in .NET Core, but stopped when I discovered that Entity Framework Core does not yet support stored procedures or views in any manner. I couldn't even force feed it by hand.
|
|
|
|
|
I've taken to storing chocolate bars in my shirt cuff. That way, I always have a few Twix up my sleeve.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Bit of a cookie-cutter joke...
|
|
|
|
|
that'll only get you into a sticky situation
Format Success.
Welcome to your new signa&*(gD@@@ ![Beer | [beer]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/beer.gif) @@@@@@*@x@@
|
|
|
|
|
|
Agreed, it's worth at least 100 Grand.
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
|
|
|
|
|
|
building the retirement nestle egg
Format Success.
Welcome to your new signa&*(gD@@@ @@@@@@*@x@@
|
|
|
|
|
I just Snickers at that one.
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
|
|
|
|
|
wondering now, where does the cad bury his gold?
Format Success.
Welcome to your new signa&*(gD@@@ @@@@@@*@x@@
|
|
|
|
|
In the Mounds of course.
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
