+- Foros de Anime Underground (https://foro.animeunderground.es)
+-- Foro: Ayuda (https://foro.animeunderground.es/forumdisplay.php?fid=11)
+--- Foro: SAT (https://foro.animeunderground.es/forumdisplay.php?fid=13)
+--- Tema: Base de datos MySQL (/showthread.php?tid=5663)
RE: Base de datos MySQL - Reaper45 - 01-15-2013
Pues a la mierda, no pienso hacer eso fuera del trabajo.
RE: Base de datos MySQL - EmuAGR - 01-16-2013
(01-15-2013, 05:54 PM)Guibuu escribió: 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.
¿Es que 9000CANAL no tiene cinco símbolos? CANAL = 22625, luego es 900022625.
RE: Base de datos MySQL - Guibuu - 01-16-2013
Ya, de hecho se explica en el enlace. Lo mencioné como ejemplo de número de teléfono que hipotéticamente podría almacenarse como otra cosa que no fueran 9 números.
RE: Base de datos MySQL - Reboot - 01-16-2013
(01-15-2013, 07:27 PM)Reaper45 escribió: Pues a la mierda, no pienso hacer eso fuera del trabajo.
Joder, lo he explicado en mi post anterior. BLOB y TEXT no son campos optimizados para buscar, sino para recuperar. Lo que guardan en la tabla son punteros de forma que separan los datos buscables de la tabla con los datos recuperables del campo BLOB o TEXT y así agilizan la búsqueda de los índices.
Te estás volviendo un vago de cuidao >_<
RE: Base de datos MySQL - Reaper45 - 01-16-2013
Psé. Las BDs nunca han sido santo de mi devoción y pensé que podría echar un cable.
RE: Base de datos MySQL - Juzz - 01-16-2013
Respondiendo a la pregunta inicial, plantea los datos que vas a guardar.
Si por cada dato (ID del contacto, por ejemplo) vas a tener 1 solo dato (código postal, por ejemplo) --> misma tabla
Si por cada dato (Id del contacto, por ejemplo) vas a tener más de un dato (telefonos) --> telefono +id del contacto en otra tabla (más descripción del telefono u lo que necesites)
Esto es Normalizar una BD, es sencillo, solo tienes que tener claras las relaciones de los datos.
Si lo metes todo en 1 tabla y no normalizas, tendrás que modificar esa tabla cada vez que quieras ampliar datos (un teléfono mas) y tendrás q cambias las TSQLs para que recoja el nuevo campo.
Sobre el tipo de campo a usar:
si no vas a sumar restar, multiplicar, dividir, buscar maximos o minimos, no utilices un campo numérico.
si vas a buscar por datos parciales dentro del campo (que el codigo postal empieze por 28, por ejemplo), utiliza de tipo texto
no vas a tener millones de registros, así que si te ocupan unos pocos más KBs la BD te va a dar igual...
RE: Base de datos MySQL - Incógnito - 01-17-2013
![[Imagen: cande.jpg]](http://4.bp.blogspot.com/_i0JHtA5skM4/TBlB3Iw4DsI/AAAAAAAAABQ/G_TljDFQAV8/s1600/cande.jpg)
RE: Base de datos MySQL - Reboot - 01-17-2013
Y Dios creó los 256 caracteres para que los programadores no tuvieran que liarse con nombres crípticos de 8.
PD: Yo a las keys las suelo prefijar con ID_[Tabla]
PD2: En vez de usar una tabla para los emails, puedes usar tu tabla "contel" y "telefonos" para meterlo.
RE: Base de datos MySQL - Yumichan - 01-17-2013
Yo siempre las llamo a todas las PK igual (si no son multiples) por epicpal, C&P, y epicpal+ al hacer joins. "id", "cod" o segun la nomenclatura que use el proyecto. Ya va explicado el nombre y apellidos en la constraint.
Pero esto es como el punto de sal...
RE: Base de datos MySQL - Guibuu - 01-17-2013
Gracias Juzz y el resto. Estoy decidiendo cómo organizo los datos en tablas gracias a vuestros consejos, y a la vez estoy dándole vueltas a la interfaz gráfica (HTML haciendo uso de Bootstrap y PHP, y conectándome a la base de datos mediante el driver PDO).
Y como no soy experto en nada de eso y a esto le puedo dedicar menos tiempo del que querría, avanzo a ritmo de anciana con andador...
PD: Sublime Text mola.