Sign up to save your podcasts
Or
Share Ep. 56 Modern Databases, Feds, Flexibility
Share to email
Share to Facebook
Share to X
Share to email
Share to Facebook
Share to X
Or
Ep. 56 Modern Databases, Feds, Flexibility
In the early days of the Internet, companies would design databases that could handle what they perceived as tremendous amounts of information. Memory was expensive, so those databases were optimized to handle related pieces of information, or relational databases. They relied on a system that used structured data language to pull up information.
It got to the point where two or three companies dominated all large systems. They became so ubiquitous that companies like Microsoft would acknowledge the dominance of Oracle by using it for Microsoft customer names.
The past fifteen years have seen memory get cheap, and virtualization has made storage a minor concern. Combining this with mountains of unstructured data being generated with sensors, phones, and occupational technology, new databases had to evolve.
One way to break through the constraint of a relational database is with a way to approach that that goes beyond Structured Query Language, or “Not only Structured Query Language.” MongoDB is an example of a database classified as NoSQL. Some have classified this as an object-oriented database.
When comparing them, some will argue that a SQL database is better when one has many writes; and a No SQL is faster when it comes to reads. Like anything, it is best to carefully evaluate your needs and select a system that fits your set of requirements.
MongoDB is an example of this No SQL approach. During the interview, Brent Leech provides an overview of why MongoDB has the performance characteristics that will serve as the answer to many federal data management goals.
The federal government is presented with many data handling challenges – they have vast repositories of structured data as well as daily accumulating unstructured amounts of information. The more you know about databases the better you will be at evaluating appropriate systems.
Follow John Gilroy on Twitter @RayGilray
Follow John Gilroy on LinkedIn https://www.linkedin.com/in/john-gilroy/
Listen to past episodes of Federal Tech Podcast www.federaltechpodcast.com
View all episodes
By John Gilroy
5
55 ratings
In the early days of the Internet, companies would design databases that could handle what they perceived as tremendous amounts of information. Memory was expensive, so those databases were optimized to handle related pieces of information, or relational databases. They relied on a system that used structured data language to pull up information.
It got to the point where two or three companies dominated all large systems. They became so ubiquitous that companies like Microsoft would acknowledge the dominance of Oracle by using it for Microsoft customer names.
The past fifteen years have seen memory get cheap, and virtualization has made storage a minor concern. Combining this with mountains of unstructured data being generated with sensors, phones, and occupational technology, new databases had to evolve.
One way to break through the constraint of a relational database is with a way to approach that that goes beyond Structured Query Language, or “Not only Structured Query Language.” MongoDB is an example of a database classified as NoSQL. Some have classified this as an object-oriented database.
When comparing them, some will argue that a SQL database is better when one has many writes; and a No SQL is faster when it comes to reads. Like anything, it is best to carefully evaluate your needs and select a system that fits your set of requirements.
MongoDB is an example of this No SQL approach. During the interview, Brent Leech provides an overview of why MongoDB has the performance characteristics that will serve as the answer to many federal data management goals.
The federal government is presented with many data handling challenges – they have vast repositories of structured data as well as daily accumulating unstructured amounts of information. The more you know about databases the better you will be at evaluating appropriate systems.
Follow John Gilroy on Twitter @RayGilray
Follow John Gilroy on LinkedIn https://www.linkedin.com/in/john-gilroy/
Listen to past episodes of Federal Tech Podcast www.federaltechpodcast.com
More shows like Federal Tech Podcast: for innovators, entrepreneurs, and CEOs who want to increase reach and improve brand awareness
View all
Coaching for Leaders
1,462 Listeners
Sourcing Industry Landscape
7 Listeners
Adventures In Legal Tech
6 Listeners