Download SQL_vs_NoSQL

HERRAMIENTAS SQL vs NO SQL
SQL (Structured Query Language) bases de datos han sido un mecanismo de
almacenamiento de datos principal durante más de cuatro décadas. Su uso estalló a
finales de 1990 con el auge de las aplicaciones web y las opciones de código abierto como
MySQL, PostgreSQL y SQLite.
Bases de datos NoSQL han existido desde la década de 1960, pero han sido recientemente
ganando tracción con opciones populares como MongoDB, CouchDB, Redis y Apache
Cassandra.
Los ejemplos se aplican a los sistemas de bases de datos MySQL populares SQL y NoSQL
MongoDB. Otras bases de datos SQL / NoSQL son similares, pero habrá pequeñas
diferencias en características y sintaxis.
SQL vs NoSQL
MITO: NoSQL reemplaza SQL
Eso sería como decir que los barcos fueron reemplazados por los coches porque son una
tecnología más nueva. SQL y NoSQL hacen lo mismo: almacenar datos. Ellos toman
diferentes enfoques, que pueden ayudar u obstaculizar su proyecto.
A pesar de sentirse más reciente y el acaparamiento de los titulares recientes, NoSQL no
es un reemplazo para SQL - es una alternativa.
Algunas bases de datos SQL están adoptando características NoSQL y viceversa. Las
opciones pueden llegar a ser cada vez más difusa, y las bases de datos híbridos NewSQL
podrían proporcionar algunas opciones interesantes en el futuro.
La elección de una combinación de tecnología inusual o una mezcla de SQL y NoSQL es
posible.
Tablas SQL vs Documentos NoSQL
Bases de datos SQL proporcionan una tienda de tablas de datos relacionados. Por
ejemplo, si ejecuta una tienda de libros en línea, la información del libro se puede agregar
a una tabla llamada Book:
ISBN
Título
autor
formato
precio
9780992461225
JavaScript: principiante a Ninja
Darren Jones
ebook
29,00
9780994182654
Jump Start Git
Shaumik Daityari
ebook
29,00
Cada fila es un registro libro diferente. El diseño es rígido; no puede utilizar la misma tabla
para almacenar información diferente o insertar una cadena en la que se espera que un
número.
Las bases de datos NoSQL guardan JSON como campo-valor en documentos pares, por
ejemplo:
{
ISBN: 9780992461225,
Título: "JavaScript: principiante a Ninja",
autor: "Darren Jones",
formato: "libro electrónico",
Precio: 29.00
}
Documentos similares pueden ser almacenados en una colección, que es análoga a una
tabla de SQL. Sin embargo, puede almacenar cualquier dato que sea en cualquier
documento; la base de datos NoSQL no se quejará. Por ejemplo:
{
ISBN: 9780992461225,
Título: "JavaScript: principiante a Ninja",
autor: "Darren Jones",
año: 2014,
formato: "libro electrónico",
Precio: 29.00,
Descripción: "Aprende JavaScript desde cero!",
nota: "5.5",
Comentado [
{Nombre: "Un lector", texto: ". El mejor libro que he leído JavaScript" },
{Nombre: "JS Experto", texto: "Recomendaciones para novatos y expertos
desarrolladores por igual." }
]
}
Las Tablas SQL crean una plantilla de datos estricta, por lo que es difícil cometer errores.
NoSQL es más flexible y perdonar, pero ser capaz de almacenar los datos en cualquier
lugar que puede conducir a problemas de consistencia.
SQL esquema vs NoSQL schemaless
En una base de datos SQL, es imposible agregar datos hasta que se definen las tablas y los
tipos de campo en lo que se conoce como un esquema. El esquema contiene
opcionalmente otra información, tal como -
claves principales - identificadores únicos, como el ISBN que se aplican a un solo registro
indices - campos comúnmente consultados en un índice para ayudar a la búsqueda rápida
relaciones - vínculos lógicos entre los campos de datos
funcionalidad como disparadores (triggers) y procedimientos almacenados.
El esquema de datos debe ser diseñado e implementado antes de cualquier lógica de
negocio puede ser desarrollado para manipular los datos. Es posible realizar las
actualizaciones más tarde, pero los grandes cambios pueden ser complicados.
En una base de datos NoSQL, los datos se pueden añadir en cualquier lugar, en cualquier
momento. No hay necesidad de especificar un diseño de documentos o incluso una
colección por adelantado. Por ejemplo, en MongoDB la siguiente declaración creará un
nuevo documento en una nueva colección de libros si no se ha creado con anterioridad:
db.book.insert (
ISBN: 9780994182654,
Título: "Jump Start Git",
autor: "Shaumik Daityari",
formato: "libro electrónico",
Precio: 29.00
);
(MongoDB añadirá automáticamente un valor _id única para cada documento en una
colección. Se pueden definir índices, o se pueden hacer más adelante si es necesario.)
Una base de datos NoSQL puede ser más adecuado para proyectos en los que los
requisitos iniciales de datos son difíciles de determinar. Dicho esto, no hay que confundir
la dificultad con la pereza: descuidar el diseño de un buen almacénamiento de datos al
comienzo del proyecto dará lugar a problemas más adelante.
SQL Normalización vs NoSQL Desnormalización
Suponemos que queremos añadir información del editor de nuestra base de datos librería.
Un único editor podría ofrecer más de un título así, en una base de datos SQL, creamos
una nueva tabla editorial:
Identificación
nombre
país
electrónico
SP001
SitePoint
Australia
feedback@sitepoint.com
A continuación, puede agregar un campo PUBLISHER_ID a nuestra mesa libro, que hace
referencia a los registros por publisher.id:
ISBN
título
autor
formato precio
PUBLISHER_ID
9780992461225 JavaScript: principiante Darren Jones
a Ninja
ebook
29,00
SP001
9780994182654 Jump Start Git
ebook
29,00
SP001
Shaumik Daityari
Esto reduce al mínimo la redundancia de datos; no estamos repitiendo la información del
editor de cada libro, sólo la referencia a la misma. Esta técnica se conoce como la
normalización, y tiene beneficios prácticos. Podemos actualizar un único editor sin
cambiar datos de Book.
Podemos utilizar técnicas de normalización en NoSQL. Los documentos en la colección de
libros:
{
ISBN: 9780992461225,
Título: "JavaScript: principiante a Ninja",
autor: "Darren Jones",
formato: "libro electrónico",
Precio: 29.00,
PUBLISHER_ID: "SP001"
}
Referencia a un documento en una colección editorial:
{
id: "SP001"
nombre: "SitePoint",
país: "Australia",
correo electrónico: "feedback@sitepoint.com"
}
Sin embargo, esto no siempre es práctico, por razones que se harán evidentes a
continuación. Podemos optar por desnormalizar nuestro documento y repetir información
del editor de cada libro:
{
ISBN: 9780992461225,
Título: "JavaScript: principiante a Ninja",
autor: "Darren Jones",
formato: "libro electrónico",
Precio: 29.00,
Editorial: {
nombre: "SitePoint",
país: "Australia",
correo electrónico: "feedback@sitepoint.com"
}
}
Esto lleva a las consultas más rápidas, pero la actualización de la información del editor en
varios registros será significativamente más lento.
SQL relacional JOIN vs NoSQL
Las consultas SQL ofrecen una poderosa cláusula JOIN. Podemos obtener datos
relacionados con varias tablas mediante una única sentencia SQL. Por ejemplo:
SELECT Book.title, book.author, publisher.name
FROM libro
LEFT JOIN book.publisher_id ON publisher.id;
Esto devuelve todos los títulos de los libros, los autores y los nombres de editores
asociados (presumiendo se ha establecido una).
NoSQL no tiene equivalente de JOIN, y esto puede impactar aquellos con experiencia SQL.
Si utilizamos colecciones normalizadas como se describió anteriormente, tendríamos que
obtener todos los documentos de libros, recuperar todos los documentos de editores
asociados, y vincular manualmente los dos en nuestra lógica del programa. Esta es una
razón de que desnormalización a menudo es esencial.
SQL vs NoSQL Integridad de los datos
La mayoría de las bases de datos SQL le permiten hacer cumplir las reglas de integridad de
datos mediante restricciones de claves foráneas (a menos que usted todavía está
utilizando el más viejo, motor de almacenamiento MyISAM desaparecida en MySQL).
Nuestra tienda de libros podría > asegurar que todos los libros tienen un código PUBLISHER_ID válido que coincide con
una entrada en la tabla editor, y
>No permitir a los editores ser eliminados si uno o más libros son asignados a ellos.
El esquema hace cumplir estas reglas para la base de datos a seguir. Es imposible para los
desarrolladores o usuarios añadir, editar o eliminar registros, lo que podría resultar en
datos no válidos o registros huérfanos.
Las mismas opciones de integridad de datos no están disponibles en las bases de datos
NoSQL; se puede almacenar lo que quieras independientemente de cualquier otro
documento. Lo ideal sería que un solo documento será la única fuente de toda la
información sobre el objeto.
SQL vs Transacciones NoSQL
En las bases de datos SQL, dos o más cambios se pueden ejecutar en una transacción - una
envoltura de todo o nada que garantiza el éxito o el fracaso. Por ejemplo, presume que
nuestra tienda libro contenía las tablas de pedidos y existencias.
Cuando se ordena un libro, le añadimos un registro a la tabla de orden y disminuye el
recuento de valores en la tabla de valores. Si ejecutamos esos dos actualizaciones de
forma individual, se podría tener éxito y el otro fallar - dejando así nuestras cifras fuera de
sincronía.
La colocación de las mismas actualizaciones en una transacción asegura ya sea tanto éxito
o que ambos fallen.
En una base de datos NoSQL, la modificación de un solo documento es atómica. En otras
palabras, si usted está actualizando tres valores dentro de un documento, o bien los tres
se están actualizando correctamente, o ,se mantienen sin cambios.
Sin embargo, no hay equivalente de transacciones para cambios a varios documentos. Hay
opciones en transacciones similares, pero, en el momento de la escritura, éstos deben ser
procesados manualmente en el código.
SQL vs Sintaxis CRUD NoSQL
Crear, leer,actualizar y eliminar datos, es la base de todos los sistemas de bases de datos.
En escencia:
SQL es un lenguaje declarativo ligero. Es engañosamente poderoso, y se ha convertido en
una norma internacional, aunque la mayoría de los sistemas implementan sutilmente
diferentes sintaxis.
Bases de datos NoSQL utilizan JavaScripty-looking consultas con argumentos JSON-like.
Operaciones básicas son simples, pero anidadas con JSON pueden llegar a ser cada vez
más complicada para más consultas complejas.
Una rápida comparación:
_____________________________________________________________________
insertar un nuevo registro de libros:
SQL
INSERT INTO libro ( 'ISBN','title','author' )
VALUES ( '9780992461256', 'Full Stack JavaScript', 'Colin Ihrig & Adam Bretz' );
NoSQL
db.book.insert ({
ISBN: "9780992461256",
Título: "Full Stack JavaScript",
autor: "Colin Ihrig & Adam Bretz"
});
_____________________________________________________________________
Actualizar un registro de libros:
SQL
UPDATE libro SET precio= 19,99 WHERE ISBN = '9780992461256';
NoSQL
db.book.update (
ISBN: '9780992461256'},
$ Set: {precio: 19,99}}
);
_____________________________________________________________________
Consulta devolver todos los títulos de los libros más de $ 10:
SQL
SELECT titulo FROM libro WHERE precio> 10;
NoSQL
db.book.find (
{Precio: {& gt ;: 10}},
{_id: 0, título: 1}
);
El segundo objeto JSON se conoce como proyección: establece que se devuelven los
campos (_id se devuelve por defecto, así que tiene que ser desarmado).
_____________________________________________________________________
Contar el número de libros SitePoint:
SQL
SELECT COUNT (1) FROM libro WHERE PUBLISHER_ID = 'SP001';
NoSQL
db.book.count ({
"publisher.name": "SitePoint"
});
Esto supone se utilizan documentos no normalizados.
_____________________________________________________________________
Devolver el número de tipos de formato de libro:
SQL
SELECT, COUNT (1) AS `total` FROM libro GROUP BY formato;
NoSQL
db.book.aggregate ([
{$ Grupo:
{
_id: "Formato de $",
Total: {$ suma: 1}
}
}
]);
Esto se conoce como la agregación: un nuevo conjunto de documentos se calcula a partir
de un conjunto original.
_____________________________________________________________________
Eliminar todos los libros SitePoint
SQL
DELETE FROM libro WHERE PUBLISHER_ID = 'SP001';
Alternativamente, es posible eliminar el registro editor y tener esta cascada de registros
de libros asociados si las claves externas se especifican adecuadamente.
NoSQL
db.book.remove ({
"publisher.name": "SitePoint"
});
SQL vs Rendimiento NoSQL
Tal vez la comparación más controvertida, NoSQL es citado regularmente como siendo
más rápido que SQL. Esto no es de sorprender; NoSQL le permite recuperar toda la
información sobre un elemento específico en una sola solicitud. No hay necesidad de
JOINs relacionada o consultas SQL complejas.
Dicho esto, su diseño y datos requeridos del proyecto tendrá mayor impacto. Una base de
datos SQL bien diseñado es casi seguro que de un mejor desempeño que un mal diseño
equivalente NoSQL y viceversa.
SQL vs NoSQL Escala
Como los datos crezcan , puede que le resulte necesario para distribuir la carga entre
varios servidores. Esto puede ser difícil para los sistemas basados en SQL. ¿Cómo se
asignan los datos relacionados? La agrupación es posiblemente la opción más simple;
varios servidores acceden al mismo almacén central, pero incluso esto tiene desafíos.
Modelos de datos más simples de NoSQL pueden hacer el proceso más fácil, y muchos han
sido construidos con la ampliación funcionalidad desde el principio. Eso es una
generalización, por lo que buscan asesoramiento de expertos si se encuentra con esta
situación.
SQL vs NoSQL prácticos
Por último, vamos a considerar los problemas de seguridad y del sistema. Las bases de
datos más populares NoSQL han existido unos pocos años; son más propensos a exhibir
problemas de que los productos de SQL más maduros. Se han reportado muchos
problemas, pero la mayoría se reducen a un solo tema: el conocimiento.
Los desarrolladores y administradores de sistemas tienen menos experiencia con los
sistemas de bases de datos más recientes, por lo que se cometen errores. Optar por
NoSQL porque se siente más fresco, o porque se quiere evitar el diseño del esquema,
inevitablemente, conduce a problemas más adelante.
SQL vs NoSQL Resumen
Bases de datos SQL y NoSQL hacen lo mismo de diferentes maneras. Es posible elegir una
opción y cambiar a otro más adelante, pero un poco de planificación puede ahorrar
tiempo y dinero.
Proyectos en SQL es ideal:
>requisitos de datos lógicos relacionados discretos que se pueden identificar por
adelantado
>La integridad de los datos es esencial
>basada en estándares de tecnología probada con buena experiencia del desarrollador y
apoyo.
Proyectos donde NoSQL es ideal:
>las necesidades de datos no relacionados, indeterminados o en evolución
>objetivos más simples o más flojas del proyecto, capaz de empezar a programar
inmediatamente
>La velocidad y escalabilidad es imprescindible.
En el caso de nuestra tienda de libros, una base de datos SQL parece la opción más
práctica - especialmente cuando introducimos instalaciones de comercio electrónico que
requieren soporte de transacciones robusto.
Bibliografia:
http://www.sitepoint.com/sql-vs-nosql-differences/
Para mas informacion:
https://www.digitalocean.com/community/tutorials/understanding-sql-and-nosqldatabases-and-different-database-models
http://www.campusmvp.es/recursos/post/Fundamentos-de-bases-de-datos-NoSQLMongoDB.aspx
https://www.mongodb.com/es