Base de datos MySQL

[Yumichan]

Oracle&otras: Para esos casos también puedes tirar del EXPLAIN PLAN o la sintaxis de turno del gestor en consola, y con MySQL pasa lo mismo como la BBDD tenga muchas tuplas. Una vez no cabia en el /tmp uno de los .MSI temporales de MySQL con una query tocha por despiste: la culpa no es del gestor, es tuya

Con PostgreSQL también es C&P las BBDD (y del gestor XD), de hecho me gusta mas postgresql que esta otra ÑU (en parte porque la usé mas ) ... uso mysql si me lo imponen.

MSSQL no lo conozco asi que ahi no digo nada. Es mas, no he visto un proyecto que la use en la puta vida , todos los clientes van a Oracle o ÑU.

@Guibuu (NOT tablas separadas => inscripciones arcanas)

[Reboot]

La mayoría de programas de gestión de farmacia, por alguna razón que no alcanzo a comprender, usan MSSQL. Por eso estoy familiarizado con ella -_-

[Guibuu]

Vale, muchas gracias a todos, veo que hay nivel en el foro :)
Soy un n00b en el tema, os usaré bastante cuando me quede con dudas después de buscar algo que no entienda.

Otra duda que tengo es: ¿por qué usar VARCHAR para almacenar valores como el nombre de un usuario en lugar de TINYTEXT? ¿Por cuestión de espacio? ¿Podría decirse entonces que TINYTEXT === VARCHAR(255)?
Es decir, si quiero almacenar nombres de hasta 32 caracteres, como "Paco", ¿qué ocupa menos, VARCHAR(32) o TINYTEXT?


Estuve leyendo esta página del manual de MySQL (el manual de la versión 5.0, porque usaré MySQL 5.0.67), y tengo entendido que:

• CHAR(M) rellena con espacios a la derecha el hueco que quede: CHAR(8) = "Paco____"
  
• VARCHAR(M) almacena la cadena de texto + un prefijo con el nº de bytes de la longitud de la cadena.
  
• TINYTEXT admite hasta 255 caracteres. Pero no sé si internamente funciona como VARCHAR...

[Yumichan]

A mi me basta el argumento de la portabilidad para usar VARCHAR.
Imagino que en comparaciones y uso de charsets también saldrá ganando VARCHAR pero no he usado nunca TINYTEXT en MySQL.

[Reboot]

Creo recordar que los campos text, ya sean tiny, normal, medium o large tienen la misma consideración que los blob, lo que conlleva una penalización a la hora de hacer búsquedas sobre ellos, pues son datos que no están en la tabla, sino aparte. Son campos para recuperar, no para buscar en ellos.

Por ejemplo, si quieres meter ficheros en la base de datos, se usan los BLOB. Como no vas a buscar nada en el campo, te viene de perlas, pues la base de datos usará lo que hay en la tabla para hacer las búsquedas y luego te recuperará el BLOB (o el TEXT) aparte.

[Reaper45]

(01-15-2013, 01:35 PM)Guibuu escribió: Es decir, si quiero almacenar nombres de hasta 32 caracteres, como "Paco", ¿qué ocupa menos, VARCHAR(32) o TINYTEXT?

Si almacenas ese dato en particular, como varchar te ocupará 4. La teoría sobre el varchar es que aprovecha mejor el espacio sobre datos de tamaño variable. Tinytext u otros ocuparán en el disco duro el máximo de bytes necesarios para representar su rango de datos. No es que esto signifique que las búsquedas sean más rápidas.

Sobre los criterios para elegir el tipo de datos, no sabría decirte. Hay cosas bastante claras, como que por ejemplo para números de teléfono, que tienen siempre el mismo número de caracteres, eliges char(9).

MySQL es lamentable a la hora de tener chorrocientos users conectados, que probablemente no sea tu caso. Pero es gratix y a las empresas eso les gusta, luego si la BD va mal es culpa del programador que ha hecho lo indecible para optimizar consultas.

[Guibuu]

Si TINYTEXT, ocupase el máximo le quitaría el trabajo a CHAR, y un único LONGTEXT ocuparía... varios GB D:

Hey, lo de CHAR(9) para los números de teléfono no está nada claro. Por ejemplo, conozco un edificio de viviendas cerca de Cuatro Caminos (Madrid) que fue diseñado para ser hotel, pero acabó construyéndose como edificio de apartamentos, y cuando quieres hablar con alguien que vive allí, tienes que marcar el número de teléfono de 9 dígitos, esperar a que te conteste en centralita el conserje, decirle "hola buenos días, páseme con el segundo B/con Pepito Pérez" y esperar a que te conecte. Totally from the past. Otro caso menos extremo sería un número de oficina con extensión. Y otro caso es el de los números de teléfono deletreados, que en España no se estilan mucho. De hecho solo me viene a la cabeza el caso hace unos años de 9000CANAL para el Canal de Isabel II.

Y de todas formas, si solo fueras a introducir un número de 9 dígitos, ¿no sería mejor usar INT(9) UNSIGNED en vez de CHAR(9)?

---

Si quisiera hacer los campos "nombre" y "apellidos" a prueba de nobleza, para que no se truncaran, tendría que hacerlos de al menos...
Nombre: Felipe Juan Froilán de Todos los Santos (39 caracteres)
Apellidos: de la Concepción Sáenz de Tejada y Fernández de Bobadilla (57 caracteres)

La nobleza siempre jodiendo xD

[Yumichan]

PostgreSQL es gratix! y es ÑU y te lo puedes compilar...

@Guibuu varchar de al menos 19: "+" prefijo inter. + " " + numero + " " + extension 4, o quivalente, si quieres parsearlo fácilmente para saber "qué es".

@"No es que esto signifique que las búsquedas sean más rápidas."
http://dev.mysql.com/doc/refman/5.5/en/blob.html (y TEXT)

[Reaper45]

(01-15-2013, 05:54 PM)Guibuu escribió: Si TINYTEXT, ocupase el máximo le quitaría el trabajo a CHAR, y un único LONGTEXT ocuparía... varios GB D:

¿Cómo? Mi no entender. Lo de los télefonos, era sólo un ejemplo que ni me había pensado demasiado.

(01-15-2013, 06:16 PM)Yumichan escribió: @"No es que esto signifique que las búsquedas sean más rápidas."
http://dev.mysql.com/doc/refman/5.5/en/blob.html (y TEXT)

TL;DR, plz.

[Yumichan]

Gánate las alas

TL to explain en función de quien escuche. Ni le puse la sintaxis a Guibuu en el 1º post, ni voy a explicar algo que está en el manual oficial-> tipos -> blob y text.