Mensajes

De la forma como lo sugieres Azielito, suena como a desampararlo y abandonarlo solo por su cuenta 

Sobre lo de VARCHAR vs CHAR es relativo Pazador    no quiero insistir o obligar a siempre usar CHAR porque habran veces que necesitaras VARCHAR en vez de CHAR. Ya que al menos en los motores de base de datos que conozco, CHAR tiene un soporte menor de caracteres que VARCHAR (CHAR tiene un maximo de 255 caracteres).

Tanto CHAR como VARCHAR son casi lo mismo, su unica diferencia radica en como almacenan, retornan y la cantidad maxima de caracteres a guardar. Si estas seguro que siempre vas a insertar un registro de una longitud fija, procura usar CHAR (Por ejemplo Nombres, Apellidos, Direccion, etc) Pero si vas a almacenar registros donde desconoces la longitud que este tomara (Por ejemplo mensajes en un foro, mensajes en un libro de visitas, etc) La preferencia seria en este caso VARCHAR. Sobretodo porque VARCHAR como te decia tiene una longitud mucho mayor de almacenamiento de datos que CHAR, y sino sabes a ciencia cierta el tamaño exacto de caracteres que se insertara en cierto campo pues usas VARCHAR.

Todo depende para que requieras guardar datos, asi sabras que tipo de datos utilizar. Lo que no puedes hacer es asignarle VARCHAR a todo (fecha, numeros, caracteres, etc) procura que cada campo vaya acorde al tipo de dato real guardado para este en memoria.

De Acuerdo con Kasswed         

[withdraw()]

Eso que llamas "Marco Ventana" no es mas que la ventana principal de tu proyecto (MainWindow o Form si haz programado en VB), y el DialogBox es un hijo de esta ventana :

tkMessageBox.showwarning

Yo no programo en Python/Tk pero si he trabajado con Perl/Tk (Por ende con el API Tk como tal), que funciona similar ya que las funciones del Api son similares independientemente del lenguaje que le use.

Averiguate, sobre la funcion withdraw() que sirve para ocultar el MainWindow en Tk, y busca la forma de validar que sea nuevamente mostrada (funcion raise()) justo cuando se cierren todos los DialogBox.

BenchMarks :

Ya que algunos usuarios tendran la duda de como testear el rendimiento de sus respectivas Base de Datos. Hago incapie a MySQL Becnhmark Suite, suelo generalmente descargar las nuevas fuentes de MySQL desde su website ya que esta incluye el Benchmark, para personas tan relacionadas con PERL como yo    esto queda como anillo al dedo:

Fuente:  http://dev.mysql.com/doc/refman/5.0/es/mysql-benchmarks.html

7.1.4. El paquete de pruebas de rendimiento (benchmarks) de MySQL

Esta sección debería contener una descripción técnica del paquete de pruebas de rendimiento de MySQL (así como del crash-me), pero esa descripción aún no ha sido escrita. Sin embargo, puede hacerse una buena idea de cómo hacer pruebas de rendimiento viendo el código y los resultados dentro del directorio sql-bench en el código fuente de la distribución de MySQL.

La finalidad de este paquete de pruebas de rendimiento es visualizar qué operaciones se realizan bien y cuáles lo hacen pobremente en cada implementación de SQL.

Estas pruebas de rendimiento no son multi hilo, así que miden el tiempo mínimo para las operaciones realizadas. Se planea agregar en un futuro pruebas multi hilo al paquete.

Para usar el paquete, deben satisfacerse los siguientes requisitos:

    *

      El paquete de pruebas de rendimiento se proporciona con el código fuente de la distribución de MySQL. También puede descargar una distribución liberada de http://dev.mysql.com/downloads/, o usar nuestro repositorio de código fuente(ver Sección 2.8.3, "Instalar desde el árbol de código fuente de desarrollo").
    *

      Los scripts de las pruebas de rendimiento están escritos en Perl y usan el módulo de Perl DBI para acceder a los servidores de bases de datos, así que DBI debe estar instalado. También es necesario el controlador DBI específico para cada servidor al que se quiere realizar las pruebas. Por ejemplo, para probar MySQL, PostgreSQL, y DB2, debe tener los módulos DBD::mysql, DBD::Pg, and DBD::DB2 instalados. Ver Sección 2.13, "Notas sobre la instalación de Perl".

Una vez obtenido el código fuente de la distribución de MySQL, el paquete de pruebas de rendimiento se encuentra en el directorio sql-bench. Para ejecutar las pruebas de rendimiento, compílese MySQL, váyase al directorio sql-bench y ejecútese el script run-all-tests:

shell> cd sql-bench
shell> perl run-all-tests --server=nombre_servidor

nombre_servidor debe ser uno de los servidores soportados. Para obtener la lista completa de opciones y servidores soportados, invóquese el comando:

shell> perl run-all-tests --help

El script crash-me también está situado dentro del directorio sql-bench. crash-me intenta determinar qué características soporta una base de datos y cuáles son sus capacidades y limitaciones. Esto lo consigue ejecutando consultas. Determina por ejemplo:

    *

      Cuáles tipos de columnas se soportan
    *

      Cuántos índicies se soportan
    *

      Qué funciones se soportan
    *

      Qué tamaño puede alcanzar una consulta
    *

      Que tamaño puede alcanzar una columna VARCHAR

Para más información acerca de resultados de pruebas de rendimiento, visítese http://dev.mysql.com/tech-resources/benchmarks/.

Para obtener scripts en otros lenguajes scripting como Python por ejemplo, pueden obtener algunos del blog de Mark Callaghan

http://mysqlha.blogspot.com/2009/02/code-for-benchmarking.html

Tambien si quieren medir rendimiento tanto en MySQL como otras Base de Datos:

http://osdb.sourceforge.net/index.php?page=home

Hola Anarquista  

Aunque no entiendo en su totalidad el objetivo de tu peticion. Te digo ya tienes tus 2 entidades definidas (empleados y departamento).

Efectivamente, 1 empleado pertenece a un unico departamento (Aunque he visto empresas donde pertenecen a varios juas   ), Mientras 1 departamento tiene de 1 a varios empleados. El analisis de cardinalidad en este caso seria:

para Empleados (1,1)
para Departamento (1:N)

Basado en lo anterior, para mi percepcion personal lo veo como una cardinalidad de varios a uno (N:1), por la razon de que una entidad de la tabla empleados solamente se puede relacionar exclusivamente con una entidad en la tabla departamentos, pero una entidad de la tabla departamentos se puede relacionar con 1 o varias entidades de la tabla empleados, por ende aca deberias utilizar la llave primaria definida de la tabla empleados para hacer la relacion.

Aunque me puedo equivocar, nunca me han gustado mucho la teoria ni los diagramas de entidad relacion.

[Memcached: un alivio para las bases de datos]

Memcached: un alivio para las bases de datos

Cuando la performance de un sistema web se torna crítica y el tiempo de respuesta puede quedar afectado por las numerosas visitas simultáneas, debemos echar mano a herramientas “poco convencionales”, este es el caso de Memcached.
¿Qué es Memcached?
Memcached es definido por Danga Interactive, la empresa que lo desarrollo y mantiene el proyecto bajo licencia BSD como un “sistema distribuido de alta performance para el cacheo de objetos en memoria, genérico por naturaleza, pero pensado para incrementar la velocidad de aplicaciones web dinámicas, aliviando la carga de las bases de datos”.
La idea es muy simple y a la vez muy efectiva: un servicio que escucha en un host y un port específico, que puede almacenar cadenas de bytes (strings). De esta manera, podríamos estar guardando en memoria una estructura serializada de PHP o Java, un string encodeado con Json, o un documento de cualquier formato (después de todo no dejan de ser cadenas de bytes).
Existe actualmente una implementacion de Memcached Server que corre en Win32. Si bien no es oficial, cuenta con el apoyo de varios desarrolladores de la comunidad.
Funcionamiento
A grandes rasgos, el Memcached Server almacena los strings (internamente denominados ítems), en una gran tabla de hash, y los mapea según la clave que le asociemos a dicho ítem.
Dicha tabla de hash adopta una estructura de porciones de memoria de tamaño variable (denominadas slabs), con el objetivo de optimizar la asignación del espacio de memoria.
Un dato no menor es el slab de mayor tamaño (1 Mb), siendo este por consiguiente el tamaño máximo que un ítem puede tener si quiere ser almacenado en Memcached Server (aunque este valor puede ser modificado desde el código fuente).
Su arquitectura escalable nos permite mantener un pool de Memcached servers, característica que bien puede ser explotada en momentos donde la cantidad de conexiones no puede ser gestionada por un único Server. En ese caso, el pool optará por otro Server, balanceando la carga de conexiones.
Protocolo
La comunicación de clientes con servidor es muy simple, y basada en comandos. El protocolo Memcached implementa 3 comandos de almacenamiento, con pequeñas diferencias en su funcionamiento:
SET: Actualiza el objeto si no existía anteriormente, o lo agrega en caso contrario.
ADD: Agrega el objeto solo si no existe.
REPLACE: Actualiza el objeto solo si existe.
Memcached permite controlar el tiempo de vida de un objeto, indicando el “tiempo de expiración” para el mismo, en el momento de realizar una operación de almacenamiento.
A su vez, posee un comando de recuperación: GET. Podemos eliminar un objeto mediante el comando DELETE. Además, el protocolo implementa comandos para recuperar estadísticas, vaciar el cache, utilizar algún tipo de compresión, entre otros.
Ejemplo de uso
<?php

// Inicializamos y conectamos
$memcache = new Memcache;
$memcache->connect('localhost', 11211) or die("No podemos conectarnos");

// Creamos una estructura a cachear
$pichongol = new stdClass;
$pichongol->nombre = “Daniel”;
$pichongol->apellido = “Lopez”;

// Almacenamos la estructura con una expiracion de 10 segundos
$memcache->set(“pichongol”, $pichongol, false, 10) or die ("No podemos guardar la estructura");

// Recuperamos la estructura
$result = $memcache->get(“pichongol”);
echo "Estructura recuperada:<br/>\n";
print_r($result);

?> 
¿Quiénes usan Memcached?
El desarrollo inicial y sus posteriores mejoras nacen como una necesidad de incrementar velocidades de respuesta para las peticiones web, en sitios de tráfico masivo.
Actualmente, su uso continúa expandiéndose, a medida que el proyecto toma mayor fuerza con la ayuda de varios desarrolladores de la comunidad Open Source que revisan y agregan nuevas capacidades al proyecto.
La siguiente es una lista acotada de sitios que actualmente utilizan Memcached para resolver cuestiones de escalabilidad:
LiveJournal
Memcached nace como un desarrollo para el backend de LiveJournal, y como tal, es el primer sitio que lo implementa.
Slashdot
Wikipedia
Fotolog
Luego de tener ciertas falencias de performance (producto de tener que manejar en promedio, de 35 a 40 millones de page views diarios) implementaron Memcached, logrando una gran mejoría en la prestación del servicio.
Hi5
Facebook
Contribuyó al proyecto, aportando muchas mejoras relacionadas con el manejo de memoria y los algoritmos de hashing, principalmente. Es actualmente la mayor implementación conocida, compuesta de alrededor de 200 servers de 1GB de memoria cada uno.

Conclusión
Memcached y escalabilidad van de la mano, y todos podemos sacar jugo de esta interesante herramienta. Nuevamente se demuestra que las ideas brillantes son simples por naturaleza.

Fuente:  http://www.maestrosdelweb.com/editorial/memcached-un-alivio-para-las-bases-de-datos/

Honestamente, no se si solo sea yo, pero el subforo de Base de Datos pasa visualmente casi inexistente. Es como si los que mas se enterasen de su existencia sean solo los usuarios que entran al foro 'Desarrollo Web' pero visualmente, como subforo y el no estar en negrita casi no se ve.

Y he visto ocasiones despues del subforo DB existir, usuarios preguntando cosas relacionadas a Base de Datos en foros de programacion (No en el foro Desarrollo Web) y creo que es precisamente porque no saben todavia de la existencia de este subforo que esta un poco escondido visualmente hablando.

ya que la ATOMICIDAD de una transaccion garantiza que los datos se guarden de manera correcta o no se guarden y no por partes como seria lo que supones, en caso de suceder es un problema de la transaccion mas no del tipo de dato

Ahora que haces mencion de ello, me surge la duda. Hice dicha referencia ya que como VARCHAR es de longitud variable, no se termina de realizar una transaccion por alguna razon imprescindible, y supongamos que mi motor es transaccional pero tiene activado el autocommit  por ende se escribira en disco el cambio automaticamente sea o no correcto, pero como se escribira? sino se completo la informacion transferida, y tampoco se completa la longitud del dato con espacios como ocurriria en CHAR.... esto va a corromper de alguna u otra manera la info escrita en disco. Tendre que hacer un pequenio escenario de prueba personal para confirmar esta creencia.

Para la suposicion que mencionas de la corrupcion para el campo varchar no es dable, ya que la ATOMICIDAD de una transaccion garantiza que los datos se guarden de manera correcta o no se guarden y no por partes como seria lo que supones, en caso de suceder es un problema de la transaccion mas no del tipo de dato, si un motor de base de datos no puede manejar eso es un desastre transaccionalmente hablando..

Efectivamente era una suposicion personal, no puedo darte una afirmacion concreta del porque esta afirmacion esta tan difundida (Sobre el poco soporte de corrupcion en tipo de datos varchar exclusivamente) no solo la gente de MySQL lo confirman, he visto referencia de lo mismo en el foro principal de la web de Oracle (Aunque ahora mismo no puedo buscarte y pegarte la referencia, pero anteriormente la he visto). Y ambos son lugares oficiales. Una razon bastante fuerte ellos han de tener para reafirmar que los registros dentro de tipo de datos varchar pueden corromperse por la poca resistencia ante fallos que posee el tipo de dato varchar como tal (esto es independiente del motor en cuestion del que hablamos).

Ahora, ya que haces una fuerte referencia sobre la garantia de atomicidad que debe ofrecerme un motor en cuestion por ser transacional, yo te pregunto en un valor declarado como VARCHAR (10) tu considera este valor atomico cuando se puede descomponer la cadena en caracteres individuales? Atomicidad de Valor de los datos (No del motor de almacenamiento que lo gestiona) por sí mismo no es un criterio objetivo y no tiene ningún significado absoluto. Yo creo mas que depende como vayas a tratar los datos, la atomicidad puede tener muchas interpretaciones distintas, pero un motor no puede asegurarme 100% atomicidad cuando posee por ejemplo un tipo de dato varchar (con las caracteristicas antes mencionadas por mi) porque si fuesen 100% atomicos ninguna tabla se corrompiese jamas. Es cierto que tienen mas soporte a fallas y corrupciones si son motores transaccionales, pero no son 100% garantizables, tambien influyen los tipos de datos y como estos funcionan para si mismos.