Uso eficiente de una base de datos

[cslbcn]

Hola. Podríais decirme las conclusiones para usar un método o el otro?

Caso: Un anuncio de un piso tiene varias fotos asociadas a él.
En la base de datos hay que guardar de alguna manera esa relación para que cuando busques el piso te salgan las fotos.

Opcion 1: Se crea una tabla "fotos" relacionada con la tabla "anuncios". En la tabla "fotos" se crea un campo donde se almacenará la url de la foto, por ejemplo: fotos/abcdefghi.jpg.

Opcion 2: No se crea la tabla "fotos". En el servidor se crea una carpeta con mismo nombre del id del anuncio. Ahí dentro de guardan las fotos con el nombre: 1.jpg, 2.jpg, 3.jpg..
Ejemplo: Id del anuncio: 340.
Estructura de archivos:
fotos/340/1.jpg

Cuál de los 2 métodos es el más eficiente, mejor, mejor mantenible, etc?

Gracias.

[repara2]

El segundo "metodo" no es un método, es cualquier cosa, no tiene ningún sentido y es imposible de mantener. Además de los problemas de seguridad y otros... La única opción válida es la primera, una tabla que representa una relación n:m o 1:n entre dos entidades.

[quimfv]

Aun hay una tercera opción guardar las fotos con la siguiente logica

Ejemplo: Id del anuncio: 340.
Estructura de archivos: fotos/340_001.jpg

(los dos ceros son para que se ordenen bien 1,10,2... 001,002,010,... con el id del anuncio puedes tener el mismo problema)

en este caso, como en la opción 2, no necesitas ni la tabla fotos... puesto que con el id del anuncio tanto en un caso como en el otro puedes filtrar las fotos a mostrar.

En cualquier caso lo que no hace falta es guardar la parte fija del la url ("fotos/").

La tabla fotos te puede servir para agregar pies de foto por ejemplo u otros datos y en las tres opciones es recomendable que la crees. Te ayudará a gestionar las fotos.

Las tres opciones son, desde el punto de vista de bbdd suponiendo que siempre creas la tabla fotos, igual de eficientes, la cuarta opción que ya no planteas es guardar las fotos en un campo binario dentro de la bbdd esa seria la opción menos eficiente y que te desaconsejo ferbientemente.

Entre las tres opciones (2 tuyas mas la mia) solo se diferencian por la forma de almacenar los ficheros en el servidor, la primera conserva el nombre original del fichero (punto a favor pero puede ser un desorden punto en contra) las dos siguientes ordenan perfectamente los archivos dandoles un nombre que los relaciona con el anunció... Quizas mi opcion serà la mas comoda ya que no tendras que cambiar de directorio...

[cslbcn]

Yo siempre he usado la primera opcion, me parece la mejor.
La segunda opcion es la que usa un compañero mio y trato de convencerle de que no es viable, pero necesito argumentos..

Tu opcion me parece buena. Pero las fotos se almacenarian en un mismo directorio y no en infinitos, que es lo que trato de que entienda mi compañero.

La cuarta opcion la conozco y no la he puesto porque se que es la peor de todas.


Podeis decirme mas argumentos para convencer a mi compañero que la segunda opcion no es aconsejable?

[quimfv]

Estructura infinita de directorios.

- sin tabla fotos.

No tienes respaldo en la base de datos para gestionar los ficheros.
(se puede hacer sin ella pero simpre sera mas complicado)

No puedes agregar información a los ficheros.

No puedes gestionar por integridad referencial (cuydado con ello ya que en el unico caso que seria real la integridad referencial seria la 4t opción). Por mucho que definas ON DELETE CASCADE entre anuncios y fotos tendras que programar el borrado de los ficheros a parte igual que como lo debe estar haciendo tu compañero.

[h2swider]

Cabe aclarar que la primera opcion tiene un problema importante. Si piensas guardar el nombre de las fotos, no hay nada que te asegure que ese nombre no se repetira en el futuro.

Yo siempre considere que la mejor opción para este tipo de proyectos es,

1- crear una tabla con los datos de las fotos en tu caso serian 2 por los anuncios.
2- y luego las fotos guardarlas en un solo directorio y de nombre le pones el id de la foto insertada.

[h2swider]

Iniciado por repara2

El segundo "metodo" no es un método, es cualquier cosa, no tiene ningún sentido y es imposible de mantener. Además de los problemas de seguridad y otros... La única opción válida es la primera, una tabla que representa una relación n:m o 1:n entre dos entidades.

Yo la verdad le veo mucho sentido, aunque mucho mas viable siempre trabajarlo con DBs. Pero es una solución perfectamente valida, no me parece adecuado descartarla desde un principio de la manera que lo dices