duda sobre estructura BD

[gnzsoloyo]

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:

CREATE 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:

CREATE 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:

CREATE 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.