Información y consejos para proyecto web

[Casimiro Notevi]

Hola, tengo que preparar el análisis de un proyecto web y me gustaría leer opiniones de personas que tengan experiencia en algo parecido para así tomar una decisión u otra.

El proyecto es para una cadena de empresas asociadas y sus sucursales, las cuales necesitan un sitio común donde almacenar las incidencias de los artículos que les ha llegado defectuosos, estropeados, rotos, los que se han deteriorados con el tiempo, etc. y que todos puedan consultarlos mediante varios filtros.

Resumiendo: usuarios, artículos y fotografías de los artículos dañados (esto de las fotos es el principal problema).

Explico un poco el proceso que se pretende: en cualquiera de las empresas o sucursales asociadas reciben un pedido de la central y llegan una serie de artículos dañados en el transporte, porque han estado mucho tiempo al sol, porque han estado almacenados en un lugar húmedo, etc. y también puede ser que lleguen correctamente pero que se estropeen después de un tiempo en los almacenes.
Entonces el usuario entra en la web, se da de alta si no ha entrado antes, da de alta la referencia del artículo dañado si no existe o le aparecen los datos para confirmar, si ya existe. Ahora debe rellenar un formulario con varios datos del artículo, defectos detectados, etc. y adjuntar fotografías de los mismos, puede subir cuantas fotos le parezca.

Cualquier otro usuario puede consultar fotos de artículos por usuario, zonas, tipos de defectos, etc. para comprobar, por ejemplo, si un artículo se daña más en el norte (zona más fría y húmeda) o en el sur (zona más calurosa y seca), puede consultar sólo sus artículos y fotos, los de otro usuario (empresa/sucursal), los de una zona en especial: Cantabria, Andalucía, etc., los que lleven cierta cantidad de tiempo dados de alta, etc.

Además debe llevar una opción de estadísticas donde filtrar por todos los apartados que deseen, eso no es problema tampoco.

En general todo es bastante simple, el principal problema aquí es que haciendo unos cálculos “así por encima” nos ha salido que en el primer año pueden almacenarse unas cien mil fotos, en tres años alrededor de un millón de fotos y a partir de ahí se estabilizaría porque se eliminarían los registros más antiguos.

Las fotos deben ser todas de formato 'jpg' y al guardarlas se deben convertir si no lo son. Pero otra premisa que exigen es que hay que mantener los tamaños originales de las mismas. Y esto sí es un problema porque ya me veo yo a la gente haciendo fotos de 12 megas cada una, pero bueno, ellos sabrán lo que quieren pagar de ancho de banda , seguro que en poco tiempo me piden que las reduzca de tamaño al guardarlas

Y bien, aquí van las preguntas:

• Fotos en una base de datos o fuera
• Si van fuera, cómo organizarlas mejor (esto creo que es lo primordial)
• Hacerlo todo desde cero o aprovechar algo existente tipo joomla, drupal, etc.
• Los servidores estarán alojados físicamente en la central de la empresa, qué medidas de seguridad se recomiendan (Por supuesto, en Linux)
• Lenguaje a usar y base de datos, mi experiencia web no es muy amplia
• Otras cosas a tener en cuenta
• Consejos
  

Y eso es todo, creo que no se me olvida nada importante. Muchas gracias a quien pueda o quiera aportar algo interesante .

[manuc]

Hola Casimiro Notevi,

Te comento mi opinión personal:

Fotos en una base de datos o fuera
Si van fuera, cómo organizarlas mejor (esto creo que es lo primordial)

Fuera de base de datos, en un directorio de imágenes y protegido (si es posible)
En un proyecto similar, lo hemos hecho es crear una tabla en base de datos, con un ID autogenerado y el Nombre original del fichero.
Al subir la foto, registras la entrada en la tabla de imágenes y la imágen la subes al directorio de imágenes y le cambias el nombre por el ID del registro creado para ella.

Para los listado de imágenes tiras de la tabla en base de datos. Cuando un usuario quiere descargar una imagen, localizar el fichero correspondiente al ID que se quiere descargar y al descargar lo haces con el nombre original de la imagen (que estaba también almacenado en la misma tabla)

Hacerlo todo desde cero o aprovechar algo existente tipo joomla, drupal, etc.

Los defensores de Joomla te dirán que se puede hacer sin problemas y que irá a las mil maravillas. Yo no lo haría con Joomla, ni nada de estos Software que, en teoría, te facilitan el trabajo. Desde mi punto de vista le pasa como cuando haces una base de datos con Access. Para empezar está bien, pero cuando quieres hacer cosas más avanzadas todo se complica.
Sin contar con los inconvenientes de tener todo el contenido de la Web en base de datos. Si no tienes muy muy bien configurada la página en Joomla, puedes tener grandes problemas de tiempos de carga.

Te recomiendo que todas las páginas que puedas las hagas con html, php o asp directamente. Ganarás mucho control, estructuración y velocidad de carga.

Los servidores estarán alojados físicamente en la central de la empresa, qué medidas de seguridad se recomiendan (Por supuesto, en Linux)

Las habituales: firewall físico, si las delegaciones tiene IP fijas, pues filtro por IP's, Antivirus, redundancia y respaldo de servidores principales, buen sistema de copias de seguridad, SAIs, etc.

Lenguaje a usar y base de datos, mi experiencia web no es muy amplia

HTML, AJAX, CSS, JavaScript, PHP y MySQL.
Si te es posible, respeta los estándares W3C, AAA, CSS, etc.
Puedes utilizar DreamWeaver, mezclando plantillas con "includes" de php estructurados para no duplicar mucho código.

Otras cosas a tener en cuenta

Cuidado con los distintos navegadores. Es una pesadilla.

Consejos

No abuses de los tamaños de ficheros que reutilices (CSS, JS's, etc) te perjudicarán en los tiempos de carga de la Web.

Revisa periódicamente los tiempos de carga de las páginas (hay sitios que dan el tiempo de carga de cada fichero de tu web)

Estructura bien el proyecto para crear unidades que puedas reutilizar desde distintos módulos.

Si vas a indexar algunas páginas en buscadores, utiliza para esas páginas nombres amigables.

En páginas que vayas a indexar en buscadores, no utilices AJAX para cargar contenido estratégico para la indexación.

Seguro que hay mucho más, pero ahora no me brotan las ideas.

Bueno, un poco "espeso", pero espero que te ayude.

Un saludo.

[[movorack]]

Empezado por Casimiro Notevi

• Fotos en una base de datos o fuera
• Si van fuera, cómo organizarlas mejor (esto creo que es lo primordial)
• Hacerlo todo desde cero o aprovechar algo existente tipo joomla, drupal, etc.
• Los servidores estarán alojados físicamente en la central de la empresa, qué medidas de seguridad se recomiendan (Por supuesto, en Linux)
• Lenguaje a usar y base de datos, mi experiencia web no es muy amplia
• Otras cosas a tener en cuenta
• Consejos
  

Hola casimiro,

a ver unos pensamientos al aire... por si las moscas te sirve alguno...

Por mi parte yo almacenaria las fotos en un directorio... y no en la DB;

Lo de la estructura del directorio para mi dependeria del mismo desarrollo en si... aunque de una como sabes tirar todas las fotos en un solo directorio no es recomendable... algo como "/photos/año/mes/numerodecaso/img1.jpg" poria servir.

aunque joomla tiene unos administradores de ficheros... la verdad mejor seria lanzarte a un desarrollo desde 0 para la herramienta como tal... si la herramienta va acompañada de un sitio informativo habria que tener en cuenta su complejidad si es muy complejo depronto un wordpress o un joomla te ayude.

Con lo del lenguaje, de seguro que yo me iria por PHP + MySQL... te ofrece buen rendimiento... y como dices que no tienes mucha experiencia en las webapps... pues la comunidad php es grande y tutoriales sobran en toda la red... aquí una comunidad de desarrollo de aplicaciones web

si depronto tienes algo de tiempo para experimientar echale un ojo a las bases de datos NOSQL... google por ej ya no usa MySQL... tiene una nueva base de datos que se llama BigTable; facebook tomo el mismo camino e implentó cassandra... http://cassandra.apache.org/;

Hasta donde entiendo (no he leido mucho) estas bases de datos dan mayor velocidad a las aplicaciones web siempre y cuando la estructura de la base de datos no sea muy compleja... mas que todo si solo se trata de unas pocas tablas pero muchos datos en ellas... twitter creo que vá en las mismas.

Si por alguna cosa... ves que el proyecto se dimensiona algo grande, puedes hacer mano de un frwamework... depronto Symphony te pueda ayudar (hasta tiene funcionalidades para ajax)... aquí un libro detallado

otra cosa (casi se me escapa)... en la web no despliegues las imágenes tal cual las subes... puedes usar un generador de miniaturas... esto te ayuda muchisimo con la carga de la imágen... al lado de la misma imágen puedes colocar un link para descargar el archivo original.

De todos modos... trata siempre de echar mano de clases ya preparadas o crear tus propias clases para las cosas sencillas y tediosas... conectividad a la DB, generación de contenido... este sitio tiene clases para cada cosa...

Pues... hasta aquí los pensamientos al aire... por lo demas... aqui estamos tus compadres... y con los compadres pa las que sea.

[Casimiro Notevi]

Por si acaso no lo he citado antes, lo principal en la web será la consulta de las fotos por distintos parámetros, todo girará alrededor de las fotos de los distintos artículos haciendo búsquedas por referencias, marcas, descripciones, fechas de alta, etc. y mostrándose las fotos de las mismas.

[Neftali [Germán.Estévez]]

Empezado por Casimiro Notevi

Y bien, aquí van las preguntas:

• Fotos en una base de datos o fuera
• Si van fuera, cómo organizarlas mejor (esto creo que es lo primordial)
• Hacerlo todo desde cero o aprovechar algo existente tipo joomla, drupal, etc.
• Los servidores estarán alojados físicamente en la central de la empresa, qué medidas de seguridad se recomiendan (Por supuesto, en Linux)
• Lenguaje a usar y base de datos, mi experiencia web no es muy amplia
• Otras cosas a tener en cuenta
• Consejos
  

Hola Casimiro.
Pues no tengo mucha experiencia en Web, pero me interesa que me vayas comentando cómo va el proyecto, Las decisiones que tomas y qué resultado dan.

En cuanto a las preguntas, la primera es la eterna discusión. Creo que nunca se pondrán de acuerdo los defensores de una y otra postura.

Mi experiencia en este campo (no es con una apliación web, pero la problemática es la misma desde una aplicación no-web) ha sido la de escoger guardar los ficheros fuera de la Base de datos. Hay razones para lo uno y para lo otro, pero se trata de ver el peso de cada una y las ventajas que te puede aportar. En mi caso:

* Al incluirlas en la Base de datos el tamaño de esta hace más complejas las tareas "varias" a realizar con la BD. Backups, Restauraciones, copias,...
Una simple multiplicación da muestra de ello. Por ejemplo, fotos de 5 MG; Cuando tengamos 300.000 fotos y hagamos el Backup. ¿Cuanto va a tardar? ¿Dónde lo vamos a meter?
* Al incluir las imágenes fuera de la Base de datos tenemos mucho más control sobre ellas y más facilidad para realizar todo tipo de operaciones. Copias de seguridad, cambios de tamaño, miniaturas,...
* Podemos tenerlas divididas en diferentes ubicaciones físicas de forma mucho más fácil.

································································································
En nuestro caso partimos de un directorio inicial, a partir de ahí tenemos diferentes Volúmenes (VOL) y dentro de los volúmenes, diferentes directorios (DIR).
Se tiene en cuenta que cada Directorio no supere un tamaño especificado u un número de ficheros fijado (5000, por defecto), de esta forma se controla que cada directorio no tenga ni demasiado tamaño ni demasiados fucheros.
Esta ubicación de:
UBICACIÓN -> VOL -> DIR
facilita, por ejemplo, que con pocos cambios se puedan mover los Volúmenes del 1 al 1000 a otra ubicación (otro disco) modificando sólo la Ubicación inicial.
Lo mismo pasa cuando un disco cae, basta con cambiar la ubicación para que las imágenes se vayan a buscar a otro disco (replicación).
································································································

* Otras aplicaciones no tienen porqué tener acceso a la base de Datos. Basta con que se les pase la ubicación del fichero que necesitan (esto hay que evaluar en cada caso si es bueno o malo).

* Un inconveniente de este, es que los directorios de imágenes/documentos deben estar accesibles para más gente/programas de lo necesario. Es decir, cualquier aplicación que deba acceder a una imagen/documento, debe tener acceso al directorio de imágenes. Esto no me acaba de gustar y las posibles soluciones las estamos pensando/evaluando.

[[movorack]]

Lo del tema del acceso a directorios en las aplicaciones web se maneja mas facil pues con los permisos de linux solo permites que el usuario del webserver (apache por lo general) sea quien tenga permiso de entrar a ese directorio y se le restringe el acceso y escritura al publico y/o al grupo.

[roman]

Las razones que expone Neftali son bastante convincentes para almacenar las fotos fuera de la base. Aunque si generas miniaturas, quizá éstas sí podrías guardarlas en la base. Sería más cómodo para generar listados.

Recuerda que con PHP también puedes usar Firebird, así que no tendrías que desprenderte de tu motor favorito.

Al guardar las imágenes en archivos en disco, hay que tener en cuenta que no puedes guardarlas en rutas accesibles desde la web (a menos que cualquiera pueda verlas). Tendrás que impedir su acceso y usar el mismo PHP para recoger las fotos y servirlas.

Desde luego, no creo que ningún CMS como joomla, drupal, wordpress, etc. sirva para esto. En todo caso, sería más adecuado algo como el w2box, que es el que usamos aquí en los foros para gestionar los archivos del FTP público. Aunque más que nada para darte una idea, porque también pienso que los mejor es hacerlo desde cero, que no parece un proyecto complejo.

// Saludos

[roman]

Empezado por movorack

Lo del tema del acceso a directorios en las aplicaciones web se maneja mas facil pues con los permisos de linux solo permites que el usuario del webserver (apache por lo general) sea quien tenga permiso de entrar a ese directorio y se le restringe el acceso y escritura al publico y/o al grupo.

Pero es este mismo usuario el que accede para servir el contenido, así que las fotos estarían al alcance de cualquiera desde la web. Si se usa Apache, hay que usar además un .htaccess para impedir el acceso desde el exterior.

// Saludos

[Casimiro Notevi]

Voy tomando notas de todos vuestros comentarios, por ejemplo:

Empezado por roman

[..] hay que usar además un .htaccess para impedir el acceso desde el exterior. [..]

¿Eso de qué va?

[roman]

Siguiendo el ejemplo de movorack, si tienes el directorio

/photos/2010/04/33025/img1.jpg

el usuario puede poner

http://tuservidor.com/photos/2010/04/33025/img1.jpg

y descargarse la foto sin necesidad de iniciar sesión en tu sistema. Si las fotos no son para el acceso público, debes proteger los directorios donde las guardas. En Apache, esto lo puedes hacer colocando un archivo.htaccess con este contenido:

deny from all

De hecho, acabo de percatarme, que el w2box lo maneja abierto. Por ejemplo, si vas al FTP público y navegas a Delphi|Tools, podrás ver que los enlaces de cada archivo son las rutas directas al archivo. Por ejemplo

http://www.terawiki.clubdelphi.com/archivos/Delphi/Tools/CloneDelphiWizard.zip

Si pones eso directamente en el navegador, podrás descargar el archivo. Sin emabrgo, a manera experimental y temporal, he puesto un .htaccess en

http://www.terawiki.clubdelphi.com/archivos/Delphi/Ejemplos

Intenta descargar ahora uno de los archivos de esa sección...

De todas formas, hay que tener en cuenta, que el Apache debe estar configurado para procesar archivos .htaccess.

// Saludos

[Casimiro Notevi]

Ya entiendo, me dice que no tengo permisos.
Ya puedes dejarlo como estaba


Por cierto, aunque no lo he hecho yo directamente, sí he colaborado en bastantes cosas de un proyecto parecido que hicimos en mi trabajo hace varios años.
Era, y es, como un sistema de ventas con carrito de la compra, navegas por los artículos, ves las fotos, las amplias, etc. y haces el pedido de las unidades que quieras.
Está hecho en php con firebird y los datos de los artículos y los pedidos los almacena directamente en el otro servidor, donde está la gestión comercial de la empresa.
Pero yo no "piqué" el código. En este caso me tocará a mí, seguro.
La principal diferencia es que este nuevo proyecto es prácticamente todo fotos, es lo principal, y es también el motivo de pensar no almacenarlas en la base de datos, porque un millón de fotos a sólo 1 mega por cada una son... un millón de megas. Pues no sé cómo hice las cálculos, pero había sacado mucho más, si es así entonces sería sólo 1 giga de base de datos.
Creo que me equivoco en algo.

[mamcx]

Algo de lo que no hablas es cuantos accesos concurrentes hay, cuales son los parametros de confiabilidad y tiempo en linea y como rayos se manejaran los backups!

Puedes leer algo general sobre hacer aplicaciones escalables y robustas aqui:

http://www.slideshare.net/mmalone/sc...django-1393282

(Es en django, que es lo que recomendaria pa usar: PHP es como usar C++, con la legibilidad del PERL... pero bueno son lecciones que se pueden aplicar a lo que sea, esta desactualizado en cuanto no hay nada maduro en Nosql, ahora SI).

Con respecto a lo de las imagenes, la mejor explicacion sobre este tema y todos los demas la vi aqui:

http://www.slideshare.net/fbrunel/ja...rlin-sept-2007

(Es una presentacion larga pero ponle mucho cuidado a donde arranca en "Pay attention in how you store the files" y muestra las diferentes estrategias.)

Yo hosteo en www.joyent.com y me ha ido bien, y esta gentes es muy experta en estos temas. Valdria la pena que tal como recomiendan en la presentacion, evaluaras opensolaris/zfs/zones como infraestructura....

El manejo de los archivos, si terminan siendo masivos, depende mucho de que tan bueno sea el array de almacenamiento en red. Otra alternativa, es no usar un BD relacional sino una NOSQL (ya te mencionaron algunas) pero estoy usando MongoDB con GridFS (http://api.mongodb.org/python/1.4%2B...dfs/index.html) que es su API para almacenamiento MASIVO y GRANDE de archivos. Mongo hace backuos en caliente, o mejor dicho, prendes otro servidor, lo metes en la lista, se sincroniza y apagas. Tambien hay un metodo de hacer backup de forma tradicional.

Es muy bueno! Pero el chiste en este caso es que tengas al MENOS 2 servidores que se repliquen entre si (Mongo es muy != a BD relacionales, replicacion es algo natural y sin lios).

AL usar Mongo, no hay problemas de como rayos almacenes los archivos. Y NO TIENES QUE ABANDONAR LA BD. Puedes acceder a la BD de mongo usando cualquier driver (hay para python, php, .net, etc) para el manejo de archivos y la BD pa lo demas.

Mongo es lo que usa SourceForge. Una unica advertencias: Mongo en un solo servidor no es "confiable" en el sentido que se pueden perder datos si hay un crash (=MySql sin transacciones). Los desarrolladores de Mongo apuntan a que la unica forma confiable es federar los datos, y en cierta forma tienen razon.

Lo que me lleva a que me parece MUY mala idea hostiar "en casa". Como muestra la presentacion de joyent, hay tantas cosas que hay que hacer bien que me parece mejor usar un proveedor externo (amazon, joyent, mediatemple, etc...). De lo contrario, buenas UPS, servidores redundantes, buen sistema de almacenamiento en RAID (o mejor aun: Solaris+ZFS).

La BD? Pa lo que mencionas cualquiera daria la talla, excepto por lo de los archivos. Hay o Mongo o ZFS u otro sistema de archivos robusto + estrategia de almacenamiento.

Prueba ademas, usar Cherokee (mas rapido que apache) y/o nginx (mas veloz para servir archivos estaticos. Si no tienes una carga alta por segundo, con cherokee creo que matas todo de un solo tiro.

http://www.cherokee-project.com/doc/ Muestra que tienes proxy reversos, balanceos, modulo para generar links a archivos temporales (lo que impide el lio que menciona roman) y mas cosas con lo que 1 solo servidor te cubre como a 5.

Una BUENA aplicacion web, usa URLS que no estan ligadas al sistema de archivos (o url limpias o bonitas como le llaman). Con django/rails es lo normal que las URLs representen el mapeo a las vistas asi que no hay nada de eso de usar .htacces y cosas asi raras (y es comun usar un servidor web independiente, no apache, para servir archivos).

[roman]

Je, je. Sé que PHP te causa roña, pero mira que compararlo con PERL

Una cosa, todo esto que planteas es interesante, pero, ¿no estamos aplicando algo así como el anti-KISS principle? Es decir, se trata de una aplicación donde básicamente sólo hay que subir fotos con unos cuantos datos extra.

Por otra parte, esto de que con django/rails te olvidas de usar .htaccess está por verse. Esto es, no mezclemos cosas. Si tu servidor web es apache, por más que uses django o rails, los archivos está ahí al alcance de todos, a menos que lo impidas.

// Saludos

[Casimiro Notevi]

Son muchas opciones, posibilidades, formas, lenguajes, sistemas, etc... y casi que complica más conocer tantas opciones que no saberlo

No lo he dicho antes, según pregunta mamcx, teniendo en cuenta las actuales llamadas de teléfono, los emails y fax que reciben, (que es el sistema que usan actualmente para las incidencias) se ha hecho un cálculo que indica que serán entre 100 y 200 conexiones simultáneas constantes las que recibirá el sistema.

En principio, aunque nuestro cliente quiere montar el servidor en sus oficinas, yo creo que se le convencerá para no hacerlo así, se contratará un VPS en algún sitio que vaya bien, o un servidor dedicado.

La idea es instalar un linux server, seguramente debian o ubuntu y sistema de arhivos ext4, el servidor web será cherokee con casi toda seguridad. Todos los servidores que hemos montado desde 1998 llevan Linux y en ese aspecto estamos muy seguros.

El programa web inicialmente se había pensado: php + firebird + fotos (dentro/fuera)

Lo de php no me convence demasiado, pero tampoco quiero perder mucho tiempo en aprender algún lenguaje "raro", y php por lo que he visto está muy documentado.

Lo de las fotos, ahora que he pensado en el tamaño, tampoco me parece muy excesivo, porque aunque guardaran todas las fotos a 10 megas, la base de datos tendría 10 Gigas con un millón de fotos. Ahora mismo están manejando en red local una base de datos de algo más de 20 Gigas.

Algo que sí tengo en duda es, suponiendo que se use php, ¿existe algún "componente" para manejar firebird que no sean los propios controladores que trae php?.

Otra cosa que no he comentado es que se pretende que la página web sea "moderna", ágil, fácilmente modificable para poner cosas nuevas, alguna oferta temporal, información variada, encuestas a los usuarios, etc. y que sea cómodo de poner y quitar esas cosas, estilo de como se hace con los "plugins" de blogger, wordpress y sitios así.

Ahora mismo, aparte del lenguaje a usar, lo que más me preocupa son las fotos (dentro/fuera), ya que el sistema que se ha comentado más arriba, lo de thumbnail me parece estupendo para no estar moviendo imágenes enormes.

[roman]

Si el proyecto no es para ayer, ¿por qué no te planteas usar Python? Sirve que nos enseñas

En cuanto al hosting, conozco cierto proveedor que es muy bueno

// Saludos

[Casimiro Notevi]

Empezado por roman

Si el proyecto no es para ayer, ¿por qué no te planteas usar Python? Sirve que nos enseñas

¿Qué "cosas" interesantes tiene phyton?, yo sólo lo conozco de scripts que tengo por aquí para hacer algún proceso.

Empezado por roman

En cuanto al hosting, conozco cierto proveedor que es muy bueno // Saludos

Me lo vas a tener que recomendar

[mamcx]

Pegate una mirada a http://www.djangoproject.com/. Se podria decir que por mucho, es la razon por lo que mas de uno empezo en python

En cuanto al lenguaje, es como lo mas parecido en cuanto a Delphi sobre el hecho de que es FACIL de leer. La comunidad de python premia la legibilidad, como en Delphi.

No existe eso de mezclar html, css, js, python, todo a la vez (no por defecto, como en php). Lo que lleva a que el codigo sea de muy facil mantenimiento.

Tiene muchas buenas cualidades, pero es dificil apuntarse solo a una. La legibilidad seguro es el #1, luego vienen un monton de cosas que se van juntando.

Un argumento en contra de PHP? Pues python es MAS potente. De seguro. Pensar en php sin web? no. Pensar en python sin web? Claro!. Es posible hasta hacer aplicaciones de escritorio, y hay unas muy buenas (pero en OSX, las que conozco). PHP cuando hay que hacer algo fuera de su core, pues toca meter c u otra cosa.

Un punto en favor de PHP? Es como el VB: Todos y todas lo usan, y se despliega en cualquier cosa, en hosting mediocres sin problemas. Tambien, que PHP es directo web. No hay que usar un framework como django (o turbogears, o pylons, u otro) para hacer tu primera paginita web.

Con todo, lo que hablas de carga y demas no descalifica aPHP en lo absoluto. Igual en manos competentes es una buena eleccion.

----

Aunque el peso de las imagenes no es nada excesivo, de todas maneras es bueno tener en cuenta las recomendaciones de la presentacion que te pase. Es muy facil degradar el sistema de archivos si no se particiona el almacenamiento de las imagenes. Ademas, seguro hay muchas otras como los thumbails que hacen sumar. Servir muchos archivos chicos es tan dificil como pocos grandes.

Una ultima recomendacion? Usa algo como http://www.balsamiq.com/products/mockups/desktop para hacer sketchs de la aplicacion, irse derecho con cherokee, probar desde el principio con MUCHAS imagenes (es posible generarlas o usar un banco de imagenes), ten listo el plan de emergencias (backups) y haz la aplicacion simple. A veces (y esto es pa roman ) el uso de herramientas diferentes, plataformas, tecnicas, etc, conduce a lo simple. La parte dificil es elegir, entender y probar, pero hay ganancia en ver como lo resuelven otros y porque elegieron lo que eligieron.

[mamcx]

Empezado por Casimiro Notevi

Otra cosa que no he comentado es que se pretende que la página web sea "moderna", ágil, fácilmente modificable para poner cosas nuevas, alguna oferta temporal, información variada, encuestas a los usuarios, etc. y que sea cómodo de poner y quitar esas cosas, estilo de como se hace con los "plugins" de blogger, wordpress y sitios así.

Aqui se me prendio la alarma de una! Una cosa es una cosa (sistema realmente importante de fotos) y lo demas es lo demas (CMS de entretenimiento al departamento de ventas y demas). Es caracteristico de los usuarios querer que su sistema (por ejemplo) de contabilidad ademas le mande cartas de felicitaciones animadas en gif a sus clientes, envie mails masivos y controle el marketing viral en facebook. Lo he vivido!

De entrada, yo diria que no. Si tu cliente quiere eso, pues hombre, que monte wordpress y listo el pollo. Y como metes a tu sistema?

Ah, facil. Pa eso puedes:

- usar un dominio como appfotos.tucliente.com
- Compartir la BD de usuarios y/o utilizar un sistema federado como OpenID, o LDAP o una BD central omlo que sea.
- Usar un API rest en tu aplicacion, para poner lo relevante en el CMS e integrar con plugins alla
- O permitir enlazar con IFRAME segementos de codigo html, para mostrar widget y pendejadas de esas.

No mezcles ambas cosas. Te saldra un chicharron tremendo. Usa un CMS probado pa contentar a tu cliente e implementa libre de ataduras el sistema que REALMENTE te estan solicitando.

[Casimiro Notevi]

Por cierto, python puede usar firebird sólo en windows.
Otro detalle: todo debe ser software libre.

Cada vez estoy más confuso

[mamcx]

Por cierto, python puede usar firebird sólo en windows.

De donde sacaste eso???????????

Otro detalle: todo debe ser software libre.

Todo lo que se ha mencionado cumple