there is a big demand in the industry for html/javascript with java/C# background. Everyone wants a new html 5 website.Originally Posted by Crableg
there is a big demand in the industry for html/javascript with java/C# background. Everyone wants a new html 5 website.
Look, I've worked with Microsoft SQL Server, MySQL, Oracle and PostgreSQL in total now for 11 odd years (production experience, excluding studies) and I'm astounded at the versatility and SPEED that MongoDB offers. I'm buying into the NoSQL movement wholeheartedly as I can see the benefits it has for developers and support technicians in the long run.
Remember that MongoDB is fairly new technology, but it's being backed by industry giants currently. Many of the initials issues it had has been ironed out (like database-wide write locks, now down to collection or document-level locks) and they even started implementing features that will make traditional RDBMS fans feel more at home, like "joins" ($lookup) and references (DBRefs).
In essence the 2 technologies only have one feature or use in common: persisting data. The ways in which they operate differ wildly so it is futile comparing the 2 technologies. Heck, it's even futile comparing SQL vs NoSQL databases - this are just too different from one another. What I do agree with [MENTION=2226]InSanity[/MENTION] with is that it is situational, as is the case with any piece of technology. In environments where you need high performance (think high transaction volume web applications or transaction engines), have highly volatile data structures (workflow systems are a great example) and would benefit from implementing only one programming language in your application stack (in this case JavaScript), MongoDB is almost the default choice.
I'm a huge JavaScript fan and evangelist, but I don't think that makes my opinion biased at all. In contrast, I've been a fan of Microsoft's stack of technologies (Windows, ASP.NET, MSSQL, IIS - let's see if the term WAMI can take off) for my whole career and with recent experience in the Oracle stack (Linux / Unix, Java EE, Oracle, Glassfish) I've also become a fan thereof. With each of those stacks, you typically end up developing in 3 languages when you build a modern, rich web application: C#, T-SQL and Javascript; or Java, PL/SQL and JavaScript. The MEAN stack reduces that to a single language: JavaScript.
I'd really urge you to follow the current development trends in the industry and notice how large corporates are adopting the MEAN stack. I followed the hack.summit() 2016 this week and was surprised to see how industry giants like Microsoft, IBM, PayPal and SAP are all buying into, supporting and improving Node.js. Just browse through MongoDB's site to see how many tech companies have already adopted the platform in just the last 2 years (E-bay, LinkedIn, Adobe, EA, New York Times, etc). Now is the ideal time to jump on the JavaScript bandwagon - it's set to make big waves in the industry in the next couple of years and it will finally break the stigma that it's only useful for validating input fields on a web form.
--~<0>~-- {type}DEV --~<0>~--
Dont get me wrong i love NoSql methodology(hadoop, big Data, mongo etc) I just loved that video, the problem is it will never replace RDBMS but its not meant to like you said they are completely separate tools which have their benefits in individual situations, they actually work really well together, I found that video after i had a friend sit and argue with me that NoSql can replace RDBMS, he was basically insinuating RDBMS is dead tech which is complete bs... problem with Devs is every dev nowadays wants a silver bullet and often people latch onto the first tool that comes across their path and because its the best for their situation they immediately put it on a pedastel and everything else becoems trashLook, I've worked with Microsoft SQL Server, MySQL, Oracle and PostgreSQL in total now for 11 odd years (production experience, excluding studies) and I'm astounded at the versatility and SPEED that MongoDB offers. I'm buying into the NoSQL movement wholeheartedly as I can see the benefits it has for developers and support technicians in the long run.
Remember that MongoDB is fairly new technology, but it's being backed by industry giants currently. Many of the initials issues it had has been ironed out (like database-wide write locks, now down to collection or document-level locks) and they even started implementing features that will make traditional RDBMS fans feel more at home, like "joins" ($lookup) and references (DBRefs).
In essence the 2 technologies only have one feature or use in common: persisting data. The ways in which they operate differ wildly so it is futile comparing the 2 technologies. Heck, it's even futile comparing SQL vs NoSQL databases - this are just too different from one another. What I do agree with [MENTION=2226]InSanity[/MENTION] with is that it is situational, as is the case with any piece of technology. In environments where you need high performance (think high transaction volume web applications or transaction engines), have highly volatile data structures (workflow systems are a great example) and would benefit from implementing only one programming language in your application stack (in this case JavaScript), MongoDB is almost the default choice.
I'm a huge JavaScript fan and evangelist, but I don't think that makes my opinion biased at all. In contrast, I've been a fan of Microsoft's stack of technologies (Windows, ASP.NET, MSSQL, IIS - let's see if the term WAMI can take off) for my whole career and with recent experience in the Oracle stack (Linux / Unix, Java EE, Oracle, Glassfish) I've also become a fan thereof. With each of those stacks, you typically end up developing in 3 languages when you build a modern, rich web application: C#, T-SQL and Javascript; or Java, PL/SQL and JavaScript. The MEAN stack reduces that to a single language: JavaScript.
I'd really urge you to follow the current development trends in the industry and notice how large corporates are adopting the MEAN stack. I followed the hack.summit() 2016 this week and was surprised to see how industry giants like Microsoft, IBM, PayPal and SAP are all buying into, supporting and improving Node.js. Just browse through MongoDB's site to see how many tech companies have already adopted the platform in just the last 2 years (E-bay, LinkedIn, Adobe, EA, New York Times, etc). Now is the ideal time to jump on the JavaScript bandwagon - it's set to make big waves in the industry in the next couple of years and it will finally break the stigma that it's only useful for validating input fields on a web form.
Why is it a problem if it doesn't replace RBDMS? I'm not saying RDBMS will ever go away. If anything, I believe NoSQL will incite a bit of innovation in the RDBMS scene. Just look at XML types being applied to RDBMS environments (MSSQL and Oracle specifically) - it gives you a good balance between relational data and unstructured data stored in XML. It's just a shame that XQuery and the like are a bit too slow to warrant full transactional processing on such schemas, despite my love for XPath and FLWOR expressions.
Due to my intent on building every system I can to be as configurable as possible, unstructured data features highly on my list of priorities when choosing a storage platform. NoSQL just happens to fit the mould perfectly and MongoDB is right there at the forefront, driving the approach forward.
--~<0>~-- {type}DEV --~<0>~--
Just to clarify: Neither C#, Java nor JavaScript makes your website "HTML5". It's all about semantic tags and content and using the new features the specification provides to your advantage. HTML5 sites are often built in conjunction with CSS3 and JavaScript (and any combination of the hundreds of libraries and frameworks out there), but in essence HTML5 is just a revision of the HTML specification.
--~<0>~-- {type}DEV --~<0>~--
maybe bad choice of words its not a problem i'm a SQL Dev so for my sake they better not fully replace RDBMS systemsWhy is it a problem if it doesn't replace RBDMS? I'm not saying RDBMS will ever go away. If anything, I believe NoSQL will incite a bit of innovation in the RDBMS scene. Just look at XML types being applied to RDBMS environments (MSSQL and Oracle specifically) - it gives you a good balance between relational data and unstructured data stored in XML. It's just a shame that XQuery and the like are a bit too slow to warrant full transactional processing on such schemas, despite my love for XPath and FLWOR expressions.
Due to my intent on building every system I can to be as configurable as possible, unstructured data features highly on my list of priorities when choosing a storage platform. NoSQL just happens to fit the mould perfectly and MongoDB is right there at the forefront, driving the approach forward.as for the innovation there already is a lot in things like SQL for example we use a fire and forget SB approach which is very Similiar to a NoSql approach. But Non structured data as with structured data has its pros and cons hence why just saying one is better then the other will never work they are always situational
Very very common problem that... It's kinda the "if all you have is a hammer, everything looks like a nail" thing. My approach is always "right tool for the job"; The problem is that just because you can do something doesn't mean you should. One example I have seen is a database being created to store application settings where a simple config/ini file or even the registry would have sufficed. Other examples is poor usage of SOAP/XML messages where instead of only sending the relevant data for a record, all data for a record would be sent (1-2MB per transaction) where sending ONLY the relevant information would have resulted in a 50-100KB message being sent...the list goes on.
and my personal favourite that I just have to slot in here...sending passwords UNENCRYPTED in plain text over the internet
fully agree try getting html5 working on richface 3.3 does not work very nicely but all the backend are built on a seam framework and they just want to use the nuwe nice html. I hate when we have very short timeframes to implement stuff.
...that's why REST was proposed to get rid of the inflated, ugly bloat of SOAP. But I agree, only send and receive what is necessary, unless you're building a standard API for a system. The problem with inflated message bodies is probably that the applications were built using a SOA approach. In my year-long experience at a telco I saw services become ugly and inflated, due to deprecated objects and properties still forming part of requests. When I had the opportunity to implement REST services, I did, and it made a world of difference to the traffic on the servers. All the web apps I build all subscribe to a proper REST standard, with the appropriate content being returned based on the request method and mime type being requested: JSON-serialised objects for application/json, XML-serialised objects for text/xml and full or partial views for text/html.
--~<0>~-- {type}DEV --~<0>~--
i wish we could do rest. so much more fun
Posting Permissions
