Diferencias entre RDBMS y Salesforce

Las personas han utilizado las bases de datos en sus actividades diarias durante años. Aunque ellos sólo se les ha dado el nombre de "bases de datos" recientemente, se han desarrollado durante años y hemos inventado cada vez más casos de uso para ellos. La mayoría de las aplicaciones modernas utilizan una base de datos de algún tipo. En teoría, una base de datos es simplemente una colección de datos relacionados. Nosotros llamamos al sistema de software que gestiona estos datos un sistema de gestión de bases de datos (DBMS). El DBMS también será responsable de controlar el acceso a la base de datos.

Las bases de datos han evolucionado a lo largo de los años desde simples sistemas basados ​​en archivos hasta sofisticados sistemas de gestión de bases de datos relacionales basados ​​en la nube y bases de datos en memoria.

Comprender los problemas de los sistemas basados ​​en archivos podría ayudarlo a evitar desafíos que podría ocurrir en los sistemas de bases de datos modernos. Los sistemas basados ​​en archivos se diseñaron para un conjunto de casos de uso. Esto fue impulsado principalmente por un intento de digitalizar las actividades que - como los humanos - solían hacer. Tome el sistema de archivo manual como ejemplo. Empresas y algunas bibliotecas solían tener una forma muy organizada de almacenar los diferentes archivos y libros. Un arreglo típico vería estos activos almacenados en gabinetes etiquetados. Los gabinetes mismos pueden tener cerraduras para controlar quién puede abrirlos y quién no, y se puede mantener un conjunto completo de gabinetes en habitaciones o áreas seguras para garantizar la seguridad adecuada, se toman medidas. La forma más sencilla de encontrar un documento en esta disposición sería revise todos los documentos uno por uno hasta que encuentre lo que busca.

Finalmente, se utilizaron sistemas de indexación para ayudar a localizar lo que queríamos más  rápidamente, en un forma simple, podríamos tener divisiones en el sistema de archivo o una hoja de índice resumida que apunta a la ubicación de cada documento almacenado.

Este sistema funciona siempre y cuando solo se almacene una pequeña cantidad de elementos, o si lo que queremos hacer es simplemente almacenar y recuperar elementos. Probablemente puedas imaginar la complejidad de recuperar datos de referencia cruzada o intentar obtener información de los datos recopilados.

Las bases de datos relacionales

Las bases de datos relacionales se hicieron muy populares a finales del siglo pasado. Dominaron el panorama empresarial y siguen siendo relevantes en la actualidad. Los datos en RDBMS se dividen en múltiples tablas relacionadas, donde cada fila de estas tablas tiene un identificador único llamado llave primaria. Las tablas relacionadas se pueden vincular haciendo referencia a esas claves primarias con llaves foraneas. 

Normalmente se accede a los datos mediante un lenguaje de consulta estructurado (como SQL o SOQL en Fuerza de ventas). La velocidad de recuperación de estos datos se ve afectada por varios factores, como la infraestructura subyacente, la forma en que se identifican e indexan los datos, y la cantidad de datos que se pueden almacenar y recuperar mientras los datos no están indexados.

Las transacciones de bases de datos relacionales se definen por las siguientes cuatro características (puede recuerde estos con el acrónimo ACID):

• Atómico: esto significa que una transacción debe tratarse como una unidad atómica. Todos sus tareas y operaciones deben tener éxito; de lo contrario, se revierte toda la transacción. Una base de datos nunca debe estar en un estado en el que una transacción se complete parcialmente.

• Consistente: si los datos estaban en un estado constante antes de una transacción en particular, entonces debería permanecer así una vez que se haya ejecutado la transacción. El estado de la base de datos debe mantenerse constante durante toda la transacción. En otras palabras, la transacción no debería tener un efecto negativo en los datos de la base de datos.

• Aislado: las transacciones son independientes, por lo que no debe haber dependencias entre ellos y sin datos compartidos. Esto es particularmente cierto cuando hay más de una transacción que se ejecuta simultáneamente en paralelo. Ninguna transacción afectará la existencia de las otras transacciones.

• Durable: los datos deben conservarse de forma persistente, incluso si el sistema no reinicia. Cuando una transacción actualiza datos en una base de datos y los confirma, la base de datos se espera que contenga los datos modificados. En el caso de una falla del sistema antes de los datos se escribe en el disco, debe actualizarse una vez que el sistema vuelva a estar en funcionamiento.

Las bases de datos relacionales son ideales para operaciones complejas y tareas de análisis de datos. Son

diseñados para valorar la coherencia sobre la disponibilidad y proporcionar una estructura rígida que los datos debe encajar.

Las bases de datos NoSQL

En la década de 1990, cuando Internet despegó, surgió un nuevo desafío, ya que las aplicaciones web

comenzó a producir datos que no estaban necesariamente estructurados u organizados y, a veces, difícil de encajar en una estructura tan rígida. Con esto vino el surgimiento de bases de datos, que ahora se conocen como bases de datos  not only SQL o NoSQL.

Las bases de datos no relacionales comparten las siguientes tres cualidades (puede recordarlas con el acrónimo BASE):

• Básicamente disponible: el sistema debe estar disponible, incluso en caso de falla (incluido el fallo de la red).

• SoftState: el estado de los datos en el sistema puede cambiar debido a la eventual actividades de coherencia.

• Consistencia eventual: la consistencia no está garantizada, pero en algún momento, los datos terminarán en un estado consistente. Aquí, podemos ver el principio de retraso consistencia en comparación con la consistencia inmediata de ACID.

Las bases de datos no relacionales son altamente escalables, aunque esto tiene un costo. Consistencia de los datos no está garantizado en todo momento, lo que significa que diferentes usuarios pueden ver diferentes versiones de los mismos datos al mismo tiempo, a pesar de que los datos eventualmente terminan en un estado consistente. Bases de datos no relacionales - todo lo contrario de Bases de datos relacionales: valoran la disponibilidad sobre la coherencia.

Mientras diseñas tu solución de Salesforce, es posible que se le presente un desafío que requiere un sistema de base de datos escalable y de alta disponibilidad. Heroku soporta algunas de las bases de datos NoSQL más populares como complementos, como MongoDB y CouchDB.

Para comprender qué casos de uso se deben considerar para NoSQL, repasemos los siguientes casos de uso:

• Datos estadísticos que se escriben con frecuencia pero que rara vez se leen.

• Big data (como estadísticas en muchos países durante muchos años).

• Activos binarios (como archivos PDF o MP3), donde sería necesario proporcionar almacenamiento en un almacén de datos que se puede servir directamente al navegador del usuario.

• Datos transitorios / temporales.

• Aplicaciones de alta disponibilidad, donde el tiempo de inactividad es fundamental.

• Aplicaciones de alta escalabilidad, donde es necesario manejar un número muy alto de transacciones.

Diferencias entre RDBS y Salesforce

La plataforma Salesforce no está diseñada para casos de uso en los que necesita recibir e ingestar toneladas de datos entrantes. Piense en un escenario de IoT como un escenario donde hay normalmente una necesidad de una plataforma escalable y de alta disponibilidad para recibir, ingestar y agregar los datos antes de procesarlos o transferirlos a otra plataforma que manejar el procesamiento. Este es un caso de uso en el que una plataforma como Heroku puede agregar mucho de valor para su solución, especialmente porque tiene un conector integrado a Salesforce a través de Heroku Connect. Durante la junta de revisión, evite errores que terminan estirando demasiado uno de los componentes de su solución, como impulsar la entrada de comunicaciones IoT en Salesforce directamente.

Salesforce es ligeramente diferente de los RDBMS regulares, Salesforce se trata de una base de datos multi-tenant donde los datos de los diferentes tenants se separan mediante ID de organización. Sin embargo, necesita conocer algunos de los conceptos que podrían considerarse subóptimos en el diseño estándar de RDBMS pero están bien en el mundo de Salesforce, como los siguientes:

• Las relaciones asimismo están absolutamente bien en Salesforce. De hecho, podrían darte la capacidad de utilizar algunas capacidades listas para usarse, que simplemente no funcionarán si modela los datos usando dos objetos.

• En una base de datos normal, normalmente no es aceptable tener una tabla con 500 columnas. Sin embargo, esto es aceptable en Salesforce para algunos casos de uso, particularmente si está creando un objeto de agregación desnormalizado.

• En las bases de datos normales, rara vez se nota una relación directa entre un registro secundario y un

registro grandparent. Mientras esté en Salesforce, esto no es algo fuera de lo común, tales relaciones podrían establecerse simplemente porque impactan la forma en que los datos son presentados al usuario final (por ejemplo, al establecer una relación de búsqueda, relacionando los registros simplemente se mostrarán automáticamente en el diseño de página del registro grandparent, sin la necesidad de que escriba un código personalizado para acumular estos registros desde el registro de los padres al grandparent).

• Los campos de Salesforce reconocen los tipos. Además de su función como contenedores de datos, similares a un campo de base de datos normal, también proporcionan validaciones de tipo de datos integradas. Usted no podrá establecer un número en un campo de casilla de verificación, y esto no es algo que pueda apagar.

• Salesforce tiene su propio lenguaje de consulta de datos estructurados conocido como Objeto de Salesforce Query Language (SOQL) que intercambia la flexibilidad de SQL por algunas funcionalidades incorporadas que acelerarán significativamente el desarrollo de la mayoría de los casos de uso.

• El almacenamiento de datos es un tema importante que debe tener en cuenta al diseñar su modelo de datos de Salesforce. El espacio de almacenamiento en sí es una cosa, ya que no es muy barato en comparación con otras plataformas. Pero lo más importante, debe estar atento al tamaño de su objeto de Salesforce para garantizar el rendimiento de ciertas funcionalidades, como los informes, no se deterioren con el rápido aumento del tamaño del objeto. 

• Salesforce viene con un modelo de control de acceso a datos muy sólido. Esto nos permite controlar no solo qué objetos y campos son accesibles para un usuario en particular, sino que graba también. Todo esto se puede hacer utilizando funciones de apuntar y hacer clic en lugar de que escribir código. Sin embargo, estas funcionalidades normalmente crean algunos datos detrás de escena para impulsar los requisitos de visibilidad. Necesitas comprender cómo funcionan y anticipar qué tipo de desafíos podría encontrar al utilizar cada enfoque de intercambio diferente.