Hola Leo, disculpa que no me comunique con vos con anterioridad. Estuve muy complicada por asuntos de salud y las exigencias del ultimo año de facultad.<div>Actualmente estoy con principio de neumonía. </div><div><br></div>
<div>Estoy retomando la tesina que quiero entregarte. Queria consultarte hasta que fecha estas ahi en la facultad para así me acerco y te llevo las cosas.</div><div><br></div><div><br></div><div>Saludos.</div><div><br></div>
<div>Maia</div><div><br><div class="gmail_quote">El 12 de agosto de 2011 00:23, Leonardo Tadei - Pegasus Tech Supply <span dir="ltr"><<a href="mailto:leonardot@pegasusnet.com.ar">leonardot@pegasusnet.com.ar</a>></span> escribió:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Hola Maia,<br>
<br>
        lamento que te sientas mal: ojalá te recuperes pronto.<br>
        Te respondo intercalado:<br>
<br>
El jue, 11-08-2011 a las 18:43 -0300, Maia Cordero escribió:<br>
<div class="im">> Hola Leo. Estoy en cama, ayer me sentia mal y hoy me siento peor. No<br>
> voy a poder ir a mostrarte los avances. El martes me acerque a la<br>
> facultad y pedi la prorroga, quedaron de informarme sobre la<br>
> respuesta.<br>
<br>
</div>        Bueno, veremos como sigue ese trámite.<br>
<div class="im"><br>
> Tenes razón respecto a la normalización de la base de datos, aunque yo<br>
> no quise hacerlo así porque me parecia demasiado "engorroso" tener que<br>
> hacer +tablas +stores +clases por datos no críticos al sistema. Pero<br>
> si se que se tiene que normalizar así como decís vos. Así que ya lo<br>
> modifique.<br>
<br>
</div>        No sabría que criterio aplicar para saber si un dato es crítico o no,<br>
sin conocer detalles del software ni el ámbito de aplicación.<br>
        A mi también me daría fiaca hacer todo eso... sobre todo cuando se<br>
podría obtener el mismo resultado con menos código: si es estructurado,<br>
querys a las tablas para ahorrarse los store procedures; y si es en<br>
Objetos, escribiendo solo las clases y usando un mapeador<br>
Objeto/Relacional.<br>
<div class="im"><br>
<br>
> Un usuario se crea unicamente gracias a la existencia de una persona.<br>
> Pueden haber personas cargadas en el sistema que aun no posean un<br>
> usuario para acceder al sistema, como así personas que dejaron de ser<br>
> usuarios del sistema en ese caso se cambiara el campo estado del<br>
> usuario a false ( inactivo ).  Los datos personales del usuario que<br>
> una vez se cargaron en el sistema, persistirán y no serán borrados. Al<br>
> tomar esta decision, las entradas nunca tendrán incosistencia al tener<br>
> el campo id_usuario.<br>
<br>
</div>        Te entiendo... pero para esta situación, no sería mejor que Entrada<br>
tenga una referencia a una Persona, que existe siempre??? y solo en caso<br>
de que tenga esto que llamás "usuario" podrá poner una Entrada???<br>
        Cuando pienso tu modelo de datos como entidades, veo más naturalmente<br>
relacionados Entradas -> Personas -> Usuarios, que lo que vos planteás<br>
como Entradas -> Usuarios -> Personas... es meter entre dos entidades<br>
del almacenamiento un RNF...<br>
<div class="im"><br>
> El grant_usage lo ejecute debido a que no me gusta trabajar con el<br>
> usuario root de mi base de datos, en todo caso cuando contrate un<br>
> hosting tendre el usuario evitando ejecutar esa instrucción.<br>
> Unicamente cambiare los datos de acceso en el archivo<br>
> configuracion.php por los datos del hosting.<br>
<br>
</div>        A mi tampoco me gusta trabajar como root: creo usuarios y DBs, y luego<br>
ejecuto las querys en el contexto de la conexión del usuario.<br>
<div class="im"><br>
> Respecto a los objetos me guie bajo el patron de diseño "Active<br>
> Record". Lo vi aplicado en cakephp y me gusto la forma de trabajo.<br>
> Tambien vi que lo usa ruby on rails.<br>
<br>
</div>        Esto no suma ni resta para tu trabajo final, porque no es un tema dado<br>
en el curso.<br>
        En lo personal, los patrones de diseño recomentados son los del GoF y<br>
las extensiones que tiene. El Active Record y el Scaffold son<br>
directamente descartados por los diseñadores (Kent Beck, Wirf-Brook,<br>
Gamma et al, Rumbaugh, Jacobson, Booch, etc) por dar como resultado un<br>
"modelo anémico" y por provocar diseños orientados a los datos en lugar<br>
de orientados al comportamiento.<br>
        Toda esta gente que te nombré ni siquiera considera "patrones" a los<br>
que propone Martin Fowler... y dan sus buenos motivos de por qué no lo<br>
son. Fowler sí tiene importantes contribuciones en el campo de la<br>
integración continua, pero no tanto en arquitectura ni en diseño de<br>
software, si bien tiene cosas publicadas en ese área.<br>
<br>
        Por favor, no cambies tu código por mi comentario de más arriba: quería<br>
aprovechar para contarte superficialmente las contras de esa<br>
aproximación, y las fuentes que pueden orientarte hacia buenos diseños.<br>
<br>
        Porque, que mucha gente lo haga, no significa que esté bien.<br>
        (Gabriel hace unos minutos me decía esto, citando a su profesor de<br>
programación)<br>
<div class="im"><br>
> Estoy modificando los procedimientos almacenados para que paginen.<br>
<br>
</div>        Ok. En el vuelco de la DB que me enviaste, no estaban los<br>
procedimientos almacenados, así que medio los adiviné entre las tablas y<br>
las llamadas en el código.<br>
        Recordá enviármelos la próxima vez!<br>
<div class="im"><br>
> Gracias por las sugerencias. Te mantengo al tanto.<br>
> Cuando termine de acomodar mejor las cosas mando el modelo por la<br>
> lista.<br>
<br>
</div>        Por nada!<br>
        Ya seguiremos charlando de todo esto.<br>
        Me serviría de veras mucho que completes la SRS (parece que hiciste el<br>
software primero, y escribís la SRS después... obviamente no afecta a tu<br>
calificación, pero haciendo las cosas en ese orden, no podés validar tu<br>
software!)<br>
        Recordá también clarificar, mejor dicho, darle un nombre que no sea tan<br>
genérico a tu "usuario", porque si no es muy difícil que descubras<br>
vicios en los datos o en el software, como pareciera ser la relación de<br>
las Entradas con el Usuario en vez de con la Persona.<br>
<br>
> Saludos<br>
<br>
        =mente!<br>
        Que te mejores.<br>
<div class="HOEnZb"><div class="h5"><br>
--<br>
Leonardo Tadei<br>
<a href="mailto:leonardot@pegasusnet.com.ar">leonardot@pegasusnet.com.ar</a><br>
Blog: <a href="http://blog.pegasusnet.com.ar" target="_blank">http://blog.pegasusnet.com.ar</a><br>
Firma pública: <a href="http://www.pegasusnet.com.ar/LeonardoTadei-public.key" target="_blank">http://www.pegasusnet.com.ar/LeonardoTadei-public.key</a><br>
<br>
_______________________________________________<br>
Php-avanzado mailing list<br>
<a href="mailto:Php-avanzado@pato2.fi.mdp.edu.ar">Php-avanzado@pato2.fi.mdp.edu.ar</a><br>
<a href="http://www3.fi.mdp.edu.ar/cgi-bin/mailman/listinfo/php-avanzado" target="_blank">http://www3.fi.mdp.edu.ar/cgi-bin/mailman/listinfo/php-avanzado</a><br>
</div></div></blockquote></div><br></div>