Menú

Mostrar Mensajes

Esta sección te permite ver todos los mensajes escritos por este usuario. Ten en cuenta que sólo puedes ver los mensajes escritos en zonas a las que tienes acceso en este momento.

Mostrar Mensajes Menú

Mensajes - WHK

#1191
Bases de Datos / Re: Trigger sencillo MySQL
30 Junio 2015, 23:40 PM
Al reino no le pasa nada porque la relación la tiene el registro del personaje, si quisieras que se elimine el reino deberías entonces hacer una relación en la tabla de reinos.
#1192
Cita de: engel lex en 29 Junio 2015, 20:22 PM
a demás WHK la sacas todas y tienes que tener muy buena memoria para saber donde ponerlas de vuelta, porque a demás no podrás buscar en internet, porque tu teclado estará desarmado

Lo que yo hago es desarmar el teclado y separar las teclas del plastico con los conductores, luego lo doy vuelta y quedan solamente las teclas con las gomitas, luego limpio la superficie de plastico con los conductores y cada punto de cada tecla y luego tomo toda slas gomitas y las lavo o las soplo y luego saco cada tecla una por una y la limpio y la dejo en su lugar, no necesitas sacarlas todas de una ves, a veces me queda una que otra tecla dado vuelta hacia abajo pero es lo de menos, la das vuelta nuevamente y ya xd
#1193
Cita de: Spectatorem en 29 Junio 2015, 19:51 PM
Donde se pueden conseguir eso?

En chile en casi cualquier tienda que vendan articulos de computación, en otros paises tambien los venden desde hace varios años:

http://www.amazon.com/s/?url=search-alias%3Daps&field-keywords=silicone+keyboard&rh=i%3Aaps%2Ck%3Asilicone+keyboard



De todas maneras los he probado y son un poco incómodos porque tienes que presionar bien cada tecla y no sientes cuando una tecla es presionada o no como uno mecánico.

Yo en lo personal limpio mi teclado sacandole tecla por tecla o si no me compro uno nuevo



Lo bueno de los teclados de cilicona es que resisten los derrames, no como un mecanico:





A menos que tengas una mascota así:

#1194
Hay teclados que no necesitas desmontar para limpiar:

#1195
Tu necesitas una vista, no una función.

CREATE VIEW mi_vista AS SELECT columna_1, columna_2 FROM tabla;

Luego cada ves que hagas un select * from mi_vista vas a retornar la consulta "SELECT columna_1, columna_2 FROM tabla".
#1196
Bases de Datos / Re: Solucion BD en empresa
29 Junio 2015, 15:55 PM
Esta respuesta dependerá mucho de la cantidad de usuarios que manejará tu app, si la cantidad excede los 5 mil usuarios en linea de manera simultanea necesitas una base de datos oracle y aplicaciones de codigo nativo sin framework para android e ios, si la empresa es una sola entonces dependerá de la marca y modelo del celular. En este sentido hablamos de millones de registros. Si es así entonces necesitarás mas de un servidor y balanceo de carga dependiendo del volumen aproximado de usuarios. Del lado del servidor necesitarás programar en java, c# MVC 5 o superior o python sobre un servidor Redhat.

Si no lo usarán tantos usuarios entonces bastará con una base de datos MySQL si te manejas bien o si no postgre sql o si no mongodb dependiendo de las habilidades de tu programador. Del lado del servidor podrás usar php con codeigniter o python, rubi on rails y un servidor Centos 6 o 7.

En ambas situaciones necesitarás hacer una base de datos relacional desnormalizada en un servidor vps o dedicado.

Los archivos jamás los almacenes en la base de datos o aumentarás significativamente la carga en el servidor y no podrás sustentar tantos usuarios, en ese caso necesitarás un NAS o un CDN, esto quiere decir que los archivos deben ser almacenados en un directorio en un servidor y desde la base de datos guardar el id de ese archivo o nombre del archivo nada mas, te recomiendo hacer una estructura de hashses, por ejemplo facebook hace un tiempo puso un microtime o time unix stamp como nombre de archivos en las imagenes mas un numero al azar para prevenir repeticiones , luego tomas este valor y lo guardas en tu base de datos y le adjuntas el nombre original en otra columna de la misma fila en la tabla, jamás les pongas los nombres originales a los archivos o tendrás problemas de seguridad.

Si es una aplicación para una empresa que maneje datos confidenciales entonces no le dejes el trabajo a alguien que está recien comenzando a aprender, si es un trabajo personal para ti que quieres vender entonces puedes usar a quien quieras pero si es para tu empresa entonces no.

Jamás des datos reales para realizar la aplicación, siempre usa valores de prueba. Esto es parte de la privacidad de datos y confidencialidad de tus productos, carteras y/o usuarios.

Eso es todo lo que te puedo recomendar.

Saludos.
#1197
Bases de Datos / Re: Trigger sencillo MySQL
29 Junio 2015, 15:41 PM
Pues MySQL con el motor innodb están diseñados para ese tipo de trabajo de manera automática y no, no siempre se debe poner on cascade, debes tomar cada relación y pensar bien que debería suceder cuando se elimina o actualiza un registro, la mayoría de las veces son on cascade, eso si, pero no siempre es así, hay veces que necesitas establecer a null, yo en lo personal nunca he utilizado el restringir el valor o la fila, siempre uso cascade o set null dependiendo del caso, en el caso de una tabla relacional de muchos a muchos si es necesario hacerlo con cascade y no necesitarás triggers, de hecho de mis años programando jamás he necesitado utilizar triggers o funciones procedure, de hecho intento jamás usarlos ya que dejo ese trabajo de calculo al lenguaje de programación del lado del código y no de la base de datos ya que cuando necesitas hacer un flujo de una aplicación, documentarla y llevar un cierto orden no puedes dejar toda la lógica desparramada entre la base de datos y el código, para mi la base de datos es base de datos y el calculo de recoger y buscar datos se lo dejo al código y libero la carga del servidor (útil cuando trabajas con separación de capas).

Mira esto:

Código (sql) [Seleccionar]
-- MySQL Workbench Synchronization
-- Generated: 2015-06-29 10:30
-- Model: New Model
-- Version: 1.0
-- Project: Name of the project
-- Author: WHK

SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0;
SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0;
SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='TRADITIONAL,ALLOW_INVALID_DATES';

CREATE TABLE IF NOT EXISTS `blank`.`personaje` (
  `id` INT(11) NOT NULL AUTO_INCREMENT,
  `nombre` VARCHAR(256) NOT NULL,
  `reino_id` INT(11) NULL DEFAULT NULL,
  PRIMARY KEY (`id`),
  INDEX `fk_personaje_reinos_idx` (`reino_id` ASC),
  CONSTRAINT `fk_personaje_reinos`
    FOREIGN KEY (`reino_id`)
    REFERENCES `blank`.`reinos` (`id`)
    ON DELETE SET NULL
    ON UPDATE CASCADE)
ENGINE = InnoDB
DEFAULT CHARACTER SET = utf8
COLLATE = utf8_general_ci;

CREATE TABLE IF NOT EXISTS `blank`.`reinos` (
  `id` INT(11) NOT NULL AUTO_INCREMENT,
  `nombre` VARCHAR(256) NOT NULL,
  PRIMARY KEY (`id`))
ENGINE = InnoDB
DEFAULT CHARACTER SET = utf8
COLLATE = utf8_general_ci;


SET SQL_MODE=@OLD_SQL_MODE;
SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS;
SET UNIQUE_CHECKS=@OLD_UNIQUE_CHECKS;


En esta base de datos tienes personaje y reinos y la tabla de personajes tiene una columna con el id de reino, esto quiere decir que el personaje va a pertenecer a un solo reino o ninguno, por este motivo el valor por defecto es null, ahora, este valor tiene una acción de cascade cuando se actualiza el registro o set null cuando se elimina... como funciona esto?:

Cuando se actualiza el registro del reino entonces se actualiza tambien el valor en la fila del personaje, pero que pasa si eliminas el reino? si le pones cascade se va a eliminar el personaje, por eso lo estableces a null, ahora, si necesitas que el personaje siempre tenga un reino entonces le das la opcioon de bloqueo y restringes la fila, de esta manera no podra usarse el personaje hasta que manualmente le asignes un nuevo reino y no tendras problemas en la selección o actualización de registros.

Ahora, digamos que necesitas que el personaje pueda estar en mas de un reino asociado:

Código (sql) [Seleccionar]
-- MySQL Workbench Synchronization
-- Generated: 2015-06-29 10:35
-- Model: New Model
-- Version: 1.0
-- Project: Name of the project
-- Author: WHK

SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0;
SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0;
SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='TRADITIONAL,ALLOW_INVALID_DATES';

CREATE TABLE IF NOT EXISTS `blank`.`personaje` (
  `id` INT(11) NOT NULL AUTO_INCREMENT,
  `nombre` VARCHAR(256) NOT NULL,
  PRIMARY KEY (`id`))
ENGINE = InnoDB
DEFAULT CHARACTER SET = utf8
COLLATE = utf8_general_ci;

CREATE TABLE IF NOT EXISTS `blank`.`reinos` (
  `id` INT(11) NOT NULL AUTO_INCREMENT,
  `nombre` VARCHAR(256) NOT NULL,
  PRIMARY KEY (`id`))
ENGINE = InnoDB
DEFAULT CHARACTER SET = utf8
COLLATE = utf8_general_ci;

CREATE TABLE IF NOT EXISTS `blank`.`personajes_reinos_relacion` (
  `personaje_id` INT(11) NOT NULL,
  `reino_id` INT(11) NOT NULL,
  PRIMARY KEY (`personaje_id`, `reino_id`),
  INDEX `fk_personajes_reinos_relacion_reinos1_idx` (`reino_id` ASC),
  CONSTRAINT `fk_personajes_reinos_relacion_personaje`
    FOREIGN KEY (`personaje_id`)
    REFERENCES `blank`.`personaje` (`id`)
    ON DELETE CASCADE
    ON UPDATE CASCADE,
  CONSTRAINT `fk_personajes_reinos_relacion_reinos1`
    FOREIGN KEY (`reino_id`)
    REFERENCES `blank`.`reinos` (`id`)
    ON DELETE CASCADE
    ON UPDATE CASCADE)
ENGINE = InnoDB
DEFAULT CHARACTER SET = utf8
COLLATE = utf8_general_ci;


SET SQL_MODE=@OLD_SQL_MODE;
SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS;
SET UNIQUE_CHECKS=@OLD_UNIQUE_CHECKS;


En este caso hay una tabla intermedia de muchos a muchos donde un personaje puede estar asociado a mas de un mundo, ahora, si te fijas ambas columnas de esta tablas son llaves, esto quiere decir que no se podrán repetir los mundos con los personajes, esto quiere decir que si hay dos reinos entonces un personaje no podrá tener mas de dos reinos y si intentas asociar un reino por segunda ves la base de datos te arrojará un error diciendo que el registro está duplicado. Esto es súper útil si deseas mantener la integridad de datos de tu aplicación ya que si permites duplicidades vas a tener problemas muy serios al momento de manejar tus datos, esto te restringe en parte a diseñar una buena aplicación.

Si te fijas, en este ejemplo ambas funciones son cascade en ambas columnas ya que si eliminas un personaje o eliminas un reino entonces la relación desaparece, si eliminas un reino el personaje ya no estará asociado a el y eso es lo normal que pase y no que quede un registro fantasma que te diga que pertenece a un reino que no existe.

Bueno.... todo eso lo hace innodb de manera automática e innodb viene integrado por defecto con mysql.

Saludos.
#1198
Bases de Datos / Re: Trigger sencillo MySQL
27 Junio 2015, 23:11 PM
Si es una base de datos relacional con foreign keys entonces vas a tener problemas si no estableces una acción ya que si tienes una tabla de relaciones entre una tabla A y tabla B cuando uno de estos sea eliminado o modificado vas a tener un valor nulo o corrupto en la tabla de relaciones ya que estará apuntando a un registro que ya no existe.

Eso de eliminar una fila cuando un registro de otra tabla es eliminado no se hace a traves de triggers sino con tablas relacinales y foreign keys.

Dale un vistazo a esta base de datos:
http://foro.elhacker.net/bases_de_datos/ayuda_amigo_necesito_crear_una_base_de_datos-t437701.0.html;msg2023594#msg2023594

Todos los puntos de color rojos son llaves foraneas que tienen como acción "cascade" lo cual indica que cuando se elimina o se modifica este tambien debe eliminarse o actualizarse desde la tabla de relaciones.

En algunos casos cuando tienes una tabla con una columna que apunta a otra tabla (de uno a uno) entonces la acción es set null para que el valor se vuelva nulo y no te elimine todo el registro:

CREATE TABLE IF NOT EXISTS `usuarios_telefonos` (
  `usuario_id` INT(11) NOT NULL AUTO_INCREMENT,
  `codigo_pais` INT(11) NOT NULL,
  `codigo_ciudad` INT(11) NOT NULL,
  `numero` INT(11) NOT NULL,
  `es_fijo` TINYINT(1) NOT NULL DEFAULT 0,
  PRIMARY KEY (`usuario_id`),
  CONSTRAINT `fk_usuarios_telefonos_usuarios1`
    FOREIGN KEY (`usuario_id`)
    REFERENCES `usuarios` (`id`)
    ON DELETE CASCADE
    ON UPDATE CASCADE)
ENGINE = InnoDB
DEFAULT CHARACTER SET = utf8
COLLATE = utf8_general_ci;


#1199
Ese no es problema de la base de datos, intenta hacer el insert y el select desde el terminal y verás que tengo razón ya que una base de datos utf8_* debería soportar caracteres especiales latinos.

Tu problema está en el script que muestra el valor que guardaste o el que guarda el valor escrito, recuerda que no basta solamente con tener un archivo con codificación utf8, es necesario establecer cabeceras de tipo header http y html. O si no puede ser que tu conexión a la base de datos no sea por defecto utf-8 (eso pasa cuando instalas distribuciones en español):

https://foro.elhacker.net/desarrollo_web/inquietud_por_que_utf8_no_exporta_tildes_y_iso88591_si-t420426.0.html;msg1962508#msg1962508
#1200
Bases de Datos / Re: Trigger sencillo MySQL
27 Junio 2015, 20:06 PM
Debes tener un conflicto en tu tabla, tendriamos que ver la estructura completa de tu base de datos para saber porque se está bloqueando. Por ejemplo talves tienes una acción on delete que hace una llamada recursiva infinita, me ha pasado varias veces y pars solucionarlo debo crear tablas intermedias o eliminar una acción.