duda sobre estructura BD

machtcom · #1 (**permalink**) 24/09/2009, 12:55

Hola ha todos,

Antes de plantear mi problema deciros que soy novato en este tema y voy aprendiendo sobre la marcha y es de agradecer toda la ayuda posible. Realicé una web con dreamweaver y es una web muy bonita sobre diseño, pero muy poco funcional en la practica, no tiene ni tan solo un formulario para que los futuros clientes me envien material para publicar. La cuestión es que he empezado a introducirme en el mundo de mysql para desarrollar toda la parte interna y la idea es crear un formulario de envio de datos los cuales recibiré yo personalmente y poderlos publicar sin mucho esfuerzo. Si lo tengo que realizar yo es porque quiero garantizarme que los datos sean correctos pues es una web para contactos profesionales (escorts) y no quiero que se filtre nada raro, aparte quiero que tenga un poco de calidad. Bueno la cuestion es que estoy en proceso de crear un back office para mi para poder publicar el material y almacenar datos de interes, creación de formulario de envio de datos por parte del cliente y diseño de paginas de resultado, busqueda, etc. Mi duda viene a razon de la BD que estoy empezando a plantearme con mysql. Tengo que publicar datos de las acompañantes las cuales tienen una serie de datos personales... provincia, localidad, fotos y poco más. Me gustaría saber si estoy planteando bien el tema de la relación entre tablas. Mi idea incial es la siguiente:

a) Usuario_id--- el cual se va a dividir entre 1) Agencias
2) Escorts

b) datos_id (primary)--- en el cual voy a introducir todos los datos (edad, medidas,etc)
usuarios_id--- para la relacion.

c) provincia_id-- donde incluire todas las provincias de españa, cada una con su id.
usuario_id--- relación para la localización del usuario y poder hacer busquedas por provincia y localidad.

d) localidad_id-- la cual voy a poner cada una con la provincia-id que corresponda para que tenga una relación directa y pueda crear listados.

e) fotos_id--- donde poder subir las fotografías que me envien
usuario-id--- para la relación y poder mostrar las fotos de cada cliente.

Puede que no sea la mejor manera de mostrar la estructura de la BD. Mi duda es saber si lo estoy haciendo bien y si es así creo que está preparada para en un futuro poner mas tipos de clientes, ahora son agencias y escorts, pero en un futuro quiero poner locales, sexshop...

Si alguien es tan amable y puede decirme alguna cosa se lo agradeceré.

Un saludo a todos.

machtcom · #2 (**permalink**) 25/09/2009, 01:13

Nadie que me pueda ayudar en esta consulta?

huesos52 · #3 (**permalink**) 25/09/2009, 06:47

Una imagen vale mas que mil palabras.

Postea el modelo relacional que has hecho.

saludos

machtcom · #4 (**permalink**) 25/09/2009, 12:07

Pues tienes toda la razón. Monto un tema y lo subo. Gracias.

machtcom · #5 (**permalink**) 25/09/2009, 12:22

No se si te servirá mucho esto huesos52 porque está todavía incompleta. Lo que estoy intentado hacer y vuelvo a repetir que esta incompleta... es:

yo tengo dos tipos de cliente, agencias y escorts de los cuales uno de ellos que es la agencia, puede tener escorts colaborando y por ese motivo tiene que poder dar de alta a sus correspondientes. Los dos pueden tener fotos y los dos puede pertenecer a provincias y localidades. Quiero que cuando se haga una consulta en la web, pueda listar tanto agencias como escorts y que estas ultimas tengan sus filtros. Ahora estoy rompiendome el coco con las provincias y localidades haber como lo hago.

Recordar que soy novato en este tema y la verdad que cualquier ayuda puede ser muy interesante. Gracias.

CREATE TABLE agencia (
agencia_id INT NOT NULL AUTO_INCREMENT,
contraseña VARCHAR(45) NOT NULL,
fecha DATETIME NULL,
PRIMARY KEY(agencia_id)
)
TYPE=InnoDB;

CREATE TABLE datosagencia_id (
datosagencia_id INT NOT NULL AUTO_INCREMENT,
escorts_id INT NOT NULL,
agencia_id INT NOT NULL,
nombre_comercial VARCHAR NULL DEFAULT 100,
titulo VARCHAR NULL DEFAULT 65,
descripcion TEXT NULL DEFAULT 255,
per_contacto VARCHAR NULL DEFAULT 50,
nom_fiscal VARCHAR NULL DEFAULT 50,
nif VARCHAR NULL DEFAULT 20,
calle_fiscal VARCHAR NULL DEFAULT 50,
numero VARCHAR NULL DEFAULT 5,
piso VARCHAR NULL DEFAULT 2,
puerta VARCHAR NULL DEFAULT 3,
escalera VARCHAR NULL DEFAULT 2,
codigo_postal INTEGER UNSIGNED NULL,
fijo_1 VARCHAR NULL,
fijo_2 VARCHAR NULL,
movil_1 VARCHAR NULL,
movil_2 VARCHAR NULL,
correo VARCHAR NULL,
web VARCHAR NULL,
edad INT NULL,
nacionalidad VARCHAR NULL,
medidas VARCHAR NULL,
altura VARCHAR NULL,
peso VARCHAR NULL,
apartamento VARCHAR NULL,
desc_apartamento TEXT NULL,
parking VARCHAR NULL,
metro INTEGER UNSIGNED NULL,
autobus VARCHAR NULL,
reservas VARCHAR NULL,
pago VARCHAR NULL,
PRIMARY KEY(datosagencia_id),
INDEX datosagencia_id_FKIndex1(agencia_id),
INDEX datosagencia_id_FKIndex2(escorts_id)
)
TYPE=InnoDB;

CREATE TABLE escorts (
escorts_id INT NOT NULL AUTO_INCREMENT,
agencia_id INT NOT NULL,
contraseña VARCHAR NULL DEFAULT 45,
fecha DATETIME NULL,
PRIMARY KEY(escorts_id)
)
TYPE=InnoDB;

CREATE TABLE fotos (
fotos_id INT NOT NULL AUTO_INCREMENT,
escorts_id INT NOT NULL,
foto1 VARCHAR NULL,
foto2 VARCHAR NULL,
foto3 VARCHAR NULL,
foto4 VARCHAR NULL,
foto5 VARCHAR NULL,
foto6 VARCHAR NULL,
foto7 VARCHAR NULL,
foto8 VARCHAR NULL,
foto9 VARCHAR NULL,
foto10 VARCHAR NULL,
PRIMARY KEY(fotos_id),
INDEX fotos_FKIndex1(escorts_id)
);

CREATE TABLE provincias (
provincias_id INT NOT NULL,
Álava INT NULL DEFAULT 1,
Albacete INT NULL DEFAULT 2,
Almería INT NULL DEFAULT 3,
Badajoz INT NULL DEFAULT 4,
Baleares INT NULL DEFAULT 5,
Barcelona INT NULL DEFAULT 6,
Burgos INT NULL DEFAULT 7,
Cáceres INT NULL DEFAULT 8,
Cádiz INT NULL DEFAULT 9,
Castellón INT NULL DEFAULT 10,
Ciudad Real INT NULL DEFAULT 11,
Córdoba INT NULL DEFAULT 12,
A Coruña INT NULL DEFAULT 13,
Cuenca INT NULL DEFAULT 14,
Girona INT NULL DEFAULT 15,
Granada INT NULL DEFAULT 16,
Guadalajara INT NULL DEFAULT 17,
Guipúzcoa INT NULL DEFAULT 18,
Huelva INT NULL DEFAULT 19,
Huesca INT NULL DEFAULT 20,
Jaén INT NULL,
León INT NULL,
Lleida INT NULL,
La Rioja INT NULL,
Lugo INT NULL,
Madrid INT NULL,
Málaga INT NULL,
Murcia INT NULL,
Navarra INT NULL,
Ourense INT NULL,
Asturias INT NULL,
Palencia INT NULL,
Las Palmas INT NULL,
Pontevedra INT NULL,
Salamanca INT NULL,
Santa Cruz de Tenerife INT NULL,
Cantabria INT NULL,
Segovia INT NULL,
Sevilla INT NULL,
Soria INT NULL,
Tarragona INT NULL,
Teruel INT NULL,
Toledo INT NULL,
Valencia INT NULL,
Valladolid INT NULL,
Vizcaya INT NULL,
Zamora INT NULL,
Zaragoza INT NULL,
Ceuta INT NULL,
Melilla INT NULL,
PRIMARY KEY(provincias_id)
);

CREATE TABLE publi_agencia (
publiagencia_id INT NOT NULL AUTO_INCREMENT,
agencia_id INT NOT NULL,
banner VARCHAR NULL,
logo VARCHAR NULL,
banner2 VARCHAR NULL,
PRIMARY KEY(publiagencia_id),
INDEX publi_agencia_FKIndex1(agencia_id)
);

CREATE TABLE tags (
tags_id INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
escorts_id INT NOT NULL,
agencia_id INT NOT NULL,
tags SET NULL DEFAULT 'acompañantes', 'agencias compañia', 'agencias contactos', 'agencias escorts', 'agencias putas', 'agencias relax', 'anuncios escorts', 'anuncios sexo', 'anuncios relax', 'busco putas', 'chicas', 'contactos mujeres', 'contactos relax', 'escorts', 'escorts independientes', 'escorts relax', 'ir de putas', 'lesbianas putas', 'masajistas', 'modelos', 'modelos escorts', 'mujeres', 'citas mujeres', 'compañia', 'putas', 'putas contactos', 'putas relax', 'relax', 'sexo', 'solo hombres', 'solo mujeres', 'telefono de putas', 'telefonos putas',
PRIMARY KEY(tags_id),
INDEX tags_FKIndex1(agencia_id),
INDEX tags_FKIndex2(escorts_id)
);

machtcom · #6 (**permalink**) 26/09/2009, 00:50

hola?

¿nadie puede hecharme un cable?

gnzsoloyo · #7 (**permalink**) 26/09/2009, 06:56

Una cosa que surge inmediatamente es que esa tabla PROVINCIA no tiene sentido. ¿Para qué crear una tabla para guardar las provincias, si cada provincia está representada por una columna? ¿Qué vas guardar en ella?
Una tabla para guardar provincias podría ser:

Código sql:

Ver originalCREATE TABLE provincias (
provincia_id INT UNSIGNED NOT NULL PRIMARY KEY,
provincia_nombre VARCHAR(100));

Esta otra forma es de una tabla usada en una base de datos geográfica que yo uso en consultas de geoposicionamiento:

Código sql:

Ver originalCREATE TABLE  `provincia` (
  `ID` INT(11) UNSIGNED  NOT NULL,
  `NOM_PCIA` VARCHAR(255) DEFAULT NULL,
  `CAPITAL` VARCHAR(255) DEFAULT NULL,
  `PAIS` VARCHAR(255) DEFAULT NULL
  PRIMARY KEY  (`ID`)
);

En el ejemplo no estoy incluyendo el campo geométrico para no producir confusiones en tu caso.

La otra tabla que no resulta funcional es la de FOTOS. Esa tabla tiene sentido si y sólo si va a tener siempre 10 fotos. Si tiene menos desperdicia espacio, y si se quiere poner más, no se puede.
Es mejor crear un sólo registro por foto y darle otro atributo para indicar cuál es el numero de foto respecto del IDque es FK:

Código sql:

Ver originalCREATE TABLE fotos (
fotos_id INT NOT NULL AUTO_INCREMENT,
escorts_id INT NOT NULL,
foto VARCHAR NULL
PRIMARY KEY(escorts_id, fotos_id)
);

De esa forma puedes ingresar una cantidad variable de fotos, sin desperdiciar espacio de disco, y también eliminarla sin tener que hacer un UPDATE.
Ponle la FK respecto de la tabla escorts y fijate si tiene sentido un índice entre fotos_id y escorts_id. Como fotos_id es auto_increment, ese índice tendrá la misma cantidad de entradas que el PK. Sería mejor un índice sobre escorts_id. Sería más funcional.

Respecto de la tabla TAGS, no se si tiene sentido usar un campo SET para almacenar los tags. La idea de la tabla es correcta, pero un campo SET es demasiado restrictivo respecto de los contenidos y no permite sacar o agregar sin tener que modificar la estructura de la tabla y correr un script para validar los datos en la base.
Yo lo pondría como VARCHAR y cargaría directamente los valores en la base, Dejándola inaccesible para modificaciones.
Finalmente, la tabla DATOSAENCIA_ID mezcla datos de la agencia con datos de la escort. Eso no tiene sentido. Deberían separarse en dos tablas diferentes.

machtcom · #8 (**permalink**) 28/09/2009, 09:51

Gracias gnzsoloyo, se agradece que hayas perdido un poco de tiempo en estudiar mi caso y hecharme una mano.

Tienes razon con lo de las provincias, pero no entiendo bien como hacerlo. Por el modelo que pones, entiendo que cada vez que realice un alta de cliente, ¿tendría que poner su provincia, capital y pais y así se va autoincrementando? ¿podré hacer un filtro de busqueda por provincias después?

Lo del tema de las fotos, no me ha quedado muy claro la verdad, entiendo lo de los campos, pero no como representarlo. En el ejemplo me pusiste un campo varchar null, pero no entiendo que hago con este, ¿le tengo que poner aqui la ruta de la imagen o en el valor tengo que poner algo en concreto?

Los tags estoy de acuerdo contigo, los pondré en un campo varchar y así si tengo que añadir alguno más o eliminar alguno solo tengo que hacer la acción y ya esta. Pero me sigue surgiendo la misma duda ¿puedo crear desplegables en mi formulario para que eligir los tags a poner en las fichas?

Y por ultimo en los datos de agencia y escorts, hay algunos que son unicos de cada, pero hay otros que me sirven para los dos, por ejemplo datos fiscales para hacer una factura en un futuro, estos los puedo poner en una tabla compartida para los dos o sigo la misma formula y hago una tabla de datos fiscales para cada uno?

Gracias por la ayuda.

gnzsoloyo · #9 (**permalink**) 28/09/2009, 10:03

Cita:

Tienes razon con lo de las provincias, pero no entiendo bien como hacerlo. Por el modelo que pones, entiendo que cada vez que realice un alta de cliente, ¿tendría que poner su provincia, capital y pais y así se va autoincrementando? ¿podré hacer un filtro de busqueda por provincias después?

No. Lo que tienes que tener es una tabla de provincias donde tengas almacenadas todas las provincias y cuando el usuario seleccione la que le corresponda, poner en su registro (el del usuario) poner el ID que le corresponde a la provincia.
Existen tablas fijas en todas las bases que son parte del soporte de datos. Esa es una de ellas. Se crean y cargan con información que no se actualiza si no es por el DBA.

Cita:

Lo del tema de las fotos, no me ha quedado muy claro la verdad, entiendo lo de los campos, pero no como representarlo. En el ejemplo me pusiste un campo varchar null, pero no entiendo que hago con este, ¿le tengo que poner aqui la ruta de la imagen o en el valor tengo que poner algo en concreto?

Con la foto pasa que primero ingresa el escort, y luego se ingresan una a una las fotos, poniendo en cada ocasión el ID del escort a que pertenece.

Cita:

Y por ultimo en los datos de agencia y escorts, hay algunos que son unicos de cada, pero hay otros que me sirven para los dos,

Eso no tiene niguna importancia. Desde el puto de vista de la abstracción de datos, un escor es un escort, y una agencia es una agencia. Son cosas (entidades) distintas.
Por más que compartan atributos no comparten identidad;una agencia puede tener una o muchas escort, y una escort trabajar en muchas agencias. La única forma de mantener esa multiplicidad (cardinalidad) es haciendo una relación N:N. Esto implica que deberás tener una tabla que relacione el ID de cada escort con el ID de cada agencia en la que está trabajando.
Además, de esa forma, si se da de baja una no tienes que perder tiempo en buscar qué borar: borras la escort y se cae la relación con la agencia (ON DELETE CASCADE a la tabla que las relaciona).
La búsqueda de atributos iguales es una simpleza de consultas. No tienes que resolverlo en la tabla, sino en lo que mandas a buscar.

machtcom · #10 (**permalink**) 28/09/2009, 11:05

Vale, entonces para aclararme y disculpa pues son mis inicios y quiero que me quede todo claro para no tener pelearme conmigo mismo...

creo una tabla la cual se llamará provincia donde se pondrán todas las provincias cada una con su id, que me imagino que será el valor que le de yo mismo, por poner un ejemplo:

tabla provincia
id_provincia int autoincrement unsigned (primary)
id_agencia int
id_escorts int
alava varchar valor=1 Null
albacete varchar valor=2
etc

Si estoy en lo cierto, ¿como relaciono cada provincia con su localidad? ¿hago una tabla con todas las localidades y con el id de cada provincia?

Lo restante me queda claro +-, pero lo de las fotos tampoco llego a cogerlo...

Disculpa mi torpeza, pero quiero coger bien los conceptos y no cagarla.

gnzsoloyo · #11 (**permalink**) 28/09/2009, 11:24

Cita:

¿hago una tabla con todas las localidades y con el id de cada provincia?

En realidad, si. Esa es la forma correcta.

Cita:

lo de las fotos tampoco llego a cogerlo..

Veamos una idea de la secuencia de pasos:
1. Dar de alta una agencia.
2. Agregar una escort a la agencia. Requiere seleccionar la agencia y recuperar el ID de la misma, el cual se usa para agregar al registro de la escort.
3. Una vez dado de alta el registro de la escort, se agregan las fotos, agregando a el registro de cada foto, el ID de la escort a que pertenece.
Este ultimo punto tiene una salvedad:
La aplicación tiene que tomar la foto y subirla a una carpeta de la web destinada a estas imágenes. Luego, si se usa siempre la misma carpeta, lo único que se requerirá almacenar será el nombre del archivo completo, ya que la ruta de lectura éstará redefinida en la aplicación.

¿Alguna duda?

machtcom · #12 (**permalink**) 28/09/2009, 11:41

Vale, entonces en la tabla de las fotos, se va incrementando en el campo foto todas las rutas de las fotos que vaya subiendo a la carpeta (pongamos: imagenes) y luego ya tengo que recuperar esa ruta desde la muestra en la web. Me imagino que no me equivoco...

y por ultimo, si estoy en lo cierto, podria ser algo similar con el tema provincias así:

CREATE TABLE `provincias` (
`id` int(2) NOT NULL auto_increment,
`provincia` varchar(255) collate latin1_spanish_ci NOT NULL,
KEY `id` (`id`)
) ENGINE=MyISAM AUTO_INCREMENT=53 DEFAULT CHARSET=latin1 COLLATE=latin1_spanish_ci AUTO_INCREMENT=53 ;

INSERT INTO `provincias` (`id`, `provincia`) VALUES (1, 'Álava'),
(2, 'Albacete'),
(3, 'Alicante'),
(4, 'Almería'),
(5, 'Ávila'),
(6, 'Badajoz'),
(7, 'Baleares (Illes)'),
(8, 'Barcelona'),
(9, 'Burgos'),
(10, 'Cáceres'),
(11, 'Cádiz'),
(12, 'Castellón'),
(13, 'Ciudad Real'),
(14, 'Córdoba'),
(15, 'A Coruña'),
(16, 'Cuenca'),
(17, 'Girona'),
(18, 'Granada'),
(19, 'Guadalajara'),
(20, 'Guipúzcoa'),
(21, 'Huelva'),
(22, 'Huesca'),
(23, 'Jaén'),
(24, 'León'),
(25, 'Lleida'),
(26, 'La Rioja'),
(27, 'Lugo'),
(28, 'Madrid'),
(29, 'Málaga'),
(30, 'Murcia'),
(31, 'Navarra'),
(32, 'Ourense'),
(33, 'Asturias'),
(34, 'Palencia'),
(35, 'Las Palmas'),
(36, 'Pontevedra'),
(37, 'Salamanca'),
(38, 'Santa Cruz de Tenerife'),
(39, 'Cantabria'),
(40, 'Segovia'),
(41, 'Sevilla'),
(42, 'Soria'),
(43, 'Tarragona'),
(44, 'Teruel'),
(45, 'Toledo'),
(46, 'Valencia'),
(47, 'Valladolid'),
(48, 'Vizcaya'),
(49, 'Zamora'),
(50, 'Zaragoza'),
(51, 'Ceuta'),
(52, 'Melilla');

CREATE TABLE `municipios` (
`id` bigint(11) NOT NULL auto_increment,
`provincia` int(2) NOT NULL,
`municipio` varchar(255) collate latin1_spanish_ci NOT NULL,
KEY `id` (`id`)
) ENGINE=MyISAM AUTO_INCREMENT=8123 DEFAULT CHARSET=latin1 COLLATE=latin1_spanish_ci AUTO_INCREMENT=8123 ;

INSERT INTO `municipios` (`id`, `provincia`, `municipio`) VALUES (1, 1, 'Alegría-Dulantzi'),
(2, 1, 'Amurrio'),
(3, 1, 'Añana'),
(4, 1, 'Aramaio'),
(5, 1, 'Armiñón'),
(6, 1, 'Arraia-Maeztu'),
(7, 1, 'Arrazua-Ubarrundia'),
(8, 1, 'Artziniega'),
(9, 1, 'Asparrena'),
(10, 1, 'Ayala/Aiara'),
(11, 1, 'Baños de Ebro/Mañueta'),
(12, 1, 'Alegría-Dulantzi'),
(13, 1, 'Amurrio'),
(14, 1, 'Añana'),
(15, 1, 'Aramaio'),
(16, 1, 'Armiñón'),
(17, 1, 'Arraia-Maeztu'),
(18, 1, 'Arrazua-Ubarrundia'),
(19, 1, 'Artziniega'),
(20, 1, 'Asparrena'),
(21, 1, 'Ayala/Aiara'),
(22, 1, 'Baños de Ebro/Mañueta'),
(23, 1, 'Barrundia'),
(24, 1, 'Berantevilla'),
(25, 1, 'Bernedo'),
(26, 1, 'Campezo/Kanpezu'),
(27, 1, 'Elburgo/Burgelu'),
(28, 1, 'Elciego'),
(29, 1, 'Elvillar/Bilar'),
(30, 1, 'Harana/Valle de Arana'),
(31, 1, 'Iruña Oka/Iruña de Oca'),
(32, 1, 'Iruraiz-Gauna'),
(33, 1, 'Kripan'),
(34, 1, 'Kuartango'),
(35, 1, 'Labastida/Bastida'),
(36, 1, 'Lagrán'),
(37, 1, 'Laguardia'),
(38, 1, 'Lanciego/Lantziego'),
(39, 1, 'Lantarón'),
(40, 1, 'Lapuebla de Labarca'),
(41, 1, 'Laudio/Llodio'),
(42, 1, 'Legutiano'),
(43, 1, 'Leza'),
(44, 1, 'Moreda de Álava'),
(45, 1, 'Navaridas'),
(46, 1, 'Okondo'),
(47, 1, 'Oyón-Oion'),
(48, 1, 'Peñacerrada-Urizaharra'),
(49, 1, 'Ribera Alta'),
(50, 1, 'Ribera Baja/Erribera Beitia'),
(51, 1, 'Salvatierra/Agurain'),
(52, 1, 'Samaniego'),
(53, 1, 'San Millán/Donemiliaga'),
(54, 1, 'Urkabustaiz'),
(55, 1, 'Valdegovía/Gaubea'),
(56, 1, 'Villabuena de Álava/Eskuernaga'),
(57, 1, 'Vitoria-Gasteiz'),
(58, 1, 'Yécora/Iekora'),
(59, 1, 'Zalduondo'),
(60, 1, 'Zambrana'),
(61, 1, 'Zigoitia'),
(62, 1, 'Zuia'),
(63, 2, 'Abengibre'),
(64, 2, 'Alatoz'),
(65, 2, 'Albacete'),
(66, 2, 'Albatana'),
(67, 2, 'Alborea'),
(68, 2, 'Alcadozo'),
(69, 2, 'Alcalá del Júcar'),
(70, 2, 'Alcaraz'),
(71, 2, 'Almansa'),
(72, 2, 'Alpera'),
(73, 2, 'Ayna'),
(74, 2, 'Balazote'),
(75, 2, 'Ballestero (El)'),
(76, 2, 'Balsa de Ves'),
(77, 2, 'Barrax'),
(78, 2, 'Bienservida'),
(79, 2, 'Bogarra'),
(80, 2, 'Bonete'),
(81, 2, 'Bonillo (El)'),
(82, 2, 'Carcelén'),
(83, 2, 'Casas de Juan Núñez'),
(84, 2, 'Casas de Lázaro'),
(85, 2, 'Casas de Ves'),
(86, 2, 'Casas-Ibáñez'),
(87, 2, 'Caudete'),
(88, 2, 'Cenizate'),
(89, 2, 'Chinchilla de Monte-Aragón'),
(90, 2, 'Corral-Rubio'),
(91, 2, 'Cotillas'),
(92, 2, 'Elche de la Sierra'),
(93, 2, 'Férez'),
(94, 2, 'Fuensanta'),
(95, 2, 'Fuente-Álamo'),
(96, 2, 'Fuentealbilla'),
(97, 2, 'Gineta (La)'),
(98, 2, 'Golosalvo'),
(99, 2, 'Hellín'),
(100, 2, 'Herrera (La)'),
(101, 2, 'Higueruela'),
(102, 2, 'Hoya-Gonzalo'),
(103, 2, 'Jorquera'),
(104, 2, 'Letur'),
(105, 2, 'Lezuza'),
(106, 2, 'Liétor'),
(107, 2, 'Madrigueras'),
(108, 2, 'Mahora'),
(109, 2, 'Masegoso'),
(110, 2, 'Minaya'),
(111, 2, 'Molinicos'),
(112, 2, 'Montalvos'),
(113, 2, 'Montealegre del Castillo'),
(114, 2, 'Motilleja'),
(115, 2, 'Munera'),
(116, 2, 'Navas de Jorquera'),
(117, 2, 'Nerpio'),
(118, 2, 'Ontur'),
(119, 2, 'Ossa de Montiel'),
(120, 2, 'Paterna del Madera'),
(121, 2, 'Peñas de San Pedro'),
(122, 2, 'Peñascosa'),
(123, 2, 'Pétrola'),
(124, 2, 'Povedilla'),
(125, 2, 'Pozo Cañada'),
(126, 2, 'Pozohondo'),
etc...

Esto lo he descargado de una página la cual ofrece unas tablas creadas para provincias y municipios de españa.

¿Si esto estuviera bien solo me faltaría relacionar la tabla de provincias y municipios con agencias y escorts o al ser fijas solo tendría que sacar la información de aquí desde el formulario?

te puedo pasar los .sql que los tengo guardados si te interesan...

machtcom · #13 (**permalink**) 28/09/2009, 11:42

Vale, entonces en la tabla de las fotos, se va incrementando en el campo foto todas las rutas de las fotos que vaya subiendo a la carpeta (pongamos: imagenes) y luego ya tengo que recuperar esa ruta desde la muestra en la web. Me imagino que no me equivoco...

y por ultimo, si estoy en lo cierto, podria ser algo similar con el tema provincias así:

CREATE TABLE `provincias` (
`id` int(2) NOT NULL auto_increment,
`provincia` varchar(255) collate latin1_spanish_ci NOT NULL,
KEY `id` (`id`)
) ENGINE=MyISAM AUTO_INCREMENT=53 DEFAULT CHARSET=latin1 COLLATE=latin1_spanish_ci AUTO_INCREMENT=53 ;

INSERT INTO `provincias` (`id`, `provincia`) VALUES (1, 'Álava'),
(2, 'Albacete'),
(3, 'Alicante'),
(4, 'Almería'),
(5, 'Ávila'),
(6, 'Badajoz'),
(7, 'Baleares (Illes)'),
(8, 'Barcelona'),
(9, 'Burgos'),
(10, 'Cáceres'),
(11, 'Cádiz'),
(12, 'Castellón'),
(13, 'Ciudad Real'),
(14, 'Córdoba'),
(15, 'A Coruña'),
(16, 'Cuenca'),
(17, 'Girona'),
(18, 'Granada'),
(19, 'Guadalajara'),
(20, 'Guipúzcoa'),
(21, 'Huelva'),
(22, 'Huesca'),
(23, 'Jaén'),
(24, 'León'),
(25, 'Lleida'),
(26, 'La Rioja'),
(27, 'Lugo'),
(28, 'Madrid'),
(29, 'Málaga'),
(30, 'Murcia'),
(31, 'Navarra'),
(32, 'Ourense'),
(33, 'Asturias'),
(34, 'Palencia'),
(35, 'Las Palmas'),
(36, 'Pontevedra'),
(37, 'Salamanca'),
(38, 'Santa Cruz de Tenerife'),
(39, 'Cantabria'),
(40, 'Segovia'),
(41, 'Sevilla'),
(42, 'Soria'),
(43, 'Tarragona'),
(44, 'Teruel'),
(45, 'Toledo'),
(46, 'Valencia'),
(47, 'Valladolid'),
(48, 'Vizcaya'),
(49, 'Zamora'),
(50, 'Zaragoza'),
(51, 'Ceuta'),
(52, 'Melilla');

CREATE TABLE `municipios` (
`id` bigint(11) NOT NULL auto_increment,
`provincia` int(2) NOT NULL,
`municipio` varchar(255) collate latin1_spanish_ci NOT NULL,
KEY `id` (`id`)
) ENGINE=MyISAM AUTO_INCREMENT=8123 DEFAULT CHARSET=latin1 COLLATE=latin1_spanish_ci AUTO_INCREMENT=8123 ;

INSERT INTO `municipios` (`id`, `provincia`, `municipio`) VALUES (1, 1, 'Alegría-Dulantzi'),
(2, 1, 'Amurrio'),
(3, 1, 'Añana'),
(4, 1, 'Aramaio'),
(5, 1, 'Armiñón'),
(6, 1, 'Arraia-Maeztu'),
(7, 1, 'Arrazua-Ubarrundia'),
(8, 1, 'Artziniega'),
(9, 1, 'Asparrena'),
(10, 1, 'Ayala/Aiara'),
(11, 1, 'Baños de Ebro/Mañueta'),
(12, 1, 'Alegría-Dulantzi'),
(13, 1, 'Amurrio'),
(14, 1, 'Añana'),
(15, 1, 'Aramaio'),
(16, 1, 'Armiñón'),
(17, 1, 'Arraia-Maeztu'),
(18, 1, 'Arrazua-Ubarrundia'),
(19, 1, 'Artziniega'),
(20, 1, 'Asparrena'),
(21, 1, 'Ayala/Aiara'),
(22, 1, 'Baños de Ebro/Mañueta'),
(23, 1, 'Barrundia'),
(24, 1, 'Berantevilla'),
(25, 1, 'Bernedo'),
(26, 1, 'Campezo/Kanpezu'),
(27, 1, 'Elburgo/Burgelu'),
(28, 1, 'Elciego'),
(29, 1, 'Elvillar/Bilar'),
(30, 1, 'Harana/Valle de Arana'),
(31, 1, 'Iruña Oka/Iruña de Oca'),
(32, 1, 'Iruraiz-Gauna'),
(33, 1, 'Kripan'),
(34, 1, 'Kuartango'),
(35, 1, 'Labastida/Bastida'),
(36, 1, 'Lagrán'),
(37, 1, 'Laguardia'),
(38, 1, 'Lanciego/Lantziego'),
(39, 1, 'Lantarón'),
(40, 1, 'Lapuebla de Labarca'),
(41, 1, 'Laudio/Llodio'),
(42, 1, 'Legutiano'),
(43, 1, 'Leza'),
(44, 1, 'Moreda de Álava'),
(45, 1, 'Navaridas'),
(46, 1, 'Okondo'),
(47, 1, 'Oyón-Oion'),
(48, 1, 'Peñacerrada-Urizaharra'),
(49, 1, 'Ribera Alta'),
(50, 1, 'Ribera Baja/Erribera Beitia'),
(51, 1, 'Salvatierra/Agurain'),
(52, 1, 'Samaniego'),
(53, 1, 'San Millán/Donemiliaga'),
(54, 1, 'Urkabustaiz'),
(55, 1, 'Valdegovía/Gaubea'),
(56, 1, 'Villabuena de Álava/Eskuernaga'),
(57, 1, 'Vitoria-Gasteiz'),
(58, 1, 'Yécora/Iekora'),
(59, 1, 'Zalduondo'),
(60, 1, 'Zambrana'),
(61, 1, 'Zigoitia'),
(62, 1, 'Zuia'),
(63, 2, 'Abengibre'),
(64, 2, 'Alatoz'),
(65, 2, 'Albacete'),
(66, 2, 'Albatana'),
(67, 2, 'Alborea'),
(68, 2, 'Alcadozo'),
(69, 2, 'Alcalá del Júcar'),
(70, 2, 'Alcaraz'),
(71, 2, 'Almansa'),
(72, 2, 'Alpera'),
(73, 2, 'Ayna'),
(74, 2, 'Balazote'),
(75, 2, 'Ballestero (El)'),
(76, 2, 'Balsa de Ves'),
(77, 2, 'Barrax'),
(78, 2, 'Bienservida'),
(79, 2, 'Bogarra'),
(80, 2, 'Bonete'),
(81, 2, 'Bonillo (El)'),
(82, 2, 'Carcelén'),
(83, 2, 'Casas de Juan Núñez'),
(84, 2, 'Casas de Lázaro'),
(85, 2, 'Casas de Ves'),
(86, 2, 'Casas-Ibáñez'),
(87, 2, 'Caudete'),
(88, 2, 'Cenizate'),
(89, 2, 'Chinchilla de Monte-Aragón'),
(90, 2, 'Corral-Rubio'),
(91, 2, 'Cotillas'),
(92, 2, 'Elche de la Sierra'),
(93, 2, 'Férez'),
(94, 2, 'Fuensanta'),
(95, 2, 'Fuente-Álamo'),
(96, 2, 'Fuentealbilla'),
(97, 2, 'Gineta (La)'),
(98, 2, 'Golosalvo'),
(99, 2, 'Hellín'),
(100, 2, 'Herrera (La)'),
(101, 2, 'Higueruela'),
(102, 2, 'Hoya-Gonzalo'),
(103, 2, 'Jorquera'),
(104, 2, 'Letur'),
(105, 2, 'Lezuza'),
(106, 2, 'Liétor'),
(107, 2, 'Madrigueras'),
(108, 2, 'Mahora'),
(109, 2, 'Masegoso'),
(110, 2, 'Minaya'),
(111, 2, 'Molinicos'),
(112, 2, 'Montalvos'),
(113, 2, 'Montealegre del Castillo'),
(114, 2, 'Motilleja'),
(115, 2, 'Munera'),
(116, 2, 'Navas de Jorquera'),
(117, 2, 'Nerpio'),
(118, 2, 'Ontur'),
(119, 2, 'Ossa de Montiel'),
(120, 2, 'Paterna del Madera'),
(121, 2, 'Peñas de San Pedro'),
(122, 2, 'Peñascosa'),
(123, 2, 'Pétrola'),
(124, 2, 'Povedilla'),
(125, 2, 'Pozo Cañada'),
(126, 2, 'Pozohondo'),
etc...

Esto lo he descargado de una página la cual ofrece unas tablas creadas para provincias y municipios de españa.

¿Si esto estuviera bien solo me faltaría relacionar la tabla de provincias y municipios con agencias y escorts o al ser fijas solo tendría que sacar la información de aquí desde el formulario?

te puedo pasar los .sql que los tengo guardados si te interesan...

gnzsoloyo · #14 (**permalink**) 28/09/2009, 12:40

Visto a vuelo de pájaro, esa sería una buena estructura para comenzar con el resto. La única salvedad que te diría es que uses tablas InnoDB y no MyISAM, porque las MyISAM no soportan referencias de clave foránea, que es el núcleo de lo que estás por hacer.

machtcom · #15 (**permalink**) 28/09/2009, 12:45

Vale, entonces me pongo a ellos con inmoDB, ya te digo que esto me lo he descargado mientras comentabamos el tema... lo pasaré a inmoDB y veo el resultado.

Tengo una duda y disculpa que me aproveche de ti, pero veo que entiendes de estos temas y me interesa mucho. Cuando voy creando tablas, la manera de enlazarlas que tengo es siempre poniendo la clave foranea en la misma que quiero relacionar, pero según lo que as comentado antes, ¿puedo crear un numero de tablas sin relacionar y después hacer una relación total con una tabla aparte?

no se si me he explicado bien.

gnzsoloyo · #16 (**permalink**) 28/09/2009, 12:54

Cita:

¿puedo crear un numero de tablas sin relacionar y después hacer una relación total con una tabla aparte?

Es una forma de trabajar.
Creas primero todas las tablas y luego estableces las relaciones. No importa cómo lo hagas en tanto el resultado final sea correcto.
Algunas herramientas de diseño asistido,como el Enterprise Architect, cuando crean el script de generación de la base, hace eso mismo.

Lo que debes recordar es:
1. La FK debe ser del mismo tipo y rango que la PK a que se refiere.
2. Ninguna FK puede ser NULL cuando un registro se ingresa. Debe contener una PK valida.
3. Toda relación 1:N hace que se ponga una PK como FK en la segunda tabla.
4. En una relación 1:1, una PK va en la otra tabla, pero es indistinto cuál en cual. Solamente respeta el orden de entrada de los datos.
5. Toda relación N:N crea una tabla nueva que la contiene, aunque esa tabla no exista en el dibujo del esquema.
6. Si una tabla no queda relacionada de alguna forma, o no pertenece al sistema, o faltan relaciones a establecer.

machtcom · #17 (**permalink**) 28/09/2009, 13:06

Joder tio!!! parecía fácil y cada vez se va complicando más. Creo que los conceptos se me van quedando y lo bueno que lo voy haciendo sobre la marcha.

Entonces se pueden relacionar varias tablas como por ejemplo en el caso de las provincias, yo tengo que relacionar las agencias y escorts a las mismas, entonces puedo crear una tabla aparte de relación como

provincia_id como PK
agencias_id como FK
escorts_id como FK

y municipios no me haría falta pues ya está relacionada con provincias. ¿esto sería correcto?

gnzsoloyo · #18 (**permalink**) 28/09/2009, 13:29

Para relacionar escorts y agencias solamente necesitas las dos FK de ellas. La relación con la provincia la sacas de la Agencia, que está relacionada con provincia.
Una consulta tipo sería:

Código sql:

Ver originalSELECT * 
FROM agencia INNER JOIN agencia_escort USING(id_agencia)
          INNER JOIN escort USING(id_escort)
          INNER JOIN provincia USING(id_provincia);

Por larga que te parezca, lo que ganas es en precisión.

machtcom · #19 (**permalink**) 29/09/2009, 01:41

Bueno, disculpa por el retraso de la respuesta pero me surjió un imprevisto. Espero que con toda esta información pueda realizar todo lo que quiero hacer, será que tendré que ir montando y probando y estrellandome para conseguir el resultado optimo. No creo que me cueste realizarlo todo, lo que me queda realmente es entender bien las relaciones, esto de poder acceder a las escorts por provincias atraves de la id agencia, me resulta todavía un poco extraño.

Agradecerte el tiempo que as invertido en enseñar a este novato a defenderse y tener un poco más claro todo. Gracias.

gnzsoloyo · #20 (**permalink**) 29/09/2009, 04:19

Cita:

esto de poder acceder a las escorts por provincias atraves de la id agencia, me resulta todavía un poco extraño.

Un último tip: pon también el ID de la provincia en la escort. De esa forma puedes saber dónde están sin relacionarlas con una agencia.
Es más eficiente.

Saludos y suerte..

machtcom · #21 (**permalink**) 29/09/2009, 05:23

ok... ahora me cuadra, no queria decirte nada pero me resultaba ya demasiado lioso, jejeje!!! Bueno, estoy montandolo todo con todas tus explicaciones y mi logica y e aqui lo peligroso...

He conseguido que me aceptara phpmyadmin las tablas de provincia y municipios cambiandole en el archivo .sql a inmodb y estoy retocando tema de acentos y "ñ", luego las relacionaré, retocaré lo que me comentastes y si me lo permites te lo paso para que le heches un ultimo vistazo y ves si he hecho bien los deberes.

machtcom · #22 (**permalink**) 02/10/2009, 11:37

Hola gnzsolyo, ya he montado toda la bd y solo te pido que le heches un bistazo y me des tu consejo de la misma, tu o cualquiera que se ofrezca. Me parece que entendí bien todo y cada vez se me va haciendo menos grande esto, pero aún me queda.

He copiado el export que he hecho directamente de phpmyadmin, logicamente lo he resumindo para no dar tanto la paliza y vemos que tal.

Gracias por todo.

------------------------------------------------------------------

CREATE TABLE IF NOT EXISTS `agencias` (
`agencia_id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`nom_comercial` varchar(50) COLLATE utf8_spanish_ci NOT NULL,
`titulo` varchar(65) COLLATE utf8_spanish_ci NOT NULL,
`descripcion` text COLLATE utf8_spanish_ci NOT NULL,
`per_contacto` varchar(50) COLLATE utf8_spanish_ci NOT NULL,
`nom_fiscal` varchar(100) COLLATE utf8_spanish_ci NOT NULL,
`nif` varchar(15) COLLATE utf8_spanish_ci NOT NULL,
`calle_fiscal` varchar(100) COLLATE utf8_spanish_ci NOT NULL,
`calle_num` varchar(5) COLLATE utf8_spanish_ci NOT NULL,
`piso` varchar(3) COLLATE utf8_spanish_ci NOT NULL,
`puerta` varchar(3) COLLATE utf8_spanish_ci NOT NULL,
`escalera` varchar(3) COLLATE utf8_spanish_ci NOT NULL,
`cod_postal` varchar(7) COLLATE utf8_spanish_ci NOT NULL,
`fijo_1` varchar(9) COLLATE utf8_spanish_ci NOT NULL,
`fijo_2` varchar(9) COLLATE utf8_spanish_ci NOT NULL,
`movil_1` varchar(9) COLLATE utf8_spanish_ci NOT NULL,
`movil_2` varchar(9) COLLATE utf8_spanish_ci NOT NULL,
`correo` varchar(100) COLLATE utf8_spanish_ci NOT NULL,
`correo_cont` varchar(100) COLLATE utf8_spanish_ci NOT NULL,
`web` varchar(100) COLLATE utf8_spanish_ci NOT NULL,
`desc_apartamentos` text COLLATE utf8_spanish_ci NOT NULL,
`reservas` varchar(100) COLLATE utf8_spanish_ci NOT NULL,
`pagos` varchar(100) COLLATE utf8_spanish_ci NOT NULL,
PRIMARY KEY (`agencia_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_spanish_ci AUTO_INCREMENT=1 ;

CREATE TABLE IF NOT EXISTS `escorts` (
`escort_id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`agencia_id` int(11) DEFAULT NULL,
`nom_comercial` varchar(50) COLLATE utf8_spanish_ci NOT NULL,
`titulo` varchar(65) COLLATE utf8_spanish_ci NOT NULL,
`descripcion` text COLLATE utf8_spanish_ci NOT NULL,
`per_contacto` varchar(50) COLLATE utf8_spanish_ci DEFAULT NULL,
`nom_fiscal` varchar(100) COLLATE utf8_spanish_ci NOT NULL,
`nif` varchar(15) COLLATE utf8_spanish_ci NOT NULL,
`calle_fiscal` varchar(100) COLLATE utf8_spanish_ci NOT NULL,
`calle_num` varchar(5) COLLATE utf8_spanish_ci NOT NULL,
`piso` varchar(3) COLLATE utf8_spanish_ci DEFAULT NULL,
`puerta` varchar(3) COLLATE utf8_spanish_ci DEFAULT NULL,
`escalera` varchar(3) COLLATE utf8_spanish_ci DEFAULT NULL,
`cod_postal` varchar(7) COLLATE utf8_spanish_ci NOT NULL,
`fijo_1` varchar(9) COLLATE utf8_spanish_ci DEFAULT NULL,
`fijo_2` varchar(9) COLLATE utf8_spanish_ci DEFAULT NULL,
`movil_1` varchar(9) COLLATE utf8_spanish_ci NOT NULL,
`movil_2` varchar(9) COLLATE utf8_spanish_ci DEFAULT NULL,
`correo` varchar(100) COLLATE utf8_spanish_ci DEFAULT NULL,
`correo_cont` varchar(100) COLLATE utf8_spanish_ci DEFAULT NULL,
`web` varchar(100) COLLATE utf8_spanish_ci DEFAULT NULL,
`edad` enum('18','19','20','21','22','23','24','25','26', '27','28','29','30','31','32','33','34','35','36', '37','38','39','40','41','42','43','44','45','46', '47','48','49','50','51','52','53','54','55','56', '57','58','59','60') COLLATE utf8_spanish_ci NOT NULL,
`nacionalidad` varchar(30) COLLATE utf8_spanish_ci DEFAULT NULL,
`medidas` varchar(8) COLLATE utf8_spanish_ci DEFAULT NULL,
`altura` varchar(3) COLLATE utf8_spanish_ci DEFAULT NULL,
`peso` varchar(3) COLLATE utf8_spanish_ci DEFAULT NULL,
`apartamento` varchar(150) COLLATE utf8_spanish_ci DEFAULT NULL,
`parking` varchar(100) COLLATE utf8_spanish_ci DEFAULT NULL,
`metro` varchar(100) COLLATE utf8_spanish_ci DEFAULT NULL,
`autobus` varchar(100) COLLATE utf8_spanish_ci DEFAULT NULL,
`reservas` varchar(100) COLLATE utf8_spanish_ci DEFAULT NULL,
`pago` varchar(100) COLLATE utf8_spanish_ci DEFAULT NULL,
PRIMARY KEY (`escort_id`),
KEY `agencia_id` (`agencia_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_spanish_ci AUTO_INCREMENT=1 ;

CREATE TABLE IF NOT EXISTS `fotos` (
`fotos_id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`escort_id` int(11) NOT NULL,
`foto` varchar(255) COLLATE utf8_spanish_ci DEFAULT NULL,
PRIMARY KEY (`fotos_id`),
KEY `escorts_id` (`escort_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_spanish_ci AUTO_INCREMENT=1 ;

CREATE TABLE IF NOT EXISTS `municipios` (
`municipio_id` bigint(11) NOT NULL AUTO_INCREMENT,
`provincias_id` int(2) NOT NULL,
`municipio` varchar(255) CHARACTER SET latin1 COLLATE latin1_spanish_ci NOT NULL,
PRIMARY KEY (`municipio_id`),
KEY `provincia` (`provincias_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_spanish_ci AUTO_INCREMENT=8123 ;

INSERT INTO `municipios` (`municipio_id`, `provincias_id`, `municipio`) VALUES
(1, 1, 'Alegria-Dulantzi'),
(2, 1, 'Amurrio'),
(3, 1, 'Añana'),
(4, 1, 'Aramaio'),
(5, 1, 'Armiñón'),
(6, 1, 'Arraia-Maeztu'),
(7, 1, 'Arrazua-Ubarrundia'),
(8, 1, 'Artziniega'),
(9, 1, 'Asparrena'),
(10, 1, 'Ayala/Aiara'),
(11, 1, 'Baños de Ebro/Mañueta'),
(23, 1, 'Barrundia'),
(24, 1, 'Berantevilla'),
(25, 1, 'Bernedo'),
etc...

CREATE TABLE IF NOT EXISTS `provincias` (
`provincias_id` int(2) NOT NULL AUTO_INCREMENT,
`agencia_id` int(11) DEFAULT NULL,
`escort_id` int(11) DEFAULT NULL,
`provincia` varchar(255) CHARACTER SET latin1 COLLATE latin1_spanish_ci NOT NULL,
PRIMARY KEY (`provincias_id`),
KEY `agencia_id` (`agencia_id`,`escort_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_spanish_ci AUTO_INCREMENT=53 ;

INSERT INTO `provincias` (`provincias_id`, `agencia_id`, `escort_id`, `provincia`) VALUES
(1, NULL, NULL, 'Álava'),
(2, NULL, NULL, 'Albacete'),
(3, NULL, NULL, 'Alicante'),
(4, NULL, NULL, 'Almer'),

etc...

CREATE TABLE IF NOT EXISTS `publiagencia` (
`publi_id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`agencia_id` int(11) NOT NULL,
`banner728x90` varchar(100) COLLATE utf8_spanish_ci DEFAULT NULL,
`banner300x218` varchar(100) COLLATE utf8_spanish_ci DEFAULT NULL,
`logagencia125x125` varchar(100) COLLATE utf8_spanish_ci DEFAULT NULL,
PRIMARY KEY (`publi_id`),
KEY `agencia_id` (`agencia_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_spanish_ci AUTO_INCREMENT=1 ;

CREATE TABLE IF NOT EXISTS `publiescorts` (
`publiescorts_id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`escort_id` int(11) NOT NULL,
`banner728x90` varchar(100) COLLATE utf8_spanish_ci DEFAULT NULL,
`banner300x218` varchar(100) COLLATE utf8_spanish_ci DEFAULT NULL,
`logo125x125` varchar(100) COLLATE utf8_spanish_ci DEFAULT NULL,
PRIMARY KEY (`publiescorts_id`),
KEY `escorts_id` (`escort_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_spanish_ci AUTO_INCREMENT=1 ;

CREATE TABLE IF NOT EXISTS `tags` (
`tags_id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`agencia_id` int(11) DEFAULT NULL,
`escort_id` int(11) DEFAULT NULL,
`tipos_tags` varchar(255) COLLATE utf8_spanish_ci NOT NULL,
PRIMARY KEY (`tags_id`),
KEY `agencia_id` (`agencia_id`,`escort_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_spanish_ci AUTO_INCREMENT=34 ;

INSERT INTO `tags` (`tags_id`, `agencia_id`, `escort_id`, `tipos_tags`) VALUES
(1, NULL, NULL, 'acompañantes'),
(2, NULL, NULL, 'agencias'),
(3, NULL, NULL, 'agencias contactos'),
(4, NULL, NULL, 'agencias escorts'),
(5, NULL, NULL, 'agencias putas'),
(6, NULL, NULL, 'agencias relax'),

etc...

machtcom · #23 (**permalink**) 05/10/2009, 01:12

Nadie por ahí que le heche un vistazo?

gnzsoloyo · #24 (**permalink**) 05/10/2009, 04:12

Perdón el retraso...
Una de las cosas que puedo decirte es que no estoy de acuerdo con esta tabla:

Código sql:

Ver originalCREATE TABLE IF NOT EXISTS `provincias` (
`provincias_id` INT(2) NOT NULL AUTO_INCREMENT,
`agencia_id` INT(11) DEFAULT NULL,
`escort_id` INT(11) DEFAULT NULL,
`provincia` VARCHAR(255) CHARACTER SET latin1 COLLATE latin1_spanish_ci NOT NULL,
PRIMARY KEY (`provincias_id`),
KEY `agencia_id` (`agencia_id`,`escort_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_spanish_ci;

Esta tabla no debería tener los ID ni de las agencias ni de las escort, por un lado porque cda una de las provincias aparece una sola vez, lo que sólo permitiría entrar una escort y una agencia..., por otro lado, porque su
función es identificar las provincias, no las agencias o las escorts, que en realidad se vinculan a ella por tener en sus propias tablas el ID de la provincia. Esta es una tabla fija. No se actualiza si no es para incluir nuevas provincias de nuevos países.
Debería ser:

Código sql:

Ver originalCREATE TABLE IF NOT EXISTS `provincias` (
`provincias_id` INT(2) NOT NULL AUTO_INCREMENT,
`provincia_nombre` VARCHAR(255) CHARACTER SET latin1 COLLATE latin1_spanish_ci NOT NULL,
PRIMARY KEY (`provincias_id`),
KEY `agencia_id` (`agencia_id`,`escort_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_spanish_ci;

Otro tip es: No uses un campo con el nombre de una tabla. Suelen traer problemas al MySQL para reconocer qué es lo que debe leer y dan resultados erráticos.

Esta otra también tiene el mismo problema:

Código sql:

Ver originalCREATE TABLE IF NOT EXISTS `tags` (
`tags_id` INT(10) UNSIGNED NOT NULL AUTO_INCREMENT,
`agencia_id` INT(11) DEFAULT NULL,
`escort_id` INT(11) DEFAULT NULL,
`tipos_tags` VARCHAR(255) COLLATE utf8_spanish_ci NOT NULL,
PRIMARY KEY (`tags_id`),
KEY `agencia_id` (`agencia_id`,`escort_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_spanish_ci ;

Los tags van en una tabla primaria, sin otros ID. Para vincular los tags con las agencias y las escort, necesitas otra tabla:

Código sql:

Ver originalCREATE TABLE IF NOT EXISTS `tags` (
`tags_id` INT(10) UNSIGNED NOT NULL AUTO_INCREMENT,
`tipos_tags` VARCHAR(255) COLLATE utf8_spanish_ci NOT NULL,
PRIMARY KEY (`tags_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_spanish_ci ;

Código sql:

Ver originalCREATE TABLE IF NOT EXISTS `tags_escort_agencia` (
`agencia_id` INT(11) DEFAULT NULL,
`escort_id` INT(11) DEFAULT NULL,
`tags_id` VARCHAR(255) COLLATE utf8_spanish_ci NOT NULL,
PRIMARY KEY (`tags_id`, agencia_id, escort_id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_spanish_ci  ;

Como nunca se repetirá una combinación entre los tres campos, los tres actúan de tabla primaria.

Finalmente, conforme esas observaciones, a la tabla AGENCIA y a la tabla ESCORT le faltan dos campos: 1 municipio_id y provincia_id, o bien municipio_id solo, ya que de este se puede obtener la provincia. En cualquiera de los dos casos, al menos uno de los valores debe ser mandatorio.

machtcom · #25 (**permalink**) 05/10/2009, 09:42

Hola compañero y gracias por hecharle un vistazo.

Si que es cierto que estuve mirando y me fijé que puse muchos id con el mismo del nombre de la tabla... lo hice rápido y sin pensar.

Me parece que después de tu aclaración empieza a quedarme un poco más claro el concepto de las relaciones y si te soy sincero me parece que he querido empezar con algo muy grande, pero no hay más remedio y creo que estoy aprendiendo un montón.

Voy a poner en práctica todo lo que me as comentado y me gusataría hacerte una pregunta; En la web puedo tener agencias, agencias con escorts y también escorts independientes. ¿Cuando tenga que relacionar una escort independiente con su provincia y su municipio como lo hago? ¿le tengo que poner la FK de provincias en la tabla de escorts? Lo digo porque cuando me entre una escort independiente que no trabaje con ninguna agencia quiero poder tener un filtro de busqueda por provincias y municipios.

gnzsoloyo · #26 (**permalink**) 05/10/2009, 09:53

Cita:

¿le tengo que poner la FK de provincias en la tabla de escorts

Exactamente. Por eso te decía:

Cita:

a la tabla AGENCIA y a la tabla ESCORT le faltan dos campos: municipio_id y provincia_id, o bien municipio_id solo, ya que de este se puede obtener la provincia. En cualquiera de los dos casos, al menos uno de los valores debe ser mandatorio.

Por lo de mandatorio significa que se trata de campos de llenado obligatorio y que deben ser NOT NULL en la tabla correspondiente.
El tema, conceptualmente es que si un escort existe, debe residir forzosamente en una ciudad o al menos realizar su actividad principal en ella, en tanto es una persona. Lo mismo corre pare las agencias: Por más que realicen sus actividades en todo el mundo, su residencia legal es única como organización o "Razón Social".

machtcom · #27 (**permalink**) 05/10/2009, 10:04

vale, vale... mira que leo sobre este tema y nunca se me acaba quedando nada, te dan explicaciones tediosas que solo alguien con experiencia en estos temas puede acabar entendiendo y ahora me está quedando claro. Me parece que el concepto lo tenía un poco al contrario, queria ver que en una tabla de provincia tenia que sacar las agencias y las escorts y tienes toda la razon, quien coje información y tiene una provincia es una agencia o una escort... Bueno, creo que me expliqué. Pasa lo mismo que con los tags, los tags no tienen agencias o escorts, son las agencias y las escorts que tienen tags.

Yo lo hacía al reves y por eso, sinceramente, no me estaba enterando de casi nada. Lo estaba haciendo pero no lo cogía y ahora se me ha encendido la luz.

Joder macho, me estas ayudando mucho la verdad. Creo que con esto ultimo voy a tener suficiente para acabar de entender y de montar entendiendo...

Veremos el resultado!!!

gnzsoloyo · #28 (**permalink**) 05/10/2009, 10:10

Buena suerte.
:))

machtcom · #29 (**permalink**) 05/10/2009, 10:11

Otra cosa, partiendo de esta base, con el tema de los tags ¿podría hacer lo mismo? Podría poner en la tabla de agencia y en la de escorts como FK el tags_id...

gnzsoloyo · #30 (**permalink**) 05/10/2009, 10:33

Si creas esa relación tienes el problema de que sólo podría existir un tag por agencia y un tago por escort...
Hay tres esquemas posibles en ese caso: Tag_Escort; Tag_Agencia y Tag_Agencia_Escort. Yo aquí ve la necesidad de tres tablas distintas, y en todo caso el ID de cada una de las tres en cada caso. Si bien crece la complejidad de la base, al menos ganas en precisión de las consultas.