Pros y contras de bases de datos de varios valores

Question

Acabo de comenzar un nuevo trabajo en el que voy a tener que hacer un buen trabajo con una base de datos de varios valores (UniVerse). La poca experiencia de la base de datos que tengo está en bases de datos relacionales (SqlServer) y estoy buscando información imparcial acerca de cómo se comparan los pros y los contras de un MVD con las bases de datos relacionales.

Todos en la oficina provienen de una base de datos relacional (y odian a UniVerse) o han estado aquí por años y les encanta.

Answer 1

Primero, un descargo de responsabilidad. Trabajo con UniData (la base de datos hermana de UniVerse) y ocasionalmente con blog on it, por lo que no puedo afirmar que soy completamente imparcial; Lo intentaré, sin embargo.

Éstos son algunos puntos de la consideración de que:

• Una gran diferencia entre una base de datos SQL y un Valor múltiple DB es que el MVDB no se adhiere a 1NF. Esto tiene sus pros y sus contras. Puede ser (y comúnmente) maltratado, pero hay momentos en que puede ser extremadamente funcional. El mayor beneficio es que significa que no siempre se necesita una tabla de combinación que puede hacer que las consultas sean mucho más rápidas.

• Almacena los metadatos de una manera completamente nueva en comparación con los DB de SQL habituales. Cada archivo/tabla no tiene un esquema concreto. En cambio, tiene 1 o más archivos 'de diccionario' que están formados por registros que le indican cómo deben interpretarse los datos. Esto le permite no solo almacenar múltiples interpretaciones de los datos (raw/mayúsculas/minúsculas, campos combinados, etc.) sino que también le permite realizar el equivalente de enumeraciones y uniones. Puede ser extremely powerful if done right.

• Lamentablemente, aunque el concepto tiene mucho potencial, falta el conjunto de herramientas del DBMS. El desarrollo es impulsado, pero un conjunto extremadamente pequeño de casos de negocios que parecen estar impulsados ​​por una mentalidad de "mantener las luces encendidas" de los sistemas de software de envejecimiento existentes & que se crearon en él. Aunque tiene herramientas para la integración (como conectores .NET, interfaz ODBC para consultas SQL, etc.) tienen problemas. Por ejemplo, la interfaz UniObjects .NET carece de granulación en seguridad (básicamente todo o nada).

• No es solo un DBMS, sino que es esencialmente una plataforma de aplicaciones completa. A pesar de que UniBasic no es tan poderoso como un lenguaje basado en .NET, seguro que supera a T-SQL y tiene un giro rápido para impulsar las reglas comerciales.

Answer 2

No existen pros y contras como tales, simplemente usan métodos diferentes para almacenar valores. UniVerse usa un delimitador para separar los valores (IIRC usa char (254) y char (253) para dividir los múltiples valores en un campo, y char (255) para separar los registros reales en el archivo de datos. Podría estar equivocado. sin embargo, han pasado más de 10 años desde la última vez que lo usé). A algunas personas les encanta este método de almacenamiento de datos, al igual que algunas personas prefieren los autos antiguos en comparación con los modelos antiguos, o algunas personas prefieren usar un caballo y un carro en lugar de un vehículo de motor moderno. (Por supuesto, esta es solo mi opinión).

Almacenar múltiples valores dentro de un campo significa que no tiene la tabla adicional que SQLServer habría utilizado, efectivamente tiene un nivel de desnormalización. Usar estos valores múltiples es fácil y bueno si usamos una tecnología que va de manera nativa con UniVerse (solíamos usar un sistema de ventanas llamado CueBIC), pero se convierte en un PITA cuando se conecta a la base de datos desde otro lenguaje como C++ o VB. tiene que leer un registro y separar los valores usted mismo. Esto significa que también fue difícil buscar en esos valores múltiples.

Pero, de nuevo, tal vez las cosas han cambiado desde la última vez que lo usé, tal vez alguien haya escrito un buen controlador para que pueda interactuar fácilmente con UniVerse desde una plataforma .Net. Espero por su bien que tengan.

Answer 3

Las bases de datos de MV son conocidas por exprimir el impresionante rendimiento de los servidores de relativamente baja potencia.

Utilizan un sistema de archivo de hash de enlace que reduce la mayoría de las operaciones de acceso a archivos a una operación matemática y una lectura de disco único cuando se conoce la clave de registro. En un sistema configurado correctamente, las lecturas de un archivo con 1,000,000,000 de registros no toman más tiempo que las de un archivo con 1,000 registros, siempre que se conozca la clave de registro.

Las claves de registro deben ser únicas, y en las aplicaciones donde una clave de registro se puede configurar de forma que se pueda determinar algorítmicamente o programáticamente, la sobrecarga implicada en el acceso a la base de datos puede ser mínima. Pero, por supuesto, esto generalmente implica acceder a la base de datos de maneras que probablemente no se considerarían "relacionales".

Answer 4

Como sugirió Dave, las bases de datos de MV están realmente diseñadas para funcionar mejor cuando conoce la clave del registro que está tratando de recuperar. Algunas personas se refieren a ellos como sistemas de bases de datos basadas en registros, en oposición a SQL, que es un sistema de base de datos basado en conjuntos.

Realmente depende de lo que intenta hacer, cómo se deben estructurar los datos y qué otras herramientas tiene disponible. Paso la mayor parte del tiempo trabajando en MV (en su mayoría, los productos de Revelation) y manejamos conjuntos de registros en más de 10,000,000, y la velocidad es buena.

La intensidad de la base de datos de MV es cuando los datos son fluidos. Encontramos que la mayoría de nuestros clientes lo usan para aplicaciones como productos legales, médicos y financieros; aplicaciones donde las relaciones son complejas y pueden cambiar rápidamente y drásticamente con el tiempo.

Es posible que desee ver el movimiento sin SQL, que comparte muchos de los mismos conceptos, aunque MV y no SQL realmente no son lo mismo.

La desventaja principal de MV es menos en su estructura, que sus herramientas. Generalmente encontrará que, dado que la base de desarrolladores es más pequeña, el conjunto de herramientas y la ayuda disponibles son más pequeños. También puede encontrar que el lenguaje básico incrustado que la mayoría de las ofertas le ofrecen carece de la codificación de estilo de objeto a la que está acostumbrado. Hay veces que incluso JavaScript parece tener más funcionalidad como lenguaje.

Dicho esto, dado que las bases de datos de MV son principalmente cadenas gigantes, el manejo de las cadenas de idiomas es excelente. Son geniales para manipular cadenas HTML y XML directamente.

Supongo que la gran pregunta que tengo es si tiene preguntas específicas. No voy a abrir una guerra diciendo que es como pasar de Windows a Linux o una Mac, o incluso pasar de Debian a Red Hat, pero las estructuras y sistemas son diferentes, por lo que tienen diferentes conceptos, fortalezas, limitaciones y propósitos. . Si intenta manejar una base de datos MV como SQL (que puede), encontrará que no es la mejor opción. Una base de datos MV mal diseñada puede ser un ejercicio de frustración. Una base de datos MV bien diseñada puede ser una cosa de belleza.

Answer 5

Escalar a muchos elementos (registros) en archivos funciona bien. Escalar a muchos valores o subvalores dentro de los registros creará problemas de rendimiento. El diseño de la aplicación debe ser sensible al valor límite y las listas de subvalores por debajo del umbral de varios miles.

El manejo de cadenas es excelente.Como es el manejo de enteros. Los lenguajes de MV Basic están escritos de manera flexible, por lo que no se espera demasiada aplicación por parte del compilador. Dicho esto, dado que los elementos de origen de MV Basic son como cualquier otro dato y el compilador es solo otro verbo en el entorno de DB, escribir generadores de código y precompiladores es muy fácil. Es un buen entorno para crear una capa de herramientas debajo de su aplicación.