Historias
Slashboxes
Comentarios
 
Este hilo ha sido archivado. No pueden publicarse nuevos comentarios.
Mostrar opciones Umbral:
Y recuerda: Los comentarios que siguen pertenecen a las personas que los han enviado. No somos responsables de los mismos.
  • Features avanzadas

    (Puntos:2)
    por PiotR (1038) <piotrQUITAESTO@member.fsf.org> el Sábado, 17 Enero de 2004, 22:30h (#255085)
    ( http://www.lartc.org | Última bitácora: Viernes, 06 Agosto de 2004, 13:07h )
    Podrías echar un poco de luz sobre " integridad referencial, las vistas, los procedimientos almacenados, las subconsultas.", yo como siempre he usado mysql no sé qué son, estaría bien leerlo de primera mano de alguien con experiencia en ello que lo describa de manera concisa.
    --

    [ Padre ]
    • Re:Features avanzadas

      (Puntos:5, Interesante)
      por IndianaJones (11281) el Domingo, 18 Enero de 2004, 00:28h (#255110)
      ( http://barrapunto.com/ )
      Hola. Te voy a poner un ejemplillo de cada cosa, usando como base de datos PostgreSQL. Como es muy probable que exista algún error en el texto, se admiten correcciones ;)

      Integridad referencial: Imaginemos que tenemos una tabla "clientes" con dos columnas, "id_cliente" y "nombre", por ejemplo. Podríamos crear otra tabla llamada "dni_clientes", con dos columnas, "id_cliente" y "dni". La columna "id_cliente" de "dni_clientes" la crearíamos como una clave ajena (foreign key) que apunta a la columna con el mismo nombre (aunque no tendría por qué) de la tabla "clientes". Crearíamos la segunda tabla así:

      create table dni_clientes (
      cliente_id integer references clientes(id_cliente),
      dni integer
      );

      Por mantener la integridad referencial entiendo que es mantener la correspondencia de las claves ajenas entre las tablas.

      Vistas: Se usan para consultas complejas, y son como una forma de encapsular consultas. Ejemplo:

      create view mi_vista as
      select nombre,dni from clientes, dni_clientes
      where clientes.id_cliente=dni_clientes.id_cliente

      Podríamos hacer una consulta sobre esa vista, como si se tratase de una tabla. Ejemplo:

      select nombre,dni from mi_vista where
      nombre="pepe";

      En este caso no sería muy útil ya que podríamos haber obtenido los mismos resultados sin recurrir a una vista, pero es sólo un ejemplo :)

      Procedimientos almacenados: son procedimientos escritos en un lenguaje determinado que se almacenan en la base de datos. En Oracle el lenguaje es PL/SQL, en PostgreSQL es PLPG/SQL. Ejemplo de una función en PLPG/SQL:

      create function nuevo_cliente(integer,integer,varchar)
      returns integer as '
      declare
      par_id_cliente alias for $1;
      par_dni alias for $2;
      par_nombre alias for $3;
      begin
      insert into clientes
      (id_cliente,nombre)
      values
      (par_id_cliente,par_nombre);
      insert into dni_clientes
      (id_cliente,dni)
      values
      (par_id_cliente,par_dni);
      return id_cliente;
      end;' language 'plpgsql';

      Después, para usarla haríamos algo como:

      select nuevo_cliente('8','92389924','pepe');

      Eso introduciría un nuevo cliente en las tablas "clientes" y "dni_clientes".

      Subconsultas: Creo que se refiere a esto:

      select dni from (select id_cliente,dni,nombre
      from clientes,dni_clientes where
      clientes.id_cliente=dni_clientes.id_cliente)
      where id_cliente>6;

      Aunque también puede referirse a esto:

      select id_cliente,dni,(select id_cliente as id_cliente2,nombre from nombres)
      where id_cliente=id_cliente2;

      Como ves, la presencia de estas funcionalidades en una base de datos multiplica (y por un factor elevado) el número de posibilidades a la hora de realizar operaciones con la base de datos.

      Si quieres aprender bien estas cosas (y muchas otras que desconocerás si sólo has usado MySQL) de forma amena y sin leer tropecientos manuales, te recomiendo el libro online SQL for web nerds [greenspun.com], de Philip Greenspun. Parte de ejemplos básicos y va complicando las consultas, introduciendo los nuevos conceptos necesarios para realizarlas. Creo recordar que los ejemplos de código están hechos para Oracle, pero para coger el concepto es más que de sobra, luego sólo cambia la sintaxis.

      saludos

      --

      You laugh at me because I am different, I laugh at you because you are all the same

      [ Padre ]
  • InnoDB

    (Puntos:0)
    por pobrecito hablador el Sábado, 17 Enero de 2004, 22:47h (#255092)
    Yo mismo no puedo pasar mi aplicación a InnoDB si quiero que la web siga arriba.

    ¿Por qué motivo? ¿Se reduce el rendimiento al pasar las tablas InnoDB? ¿qué problemas tienes? ¿Puedes comentar un poco pros y contras de esto? Gracias.
    [ Padre ]
  • Re:MySQL va a terminar en MyPostgreSQL

    (Puntos:2, Interesante)
    por FidoX (6359) el Domingo, 18 Enero de 2004, 13:09h (#255313)
    ( http://www.corebedigital.com/ )
    A mi el tema de que MySQL sea más rápido que un gestor de bases de datos decente siempre me ha dado un poco de risa.

    Claro que es más rápido, pero porque no tiene que hacer nada. No tiene que comprobar integridad referencial, no tiene que ejecutar procedimientos almacenados, nada.

    Yo tengo un ejemplo claro sobre la "velocidad" de MySQL.

    Tuve que hacer una pequeña página web, un catálogo de productos. Me dió por organizar las familias en forma de árbol multicamino, para que el usuario pudiera escoger la organización de productos que más le guste. Ya lo había hecho antes en firebird.

    La ventaja de hacerlo en firebird fue que al usar integridad referencial, no tuve que programar los métodos de borrado y modifiación de clave primaria. Bastó con un par de triggers para hacer algunas comprobaciones básicas.

    Con mySQL el método de borrado tuve que implementarlo en el cliente. Haciendo SELECT, UPDATES, y DELETES a diestro y siniestro. Estabamos tardando tanto en optimizarlo y depurarlo, que preferimos dejarlo para cuando acabaramos el proyecto.

    MySQL no es rápido. Bueno, la base de datos sí. Pero al no tener lo mismo que tienen otros gestores, quien se vuelve lenta es tú aplicación a la hora de implementar y de ejecutar por tener que estar haciendo cosas que debería hacer el gestor.

    Yo he optimizado consultas que tardaban sobre los 15 min: Yunciones de tablas de cientos de miles de artículos para sacar un informe, simplemente pasando el código del cliente a un SP. Me parece exagerado mandar tablas de un lado a otro de la red, para quedarte al final con unos poco registros. Lo normal sería componer esos registros en el propio gestor y que lo único que se enviara por la red fuera el resultado cosa que hasta ahora no se podía hacer en mySQL

    Por otra parte hay que decir que parece que tiene algunas cosas buenas, es moderna: usa técnica de última generación, está extendida: puedes conseguir proveedores de internet con MySQL por todos lados, pero está claro que no vale para alguien que haya probado un gestor de bases de datos serio. Se echan en falta demasiadas cosas.

    De cualquier forma en cuanto pueda probaré esa versión a ver si ha mejorado algo.
    --

    Israel E. Bethencourt
    FidoX/CORE

    [ Padre ]