Mensajes: 5,771
Registro en: Sep 2009
Reputación:
27
01-15-2013, 11:36 AM
(Este mensaje fue modificado por última vez en: 01-15-2013, 11:43 AM por 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 ![Y32b4 Y32b4](https://foro.animeunderground.es/images/smilies/y32b4.gif) , todos los clientes van a Oracle o ÑU.
@Guibuu (NOT tablas separadas => inscripciones arcanas)
Mensajes: 8,966
Registro en: May 2007
Reputación:
149
![@KMHG](images/social_twitter.png)
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 -_-
"Es como el que se mataba a pajas con U-jin y hoy en día o es Boku no Piko o ni se le levanta." - AniList
Mensajes: 3,869
Registro en: Jun 2007
Reputación:
119
![Guibuu](images/social_twitter.png) ![guibuu](images/social_steam.png)
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...
Mensajes: 5,771
Registro en: Sep 2009
Reputación:
27
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.
Mensajes: 8,966
Registro en: May 2007
Reputación:
149
![@KMHG](images/social_twitter.png)
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.
"Es como el que se mataba a pajas con U-jin y hoy en día o es Boku no Piko o ni se le levanta." - AniList
Mensajes: 4,185
Registro en: Aug 2009
Reputación:
50
01-15-2013, 05:16 PM
(Este mensaje fue modificado por última vez en: 01-15-2013, 05:18 PM por 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.
Mensajes: 3,869
Registro en: Jun 2007
Reputación:
119
![Guibuu](images/social_twitter.png) ![guibuu](images/social_steam.png)
01-15-2013, 05:54 PM
(Este mensaje fue modificado por última vez en: 01-15-2013, 06:08 PM por 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
Mensajes: 5,771
Registro en: Sep 2009
Reputación:
27
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)
Mensajes: 4,185
Registro en: Aug 2009
Reputación:
50
(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.
Mensajes: 5,771
Registro en: Sep 2009
Reputación:
27
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.
|