SQL vs NoSQL, the ultimate database match

SQL vs NoSQL, the ultimate database match

In the blue corner, SQL stands with an arched back and titanium walker. In the red corner, NoSQL maintains steady movement and a toddler’s impatience.

Created in the early 1970s, SQL was the unrivaled choice for applications both large and small that were in need of storing, managing, and retrieving data. Deciding to implement a SQL-driven database was a no-brainer for developers and system architects because it was unmatched by its alternatives not only in reliability but also in its reporting capabilities. In recent years, however, SQL, the once unrivaled query language, is being replaced slowly but surely by the new kid on the block: NoSQL.

Let’s take a moment to evaluate and discuss the differences and similarities of these database models with a few areas of focus. For the sake of this discussion, we will use MongoDB as the NoSQL example and MySQL for the SQL example, but the assertions for NoSQL are not limited or specific to Mongo but also apply to numerous other NoSQL campers like MapReduce, Bigtable, Cassandra, and others. Many of these NoSQL technologies have similar capabilities and advantages, as well as weaknesses. Similarly, on the SQL/RDBMS side, we will reference MySQL, but the same ideas carry over for other solutions like Oracle, SQL Server, and others.

The Back Story
We first need a bit of backstory. We’ll begin by asking ourselves what SQL vs. NoSQL really means. To answer this we have to understand what a database and a database system are. Now, bear with me here, without trying to bore you to death, we may agree that a database is a system for storing and managing data and a database system is a program for managing databases. Got that? So next, the data in a database has to be organized in some way. The way in which various database systems choose to organize their data is referred to as a database model, and this is where SQL and NoSQL come in. On the surface, think of SQL as the relational model and NoSQL as the non-relational model. Diving deeper, we find that the relational model uses set theory and predicate logic, in which the data looks like it is organized in tables and columns, while the NoSQL model stores data as key-value pairs without any strict relation to each other. End of backstory; you’ve uncovered the plot, so now let’s jump straight to the three-round fight scene.

Ding!

Data scientists and architects assert that SQL is not out for the count, and I agree. Relational databases have a huge advantage compared to these wannabe newcomers primarily because they have excellent tooling, community, and support. The “why change what’s working?” question comes up pretty often when developers and system architects are faced with the decision of rolling out a data management tool. SQL offers two main advantages: first, it introduces the concept of accessing many records with one single command; and second, it eliminates the need to specify how to reach a record; e.g., with or without an index. Since most NoSQL databases lack the ability for joins in queries, the database schema generally needs to be designed differently and lends itself to some inefficiencies, giving SQL round one of this match by a small margin.

Popular NoSQL databases were pioneered by top Internet companies like Amazon, Google, LinkedIn, and Facebook to overcome the drawbacks of the relational model. The relational model is not always the best solution for all situations as it cannot meet the increasing growth of unstructured data.

NoSQL is better for unstructured data

You may have paused to ask yourself why some organizations have unstructured data. Well, social media posts and multimedia are only two examples of unstructured data, which should answer that question, but more importantly, since the world’s data is doubling every two years, companies now have a much greater need to not only store and accommodate unstructured data, but also to aggregate and use this data meaningfully. This is where the relational model takes a hit to the face giving round two to NoSQL.

Round three has three main focus; performance, planning, and price. Ideally, this is where the rubber meets the road in this decision. With NoSQL, instead of retrieving all the data

with one query, it is common to do several queries to get the desired data, but NoSQL queries are often faster than relational SQL queries so the cost of having to do additional queries may be acceptable. So if an excessive number of queries would be necessary and the company’s culture values performance, SQL or NoSQL may take the performance point for this round.

Planning is the second judge and it is very important, yet subjective. SQL databases have predefined schemas while NoSQL databases use a dynamic schema due to the nature of unstructured data. Therefore, SQL databases can be scaled vertically whereas NoSQL databases can be scaled horizontally. This means that to scale an SQL database, we simply increase the processing power of the hardware, while to scale a NoSQL database, we increase database servers in the pool of resources to reduce the load. Based on the organization’s planning culture, either SQL or NoSQL can take the planning point and this leave price as the final factor.

All companies make an effort to keep cost low so price an important factor. Most, if not all NoSQL databases are open source or very very low cost, which makes them very appealing. For the example, MongoDB, Couchbase, CloudDB, and Amazon’s Dynamo DB all allow very affordable implementations. On the other hand, among the major players in the SQL space, only MySQL (and its fork MariaDB) offers an open source solution. Both Oracle and SQL Server can be very expensive solutions due to the support they offer, which is usually readily available from their vendors or a fair number of independent consultants. NoSQL databases rely mainly on community support.

The Judge’s Decision
Depending on your vantage point or who you ask, some may agree that this match could have ended in a technical draw a few paragraphs prior, where unstructured data was a definite need and nothing else mattered. Another vantage point may have revealed that this match has ended in a TKO if no budget was allocated to database implementations and management couldn’t care less about database models, giving priority to an open-source-only solution. Ultimately, you decide who wins round three and therefore the match.

Despite your vantage point or decision, we all can agree that SQL and NoSQL serve very different purposes, with their own unique strengths and weaknesses; without them, developers and system architects would have been pulling their hair out trying to figure out how to utilize data locked away in filing cabinets to generate predictive analysis and graphs.

Ding!

 

Editor’s Note: 

Learn more about what our developers choose as their everyday tools and what our thoughts on these are:

Comparing React Native to Axway Titanium 

Kotlin: Three Reasons to Start Using it Today 

Node.js – Storing data with MongoDB

From Creative to Tech: 5 Lessons for Mobile Development Project Management

From Creative to Tech: 5 Lessons for Mobile Development Project Management

shockoe-project-manager-Rebecca-mobile-development-project-managementMy journey into Mobile Development Project Management was almost accidental. I started my career in television production, first as a producer on a reality TV show and then jumping into production at a large advertising agency, helping to create television, radio, and video projects for national brands. But after six years of production, I started gravitating more towards the internal management of teams rather than organizing shoots and productions. I decided to give project management a try, and from the minute I felt the warmth in my heart of seeing my client’s multi-media campaign scheduled out across all deliverables, I knew I was home.

When I made the jump to a tech firm six months ago, I discovered several stigmas placed on project managers at creative agencies:

  • They don’t know agile, having worked in a decades-old process that is viewed as slow, clunky, and requiring several layers of approval.
  • They’re only used to working on large, expensive projects, and are unable to follow a tight budget.
  • They’re “snobs” if the work can’t win a snazzy industry award that looks good on a shelf, they’re not interested.
  • They don’t know digital or tech, and they can only work on traditional media (TV, radio, print).

But while there’s some truth and mostly fiction in all of these stigmas, I believe that my experience at that large, clunky agency has given me important lessons and ideas that I incorporate into my mobile development project management on a daily basis. And as more advertising agencies move into 2018 and beyond, agile is becoming more than just a buzzword; consultancies must incorporate more SDLC (Software Development Life Cycle) mobile project management techniques in order to stay competitive and meet their clients’ needs.

With that, here are five lessons I learned that can be helpful to project managers and team leaders in advertising/marketing and tech:

1. Process should help the work get out faster, and evolve and improve it over time
Agile has become something of a buzzword in advertising, and for good reason. Clients are getting frustrated with the time and cost it takes to get work done. But consultancy creatives have several fears about the agile process: that you can’t quantify the time it takes to get the “big idea,” that clients won’t be able to see work in progress throughout and envision the final product, that daily stand-ups would become too much of a time-suck, and that traditional teams should be structured as a copywriter and art director. A large hurdle for an advertising consultancy to get over is to view the work as an evolving piece, and not a finished product. Sometimes that means releasing something to the client or the public if it’s not finessed to the nth degree, or if it has minor bugs. If you’re constantly updating, engaging, and storytelling, then the focus is more on the brand’s journey over time, and less on one 30-second TV spot. Consultancy teams would also benefit from the structure and accountability that a daily stand-up can provide. Responsibilities are made clear, each employee is accountable for the progress and completion of their own work, and the small team is united in their singular mission of getting the work done. And while Project Managers in both industries keep a full list of functionality or deliverables, tech PMs have more of a voice around Sprint Planning, and work with their clients and team members to determine priorities around features, and keep a fluid backlog of “nice to haves” depending on time and budget.

2. Design should improve the experience, not just impress other industry folks
Software Development Life Cycle Mobile project managementAwards are a necessary evil for any consultancy. They’re motivating for employees and serve as PR and sales tools, attracting new clients and making them aware of the consultancy’s work. But one criticism of a creative consultancy is that work is often done for the sole purpose of winning an award, and not serving the consumer. Yet tech companies may often lean in the opposite direction, where design is sacrificed at the expense of functionality and performance. There is a lesson to be learned from both. There is always a place for impeccable design, but its end goal should be to improve the user experience and solidify the consumer’s impression of the brand. As a project manager, that means involving UX/UI designers and developers throughout the lifespan of a project. My most successful projects have started in a room where a designer and developer are both throwing ideas up on the board, and continue collaborating on functionality, navigation, and UX throughout the process, even in QA. But that’s not meant to undercut the importance of a developer because all the smoke and mirrors in the world can’t hide something that doesn’t actually work. This is why in the agile process, we’re not presenting a PDF to the client, we’re presenting a functioning piece of technology. The code isn’t just the “back end” it’s as much of a client-facing deliverable as a design presentation and needs to be as clean, thorough, and documented as the slickest consultancy deck.

3. Strategic Planning can set a foundation for development too
The best advertising campaign is built upon a solid strategic foundation, and a mobile app or tech project should be no different.Functionality shouldn’t be added just because it’s a hot trend– it should make sense for the overall brand and their consumer, and deliver on a business problem the same way a piece of advertising would. One takeaway that a tech company can glean from a creative consultancy is the importance of a creative brief that’s rooted in the overall brand strategy. If the design is always driven by strategy in addition to the normal technical requirements, your projects will never feel like just a string of new functionality with no big picture in sight– which is frustrating for UX/UI designers and developers alike. While sometimes our clients in IT aren’t privy to the marketing plans and decisions of their brands, it’s our jobs to help them create a strategic plan and roadmap that bridges that relationship and creates consistency across all platforms.

4. Saying “Yes” doesn’t mean “Yes, right this minute”
Mobile Development AgencyIn a company meeting recently, our COO Alex was answering questions about timesheets, and stated, “Your nights and weekends should be your own.” I was immediately shocked and felt like applauding (ok maybe I did a little bit). That a statement like that would be shocking speaks to the culture of creative consultancies– you’re expected to be “on call” at all times, and you almost wear your late night and weekend work like a badge of honor. But why? I admit I’m still a bit stumped on this one. Could it be that creatives maintain that conception is not a science, and they can’t predict when lightning will strike? Or that good ideas don’t come until 3 a.m.? Or that marketing clients operate on faster timelines, with emergencies and last-minute media placements popping up quickly? Either way, I have seen some differences after working at a small tech company. UX/UI designers, developers, and project managers all employ “heads-down” tactics that help them to make better use of their time during the day. Also, daily stand-ups and using tools like JIRA and Slack help teams keep tasks prioritized and get work done quickly.

5. But saying “Yes” isn’t a dirty word either
Mobile Development Project Management Creative and Tech One frustration I hear about project managers in IT and tech is that whenever a new idea is raised, the first answer is “No, it’s not in scope.” But if there’s one thing I’ve learned from being an consultancy producer and project manager, it’s flexibility. Saying “yes” is now innate for me, but how do I make sure that we’re protected as a company and not giving away work for free? It’s still a tricky line to walk, but by ensuring my estimates have room for any bugs or issues that naturally occur in development, I can give us and our clients enough space to get it right, not just done. At that point, a new ask from my client begins a conversation: Is this the right piece of functionality for this release, and will the timing work? Will it make this release that much better, that it is worth the extra hustle? With those questions answered, now we can address the budget: How are we doing overall on our hours? Do we have room to add in extra work, or would this addition cause us to go over? By treating a new ask from a client as a conversation and opportunity instead of a disruption, we can reach the goal that’s shared by creative and tech project managers alike: to create work that we all can be proud of.

 

Note from Editor: 

Our team is all about sharing our “lessons learned” and techniques, here are a couple of other blogs that we think you may find interesting:

Ensure Success with the Right Mobile App Delivery

4 Tips in Designing a Retail Inventory Management App

5 Ways Shockoe Supercharged Mobile Workflow

3 Tips to Start Using Motion in Design

3 Key Takeaways from Today’s Axway Appcelerator Announcement for Developers

3 Key Takeaways from Today’s Axway Appcelerator Announcement for Developers

The mobile dev world is buzzing with the Axway news that was revealed earlier today. To summarize the announcement:

  • The Axway Appcelerator Indie development tier is now free.
  • Hyperloop is now included with the Indie plan and is now free for all developers.
  • Appcelerator Arrow Builder is now called Axway API Builder and is also included in the (now free) Indie plan.

Hyperloop is Axway’s next-generation compiler that gives Titanium mobile developers full access to the native iOS, Android, and Windows APIs, all from within JavaScript.

Axway API Builder is a tool for creating, managing and orchestrating APIs. It allows developers to expose and control the flow of data from multiple sources using many built-in data connectors. API Builder is also extensible and allows devs to use Node.JS to create their own connectors, flows, endpoints, etc.

Quite simply this means that every mobile developer is only a few JavaScript lines of code away from any native API. Axway is opening the door for mobile developers to have free access to the Axway Appcelerator platform tools including Titanium, Hyperloop, API Builder and more!
Demand for training and developers with experience with both Hyperloop and Axway API Builder will undoubtedly increase as a result of these recent changes. Axway has strategically partnered with Shockoe to develop new training courses for both Hyperloop and Axway API Builder. Shockoe’s development experience with both of these products also enables us to continue giving our clients feature-rich experience, from apps to APIs.

Want to stay connected on all things mobile?

Sign up for the Shockoe newsletter and we'll keep you updated with the latest blogs, podcasts, and events focused on emerging mobile trends.

Points for Style

Points for Style

It’s been years, but I can still remember my lab partner’s frustrated exclamation clearly. “It’s not a rule. It doesn’t matter!”, let out in response to seeing the results of our automatically graded submission of a program in a mid-level Computer Science course. Our work was functionally perfect, but the grading tool had subtracted several points over incorrect indentation size and other various style errors. He was right, technically, as we had adhered to the implementation requirements and using our program would produce indistinguishable results from our classmates’, but the faculty had chosen to take a stand. They chose to force us to care about style, or at least notice it. They chose to enforce a few basic style guidelines at a time when it seemed irrelevant, a time when we did the vast majority of our programming as a single developer in a vacuum. I’m not going to say I saw the light immediately, and I don’t remember a single student arguing in the system’s favor early on. I did, however, adopt good habits that I would later come to be thankful for when I learned what is a shocking truth for many young devs:

Style is not extra credit. Style matters.

Now the vacuum is gone and there is no auto-grader, just a group of incredibly smart fellow developers whose time is valuable and sanity should be protected. I’ve been a strong advocate of vigilant style practices for quite a while, but Shockoe turned out to be a place where justification for that is omnipresent. Due to the nature of our business, every developer makes contributions to a wide array of codebases, and has a hand in reviewing even more. We’ll wrap up a project and deliver it to the client, who then shows it off to the rest of the company and stakeholders. Soon we get feedback… management loved it! And guess what, they want a bigger, better phase 2! This is fantastic news, but it’s time to start planning, and “bigger and better” usually means additional resources. That means bringing new developers onto the project. Getting up to speed on a project quickly is a crucial skill for us, and we want to make that transition as smooth as possible. A little extra time considering style and writing cleaner code up front could make the difference between the next developer brought on grasping it instantly or spending an entire afternoon pulling their hair out.

Every new developer at Shockoe, usually on their very first day, is invited to a repository where an internal fork of the Idiomatic.js style guide lives and asked to study it. We have eyes on each others code constantly. Every user story is a pull request that gets reviewed, critiqued, and signed off on by a coworker.

I’ve known a lot of developers to be hesitant to request stylistic changes to another’s code, and I shared those feelings once too. It can feel like you are pointing out insubstantial issues, or that style is a personal choice and you might offend them. What we need to remember is that we are all trying to improve. If another developer reviews my work and thinks “I would write this differently” then I want to hear how. Several times, seemingly minor comments or questions have sparked a discussion that roped in multiple colleagues and left us all writing better code.

So don’t be satisfied with code that gets the job done. Strive for code that actively helps the next dev down the line, that they will thank you for, because when that time comes, you could be on another project, thanking someone else in kind.

Want to stay connected on all things mobile?

Sign up for the Shockoe newsletter and we'll keep you updated with the latest blogs, podcasts, and events focused on emerging mobile trends.

Titanium to Native Android: These aren’t the frameworks you’re looking for

Titanium to Native Android: These aren’t the frameworks you’re looking for

A little about the developer

Having been working with the Titanium mobile application framework for the better part of the last year, I have developed an appreciation for what it does and what it tries to do. Creating a true cross-platform framework that tries to do almost everything that each native framework can do and unifying those into a singular codebase is definitely a challenge, one that Appcelerator has done well. After working on several projects with the framework, I feel that my programming skills and my understanding of the mobile world have drastically improved.

That being said, I wanted to start working more in the native world to get a better understanding of what Titanium was doing behind the scenes. This led me to start exploring the native frameworks for iOS and Android. I have focused on Android as I have a decent Java background. I’ve always believed that the best way to learn something new is to just dive in and figure stuff out as you go. Thus, I decided to recreate the very first application that I worked on after starting at Shockoe. The new application was dubbed Doorman as that was ultimately it’s basic purpose. It’s meant to act as a virtual doorman for people walking into the office. After getting the API setup, I jumped into writing the code and learning more about Android.

My Impressions of Android

My initial impressions of native Android development were very good. While it did have a learning curve, once I started to get a better understanding of activities, intents, services, etc it was a breeze to work with. It did miss some of the libraries that Alloy had access to like Moment, Underscore, and Backbone but I learned to work around them. Probably the most noticeable difference in the Android world coming from Titanium was the sheer amount of developer support found on the web and documentation. In addition to the amount of documentation put out by Google, the number of Stack Overflow posts with developers having similar problems really helped me with detailed explanations and examples from responses. It was indeed a breath of fresh air for a new developer just starting to get their feet wet. Even working with third party libraries was simple as they were optimized to work within the Android environment and I could use them directly rather than having to create a separate module to link the two together. Appcelerator did have a lot of detailed documentation that I heavily relied on, especially when working on the already existing codebases that used components and proxies with which I wasn’t very familiar. However, there were times when I ran into an issue that I couldn’t resolve with the documentation. The fewer number of developers post on internet made it more difficult to find a resolution if my fellow Shockoe developers couldn’t help me.

Setting up Jenkins

Once I was comfortable enough with the state of the application and API that I felt a test build was necessary I moved over to work with Jenkins, our build environment. Initially, I was a bit nervous about getting the build setup. I hadn’t yet built the application through the command line but instead was using Android Studio. As it turned out, it was a very simple process to get the builds created and uploaded after some research into Gradle, a fantastic build tool for Android applications. With just two shell commands I was able to build the application and get the .apk file to send to AppTracker, our in-house distribution service. I was amazed how easy it was to get setup. However, it didn’t take long for me to realize that the app was showing errors when trying to install on a device. Turns out that I wasn’t signing my apps before uploading them. Oops. Again, with the help of the large number of Android developers on Stack Overflow, I was able to determine that I needed to adjust my Gradle scripts a bit. I just needed to link a .keystore file to the Gradle build command then bam, signed .apk files to upload to AppTracker. The app was then ready to install on device.

Overview

Overall, I really enjoyed the experience working in the native world. I learned a lot about the what is going on behind the scenes when developing Titanium apps. I believe that this understanding will help me to become a better developer going into the future. While I know that Titanium won’t be going away anytime soon as it is a great tool for creating quality applications and a relatively small time frame from not having to create and maintain two separate codebases, I would love to continue learning more about the native world.