Discusión:Sistema de gestión de base de datos

Reversiòn del 21/9

Hice la reversión, pues el artículo estaba bastante desorganizado y mezclado. El título es "Sistema de gestión de base de datos", no tiene que tener manuales de instalación de las bases de datos, habia figuras que no estaban

y mucho texto copiado y pegado de varias páginas web, ejemplos:

http://www.alasingenieria.com/Oracle/Oracle.htm y http://www.infor.uva.es/~jvegas/cursos/bd/oraback/oraback.html

De a poco podemos agregar algo más d einfo de cada motor, pero referida específicamente al SGBD

saludos,alexav8 18:19 21 sep 2007 (CEST)

Inconvenientes

Creo que este apartado no está bien conseguido o redactado. La verdad es que no considero ninguno de los puntos como inconveniente EN TODOS LOS CASOS. Por ejemplo, el punto 1 y 2 seguramente es verdad en arquitecturas Oracle pero seguramente no lo es para otros sistemas (MySQL, PostGreSQL o SQL-Server). Y es evidente que si no se hace un buen diseño y no hay documentación será más difícil el funcionamiento o mantenimiento, pero debemos asumir que los inconvenientes deben ser si las cosas se hacen bien.

Algunos cambios.

Hola.

• Se compone de un lenguaje de definición de datos, de un lenguaje de manipulación de datos y de un lenguaje de consulta.
  • Un SGBD es un software, por lo tanto no se compone de lenguajes sino de módulos o subsistemas...En todo caso se podría decir que se compone de un subsistema de interfase con los usuarios que provee diferentes intérpretes y bibliotecas, un sistema de gestión de datos propiamente dicho, un subsistema de persistencia, etc....

Creo que lo mejor es sacarlo.

• Redundancia mínima. Un buen diseño de una base de datos logrará evitar la aparición de información repetida o redundante. De entrada, lo ideal es lograr una redundancia nula; no obstante, en algunos casos la complejidad de los cálculos hace necesaria la aparición de redundancias.
  • No creo que la redundancia mínima sea un objetivo de un DBMS, sino más bien del diseño de una base de datos.
• Consistencia. En aquellos casos en los que no se ha logrado eliminar la redundancia, será necesario vigilar que aquella información que aparece repetida se actualice de forma coherente, es decir, que todos los datos repetidos se actualicen de forma simultánea.
  • La consistencia no sólo tiene que ver con la redundancia sino con que la base represente exactamente lo que debe representar.
• *Respaldo y recuperación. Los SGBD deben proporcionar una forma eficiente de realizar copias de respaldo de la información almacenada en ellos, y de restaurar a partir de estas copias los datos que se hayan podido perder.
  • Las tecnicas de recuperación van mucho más allá que la recuperación de copias de seguridad ... tiene que ver con la integridad en el sentido que se menciona en el artículo.
• Faltó hablar de las transacciones.
• #No hay duplicidad de información, comprobación de información en el momento de introducir la misma.
  • Facilidad en la programación de las restricciones que garantizan la consistencia...
• #No hay duplicidad de información, comprobación de información en el momento de introducir la misma.#Integridad referencial al terminar los registros.
  • Esto tiene que ver con el diseño de la base y no tanto con el SGBD.
• #El mal diseño de esta puede originar problemas a futuro.
  • Esto es cierto para cualquier cosa: Una base de datos, un sistema que no usa base de datos o cualquier objeto no informático (una silla, un barco, un auto).
• #Un mal adiestramiento a los usuarios puede originar problemas a futuro.
  • Nuevamente, algo que es cierto en cualquier contexto.
• #Si no se encuentra un manual del sistema no se podrán hacer relaciones con facilidad.
  • Otra vez algo que es cierto para cualquier cosa.
• #Generan campos vacíos en exceso.
  • Esto es directamente falso. Esto sucede sólo si no se hace un diseño adecuado de una base relacional... como cuando no se hace un diseño adecuado orientado a objetos en un programa, etc...
• #El mal diseño de seguridad genera problemas en esta.
  • Nuevamente, igual que en cualquier otro tipo de sistema !!!

Más tarde entraré con la arquitectura de un SGBD ... si alguien más se anima...sería bárbaro.

FDO. (discusión) 14:35 1 ago 2008 (UTC)

Otro comentario

El último punto del listado de objetivos no es un objetivo.

• Tiempo de respuesta. Lógicamente, es deseable minimizar el tiempo que el SGBD tarda en darnos la información solicitada y en almacenar los cambios realizados.

Lógicamente, es preferible respirar un poco en esta vida ... lógicamente, eso no significa que mi objetivo en esta vida sea respirar.

Además, si fuese un objetivo no sería simplemente deseable, sino obligatorio. Y, por ende, el modelo de SGBD más utilizado (Relacional) ha sido siempre criticado por su lentitud. La velocidad es deseable, pero NUNCA un objetivo de un SGBD.

Ya usado en la edad media

Los pioneros en su uso, fueron la familia Palacios, los cuales ya en la edad media, la usaban para administras los esclavos que trabajaban sus tierras. Esto es, sencillamente, imposible, es obvio, o se trata de vandalismo o está puesto aquí por error. Lo borraré si nadie objeta lo contrario. Miguelisimo1985 (discusión) 11:06 18 abr 2009 (UTC)