Actualmente las bases de datos denominadas NoSQL le están ganando su particular batalla a las tradicionalmente conocidas como RDBM o bases de datos relacionales...
Ojo! Las noSQL funcionan bien cuando prácticamente lo único que hace es insertar información. Por ejemplo twitter o facebook consiste en eso, insertar millones de tweets y grupos de "Señoras que XXXX" pero rara vez se borran o editan.
También son más mucho lentos a la hora de ordenar pero eso no es gran problema porque por ejemplo en el caso de los tweets el orden es segun se insertan con lo cual no hace falta ordenar nada.
Por supuesto las noSQL soportan millones de inserciones ademas de manejar tablas de millones y millones de filas.
Para twitter, facebook o google les viene de lujo pero por ejemplo para una biblioteca o una fábrica sería una insensatez.
La diferencia radica en que el modelo bigtable sirve para guardar ingentes cantidades de datos "a tropel" mientras que el modelo relacional sirve para tener un control absoluto de los datos. Obviamente, todo ese control es a costa de rendimiento.
Con esto quiero decir que lo uno no es mejor que lo otro, simplemente sirven para cosas diferentes.
Y dejo de escribir que me va a quedar un comentario más largo que el artículo
A continuación se mencionan los problemas típicos de las bases de datos jerárquicas y que no existen en las bases de datos relacionales. Todos estos problemas derivan del hecho de que el sistema gestor de base de datos no implementa ningún control sobre los propios datos, sino que queda en manos de las aplicaciones garantizar que se cumplen las condiciones invariantes que se requieran (por ejemplo, evitar la duplicidad de registros). Dado que todas las aplicaciones están sujetas a errores y fallos, esto es imposible en la práctica. Además dichas condiciones suelen romperse ex profeso por motivos operativos (generalmente, ajustes debidos a cambios en el negocio) sin evaluarse sus consecuencias.
Duplicidad de registros
editado:
No se garantiza la inexistencia de registros duplicados. Esto también es cierto para los campos "clave". Es decir, no se garantiza que dos registros cualesquiera tengan diferentes valores en un subconjunto concreto de campos.
Integridad referencial
editado:
No existe garantía de que un registro hijo esté relacionado con un registro padre válido. Por ejemplo, es posible borrar un nodo padre sin eliminar antes los nodos hijo, de manera que éstos últimos están relacionados con un registro inválido o inexistente..
Desnormalización
editado:
Este no es tanto un problema del modelo jerárquico como del uso que se hace de él. Sin embargo, a diferencia del modelo relacional, las bases de datos jerárquicas no tienen controles que impidan la desnormalización de una base de datos. Por ejemplo, no existe el concepto de campos clave o campos únicos.
#2 "Por supuesto las noSQL soportan millones de inserciones ademas de manejar tablas de millones y millones de filas."
Es muy fácil hacer eso con SQL, INSERT INTO COPIA_TABLA(lista de campos) SELECT * FROM TABLA. Si TABLA tiene cientos de millones de registros, la tabal COPIA_TABLA habrá insertado esos cientos de millones. No tiene nada que ver la eficiencia.
#3 Es muy fácil hacer eso con SQL, INSERT INTO _COPIA_TABLA(lista_ de campos) SELECT * FROM TABLA. Si TABLA tiene cientos de millones de registros, la tabal _COPIA_TABLA_ habrá insertado esos cientos de millones. No tiene nada que ver la eficiencia.
Hombre, creo que se refiere a realizar inserciones una a una, cosa en la cual una nosql si es mas rapida.
Si usas mysql podrias usar una bd MyISAM, que no tiene transacciones ni integridad.
En postgres tiene copy es mas rapido que insert, y podrias hacer las inserciones sin transacciones y usando el oid de la tupla como su identificador para evitar usar un serial. Aunque usar oid no se recomienda porque puede perder unicidad.
Comentarios
Ojo! Las noSQL funcionan bien cuando prácticamente lo único que hace es insertar información. Por ejemplo twitter o facebook consiste en eso, insertar millones de tweets y grupos de "Señoras que XXXX" pero rara vez se borran o editan.
También son más mucho lentos a la hora de ordenar pero eso no es gran problema porque por ejemplo en el caso de los tweets el orden es segun se insertan con lo cual no hace falta ordenar nada.
Por supuesto las noSQL soportan millones de inserciones ademas de manejar tablas de millones y millones de filas.
Para twitter, facebook o google les viene de lujo pero por ejemplo para una biblioteca o una fábrica sería una insensatez.
La diferencia radica en que el modelo bigtable sirve para guardar ingentes cantidades de datos "a tropel" mientras que el modelo relacional sirve para tener un control absoluto de los datos. Obviamente, todo ese control es a costa de rendimiento.
Con esto quiero decir que lo uno no es mejor que lo otro, simplemente sirven para cosas diferentes.
Y dejo de escribir que me va a quedar un comentario más largo que el artículo
#1 Pero como se dice "Cuando tienes un martillo, todo te parecen clavos".
Algunos descubren las NoSQL y todo les parecen clavos. ^^
Aunque fb no tira muy bien, algunas veces pierde datos.
Genial: voy al enlace y me sale:
Database error:
Error establishing a database connection.
Edgar F. Codd rulez!
http://es.wikipedia.org/wiki/Base_de_datos_jer%C3%A1rquica
Limitaciones del modelo jerárquico
A continuación se mencionan los problemas típicos de las bases de datos jerárquicas y que no existen en las bases de datos relacionales. Todos estos problemas derivan del hecho de que el sistema gestor de base de datos no implementa ningún control sobre los propios datos, sino que queda en manos de las aplicaciones garantizar que se cumplen las condiciones invariantes que se requieran (por ejemplo, evitar la duplicidad de registros). Dado que todas las aplicaciones están sujetas a errores y fallos, esto es imposible en la práctica. Además dichas condiciones suelen romperse ex profeso por motivos operativos (generalmente, ajustes debidos a cambios en el negocio) sin evaluarse sus consecuencias.
Duplicidad de registros
No se garantiza la inexistencia de registros duplicados. Esto también es cierto para los campos "clave". Es decir, no se garantiza que dos registros cualesquiera tengan diferentes valores en un subconjunto concreto de campos.
Integridad referencial
No existe garantía de que un registro hijo esté relacionado con un registro padre válido. Por ejemplo, es posible borrar un nodo padre sin eliminar antes los nodos hijo, de manera que éstos últimos están relacionados con un registro inválido o inexistente..
Desnormalización
Este no es tanto un problema del modelo jerárquico como del uso que se hace de él. Sin embargo, a diferencia del modelo relacional, las bases de datos jerárquicas no tienen controles que impidan la desnormalización de una base de datos. Por ejemplo, no existe el concepto de campos clave o campos únicos.
#2 "Por supuesto las noSQL soportan millones de inserciones ademas de manejar tablas de millones y millones de filas."
Es muy fácil hacer eso con SQL, INSERT INTO COPIA_TABLA(lista de campos) SELECT * FROM TABLA. Si TABLA tiene cientos de millones de registros, la tabal COPIA_TABLA habrá insertado esos cientos de millones. No tiene nada que ver la eficiencia.
(El enlace que pones me da error de acceso a BD)
#3 Es muy fácil hacer eso con SQL, INSERT INTO _COPIA_TABLA(lista_ de campos) SELECT * FROM TABLA. Si TABLA tiene cientos de millones de registros, la tabal _COPIA_TABLA_ habrá insertado esos cientos de millones. No tiene nada que ver la eficiencia.
Hombre, creo que se refiere a realizar inserciones una a una, cosa en la cual una nosql si es mas rapida.
Si usas mysql podrias usar una bd MyISAM, que no tiene transacciones ni integridad.
En postgres tiene copy es mas rapido que insert, y podrias hacer las inserciones sin transacciones y usando el oid de la tupla como su identificador para evitar usar un serial. Aunque usar oid no se recomienda porque puede perder unicidad.