Relational

Should we be learning NoSQL? {3}

by Shigom H
Last week, Hitachi visited Cal Poly Pomona and asked during the MISSA meeting if anyone could define a “cloud”.  A ” cloud” which relates to NoSQL, may benefit businesses because it offers an efficient and costly route to storing data on virtual servers.   NoSQL is a non-relational database approach to storing large amounts of data. An example of  database management systems that utilize this approach are MongoDB, Cassandra, HyperTable, CouchDB and Hadoop. In “10 things you should know about NoSQL databases” Guy Harrison does a quick analysis of  the advantages and disadvantages associated with a NoSQL database. read more...

Benefits of Database Sharding {3}

by Jim J
Relational databases maintain and keep data reliable. Updating the database by adding, removing, or changing data is easy with relationships and data integrity offered by relational databases. NoSQL on the other hand is another way of managing data without the complications in setting up a relational database, the cons being difficulty to maintain. An important benefits is better scalability and performance than relational databases with large amounts of data. Database sharding offers a middle grand between the two; it allows for performance and scalability benefits of NoSQL, but maintains data integrity akin with relational databases. With database sharding, the computing power of the relational database is broken up into many severs each with their own CPU, memory, and disk thus resulting in better performance than traditional relational databases. read more...

NoSQL and Document-Oriented Databases {Comments Off on NoSQL and Document-Oriented Databases}

by Toan T
Any database that does no support the SQL language is known as an NoSQL database. NoSQL was inspired and created based off Lotus notes, a program that was co-created by Lotus founder Mitch Kapor and Microsoft chief architect Ray Ozzie as a personal productivity tool. Lotus notes was never thought to be a database application; it was more thought of as an alternative to Microsoft Outlook. However, Lotus Notes included a back-end database that was optimized for sorting and working with complex documents. The program ended up inspiring the approach taken by two of today’s best-known NoSQL systems: CouchDB and MongoDB. What makes NoSQL so different is that the database systems store information not as normalized relational tables, but as documents in rich self-describing structure. It uses a  variant of JavaScript Object Notation which is similar to XML to store the documents. This approach offer more compact storage and lower processing overhead. Document databases primarily appeal to developers for the very reason that relational databases don’t. The RDBMS entity-relational data model is usually inherently different from the object-oriented model of the modern programming languages. It impacted programmer productivity by the need of translating objects back and forth from the database to the program. In document database, the document can map almost directly to the programming language’s class structure. This makes programming easier, but does raise issues of data integrity, since some data are almost inevitably duplicated. Document databases also promise a more flexible approach to schema changes. In an RDBMS, any change to the data model is costly: programs need to modified, then deployed in conjunction with the schema change. In a document database, an application document can be modified whenever it wants. That is a good thing and is also a bad thing since it can be a risk to have inconsistent or obsolete document structures as a result of application version changes in document databases. The document model also have some scalability features. Since all the data needed for most operations is held in a single document, there is no need for joins and multi-object transactions. Avoiding joins and transactions eases clustering issues. read more...

Analyzing Geographical Data with Relational Databases {Comments Off on Analyzing Geographical Data with Relational Databases}

by Joe C
Summary:

This article talks about the use of relational databases to analyze the geographical data between multiple profiles. Many databases are currently not utilizing this type of information correctly, as they do not have the correct software needed. With the right software, it can potentially calculate customer base density of an area, the distance between multiple customers, and other spatial information analysis. To start off, geocoding data is data on the locational points on earth. When customers provide this information, the database will know exactly where each customer is coming from. By cross-referencing this data between multiple customers, users can figure out multitudes of information through both simple and complex algorithms. Examples of geocoding data customers usually provide include street address, city, ZIP, and state. Latitude/Longitude coordinates may be given directly by the customers or retrieved with the previously listed data. As for relational databases, there needs to be unified formats such as choosing between degree-minute-second or decimal degree formats. In addition, performance becomes a great issue once the amount of data scales to large numbers so that even the simplest calculations being iterated millions of times becomes a great workload to watch out for. read more...