Una de Bases de datos, borrado lógico o físico?
6,226 views
Skip to first unread message
Iván Rico
Jan 5, 2011, 5:10:43 PM1/5/11
to php-m...@googlegroups.com
Hola a todos,
La pregunta va mas por el lado de diseño de la solución que de codificación en PHP pero igual me parece que es un tema que puede dar de que hablar.
Se trata del borrado de la información o registros en las tablas
He hecho sistemas que cuando se borra la info, realmente lo que hace es un update a un campo estatus, también he hecho otros que hacen un delete.
se que cada necesidad es diferente pero para un sistema de información basico de esos de clientes, proveedores, facturas emitidas y facturas recibidas.
cómo suelen hacerle:
borrado logico usando un campo estatus y usado UPDATE?
borrado fisico con la sentencia DELETE? (en MySQL utilizando innodb podemos explotar la integridad referencial)
que ventajas les da una y la otra.
toda este rollo me surgio por que en estos momentos estoy aplicando borrado logico, pero ya me meti en varios rollos con las tablas que se relacionan dicho registros y creo que me vendría mejor un borrado fisico
ustedes que opinan?
--
Iván Rico
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GE d- s:-- a-- C+++ UL++ P L++ E- W++ N- o-- K- w+
O-- M- V-- PS PE Y-- PGP- t--- 5 X R tv b- DI D----
G e+++ h! r- y+
------END GEEK CODE BLOCK------
www.geekcode.com
Sitio Web: http://ivan.rico.org.mx
Linux User: #340251
Erick Ruiz de Chavez
Jan 5, 2011, 5:15:36 PM1/5/11
to php-m...@googlegroups.com
Segun mi experiencia NUNCA deberias hacer borrado fisico, pero como @igormx llego a comentar por Twitter, la implementacion depende mucho de los Best Practices que sigas, las reglas de tu empresa/proyecto, tus gustos, etc.
Daniel Miranda
Jan 5, 2011, 5:18:38 PM1/5/11
to php-m...@googlegroups.com
Los usuarios siempre encontraran la forma de borrar algo que no debian, si hay un borrado lógico no hay problema por que la informacion sigue alli pero en el caso de un borrado fisico mas vale que tengas un buen log de eventos para evitar que le echen la culpa del borrado al sistema.
2011/1/5 Iván Rico <ivan...@gmail.com>
--
Este correo ha llegado a ti desde la Lista de Correo del Grupo PHP México.
Para cambiar la configuración de tu suscripción visita: http://grupo.phpmexico.mx/
* Visita nuestro sitio: http://phpmexico.mx/
* Síguenos en Twitter: http://twitter.com/phpmx
* Únete al Grupo de Facebook: http://www.facebook.com/pages/PHP-Mexico/137017066340686
Juan José González
Jan 5, 2011, 5:20:30 PM1/5/11
to php-m...@googlegroups.com
Para las soluciones que van destinados al cliente promedio recomiendo encarecidamente un borrado lógico pues siempre sale el listo que te dice "borré esos registros accidentalmente, pero de seguro los puedes sacar de nuevo" además hay relaciones que se rompen si borras registros piensa en este caso "fulano compra dos sandias rojas del japón y un mes después la tienda ya no maneja las sandias rojas del japón asi que deciden borrarla del inventario" ¿qué pasará cuando quiera saber qué compró fulano hace un mes? ¿y si las sandias rojas del japón eran el producto más vendido, cómo recomendará tu sistema al usuario que las siga vendiendo?
A la fecha el espacio no es problema, asi que guarda todo lo que necesites. En general piensa por default en borrado lógico y sólo cuando veas que la situación lo amerita usa el borrado físico.
A lo que dices de la complejidad del código intenta hacer la funcionalidad de borrado lógico en una clase donde puedes encapsular el proceso y coonviertela en padre de todos los que la necesiten (modelos) así reducirás el trabajo, escribiendo y manteniéndo un sólo código, suerte.
A la fecha el espacio no es problema, asi que guarda todo lo que necesites. En general piensa por default en borrado lógico y sólo cuando veas que la situación lo amerita usa el borrado físico.
A lo que dices de la complejidad del código intenta hacer la funcionalidad de borrado lógico en una clase donde puedes encapsular el proceso y coonviertela en padre de todos los que la necesiten (modelos) así reducirás el trabajo, escribiendo y manteniéndo un sólo código, suerte.
Iván Rico
Jan 5, 2011, 5:41:02 PM1/5/11
to php-m...@googlegroups.com
muy interesantes las respuestas
aunque...
Lo del último párrafo no me quedo claro lo que intentas decir, pudieras ponerlo de otra manera???
saludos
aunque...
Lo del último párrafo no me quedo claro lo que intentas decir, pudieras ponerlo de otra manera???
saludos
pablopazos
Jan 5, 2011, 7:55:54 PM1/5/11
to PHP México
Todo depende de los requerimientos de cada proyecto.
No hay mejor o peor, depende de cada proyecto.
Si es requerimiento que en la base de datos solo estén los datos
"activos", borrado físico es bueno.
Si necesitas hacer muchos logs de las altas, bajas y modificaciones,
sabiendo que se dio de alta o baja, por quién y en qué momento,
borrado lógico es lo ideal, por que puedes asociar a la información de
cada log, cuál registros se dieron de baja, y tienes toda la
información que necesitas para auditoría.
Por ejemplo, en un proyecto de historia clínica electrónica, el
borrado físico no existe. Los datos clínicos de las personas no deben
borrarse nunca, aunque haya un error en el ingreso. Pero un sistema de
un video club, tal vez si ya no tienes una película por renovación del
stock, borrado físico sea útil.
En cuanto a tu problema en particular, debes ver en el diseño ante el
borrado de un registro, se debería o no hacer el borrado de los
registros asociados. O sea si el registro representa una entidad
fuerte o una débil (que depende de otras entidades fuertes para
existir). Luego de ese análisis, al hacer borrado lógico o físico
deberías obtener el mismo resultado. Si tienes problemas debe ser
porque no estás borrando lógicamente los registros de entidades
débiles asociados a los registros de entidades fuertes que si estás
borrando de forma lógica. Pienso que es más un problema de diseño que
del tipo de borrado (repito que el resultado para tu sistema,
independientemente de cómo borras, debería ser el mismo).
Mi granito de arena.
Saludos,
Pablo.
http://yuppframework.blogspot.com/
No hay mejor o peor, depende de cada proyecto.
Si es requerimiento que en la base de datos solo estén los datos
"activos", borrado físico es bueno.
Si necesitas hacer muchos logs de las altas, bajas y modificaciones,
sabiendo que se dio de alta o baja, por quién y en qué momento,
borrado lógico es lo ideal, por que puedes asociar a la información de
cada log, cuál registros se dieron de baja, y tienes toda la
información que necesitas para auditoría.
Por ejemplo, en un proyecto de historia clínica electrónica, el
borrado físico no existe. Los datos clínicos de las personas no deben
borrarse nunca, aunque haya un error en el ingreso. Pero un sistema de
un video club, tal vez si ya no tienes una película por renovación del
stock, borrado físico sea útil.
En cuanto a tu problema en particular, debes ver en el diseño ante el
borrado de un registro, se debería o no hacer el borrado de los
registros asociados. O sea si el registro representa una entidad
fuerte o una débil (que depende de otras entidades fuertes para
existir). Luego de ese análisis, al hacer borrado lógico o físico
deberías obtener el mismo resultado. Si tienes problemas debe ser
porque no estás borrando lógicamente los registros de entidades
débiles asociados a los registros de entidades fuertes que si estás
borrando de forma lógica. Pienso que es más un problema de diseño que
del tipo de borrado (repito que el resultado para tu sistema,
independientemente de cómo borras, debería ser el mismo).
Mi granito de arena.
Saludos,
Pablo.
http://yuppframework.blogspot.com/
pablopazos
Jan 5, 2011, 8:00:18 PM1/5/11
to PHP México
O_O
Estimado, me preocupa tu comentario. Si el usuario puede borrar algo,
es porque el sistema se lo deja.
Si el sistema fue diseñado para borrar registros, entonces el usuario
no borra ningún registro por accidente, tiene la funcionalidad
disponible y se supone que fue capacitado para saber lo que puede o no
hacer con el sistema.
Una de dos, o no se diseña el sistema para proveer borrado a usuarios
que no deberían borrar registros, o se agrega la funcionalidad de
recuperar registros, a modo de "papelera de reciclaje". Entonces, en
cualquiera de los casos, con un usuario debidamente capacitado, el
borrado por error no existiría.
Saludos,
Pablo.
http://yuppframework.blogspot.com/
On 5 ene, 20:18, Daniel Miranda <danmira...@gmail.com> wrote:
> Los usuarios siempre encontraran la forma de borrar algo que no debian, si
> hay un borrado lógico no hay problema por que la informacion sigue alli pero
> en el caso de un borrado fisico mas vale que tengas un buen log de eventos
> para evitar que le echen la culpa del borrado al sistema.
>
> 2011/1/5 Iván Rico <ivan.r...@gmail.com>
Estimado, me preocupa tu comentario. Si el usuario puede borrar algo,
es porque el sistema se lo deja.
Si el sistema fue diseñado para borrar registros, entonces el usuario
no borra ningún registro por accidente, tiene la funcionalidad
disponible y se supone que fue capacitado para saber lo que puede o no
hacer con el sistema.
Una de dos, o no se diseña el sistema para proveer borrado a usuarios
que no deberían borrar registros, o se agrega la funcionalidad de
recuperar registros, a modo de "papelera de reciclaje". Entonces, en
cualquiera de los casos, con un usuario debidamente capacitado, el
borrado por error no existiría.
Saludos,
Pablo.
http://yuppframework.blogspot.com/
On 5 ene, 20:18, Daniel Miranda <danmira...@gmail.com> wrote:
> Los usuarios siempre encontraran la forma de borrar algo que no debian, si
> hay un borrado lógico no hay problema por que la informacion sigue alli pero
> en el caso de un borrado fisico mas vale que tengas un buen log de eventos
> para evitar que le echen la culpa del borrado al sistema.
>
Iván Rico
Jan 6, 2011, 10:17:01 AM1/6/11
to php-m...@googlegroups.com
Damas y Caballeros ( ¿BTW hay chicas PHPeras aquí?)
El motivo de este hilo es para conocer las practicas que se suelen manejar y hacer de todas un supermega práctica.
Con los comentarios leidos aquí y en otros foros en la red, casi todo apunta al borrado lógico y esto me lleva a pensar que la
integridad referencial nuca es explotada, aunque puede ser que yo tenga un concepto erroneo de uso la integridad referencial.
Básicamente mi duda comienza porque precisamente estoy haciendo una BD con innodb utilizando llaves foraneas y todo ese rollo mareador, y al estar escribiendo las validaciones para el borrado lógico creo que estoy desaprovechando esto de las llaves foraneas, por que un simple DELETE tendrá su commit si el registro esta abandonado.
=======================================================================================
Pondré un pequeño ejemplo para explicarme y dar a conocer a donde quiero llegar:
Si tenemos nuestra tabla de
ESTADOS
y requerimos registrar el Domicilio del Cliente entonces tenemos nuestra tabla
DOMICILIOS
Ademas necesitamos registrar Lugar de Nacimiento entonces tenemos nuestra tabla
DATOS_DE_NACIMIENTO
ambas tablas se relacionan con Estado de uno muchos
Utilizando la integridad referencial (llaves foraneas, motor innodb en mysql)
El día que yo quiera borrar (DELETE FROM ) un registro ya utilizado de ESTADO, el mysql arrojará un error diciendo que no se puede porque DOMICILIOS y/o DATOS_DE_NACIMIENTO estan relacionadas. (no estoy usando borrado en cascada)
ya con eso puedo estar tranquilo de que el usuario no cometerá alguna burrada.
En un caso donde el usuario Captura el registro: Nuvo Lon (le falla la tecla "e") en ESTADOS
se da cuenta de su error e inmediatamente pincha el botón de borrar, y como este registro no se ha relacionado en otras tablas, el mysql ejecutará la instrucción y hará el DELETE
mi criterio en este tipo de relaciones es detener la instrucción cuando se haga un DELETE, ya que eso de borrado en cascada no me late.
¿Qué pasaría si no tuviera integridad referencial?
Antes de la operación de DELETE debo consultar si ese registro existe en las tablas de DATOS_DE_NACIMIENTO y DOMICILIOS para decidir si se puede borrar o no, y aquí es dónde _yo_ optaría por el borrado logico es decir hacer un UPDATE.
Lo que me paniquea de este metodo es que si el sistema se le agrega un modulo de pagos en dónde hay que registrar lugar donde pago, entonces hay que agregar a la validación anterior una tercera consulta y si a mi o al programador de ese momento se le olvida, se comenzará a tener falta de integridad en el sistema.
=======================================================================================
ando bien o ustedes opinan que ando miando fuera del hoyo?
Saludos
@7th_Sign
El motivo de este hilo es para conocer las practicas que se suelen manejar y hacer de todas un supermega práctica.
Con los comentarios leidos aquí y en otros foros en la red, casi todo apunta al borrado lógico y esto me lleva a pensar que la
integridad referencial nuca es explotada, aunque puede ser que yo tenga un concepto erroneo de uso la integridad referencial.
Básicamente mi duda comienza porque precisamente estoy haciendo una BD con innodb utilizando llaves foraneas y todo ese rollo mareador, y al estar escribiendo las validaciones para el borrado lógico creo que estoy desaprovechando esto de las llaves foraneas, por que un simple DELETE tendrá su commit si el registro esta abandonado.
=======================================================================================
Pondré un pequeño ejemplo para explicarme y dar a conocer a donde quiero llegar:
Si tenemos nuestra tabla de
ESTADOS
y requerimos registrar el Domicilio del Cliente entonces tenemos nuestra tabla
DOMICILIOS
Ademas necesitamos registrar Lugar de Nacimiento entonces tenemos nuestra tabla
DATOS_DE_NACIMIENTO
ambas tablas se relacionan con Estado de uno muchos
Utilizando la integridad referencial (llaves foraneas, motor innodb en mysql)
El día que yo quiera borrar (DELETE FROM ) un registro ya utilizado de ESTADO, el mysql arrojará un error diciendo que no se puede porque DOMICILIOS y/o DATOS_DE_NACIMIENTO estan relacionadas. (no estoy usando borrado en cascada)
ya con eso puedo estar tranquilo de que el usuario no cometerá alguna burrada.
En un caso donde el usuario Captura el registro: Nuvo Lon (le falla la tecla "e") en ESTADOS
se da cuenta de su error e inmediatamente pincha el botón de borrar, y como este registro no se ha relacionado en otras tablas, el mysql ejecutará la instrucción y hará el DELETE
mi criterio en este tipo de relaciones es detener la instrucción cuando se haga un DELETE, ya que eso de borrado en cascada no me late.
¿Qué pasaría si no tuviera integridad referencial?
Antes de la operación de DELETE debo consultar si ese registro existe en las tablas de DATOS_DE_NACIMIENTO y DOMICILIOS para decidir si se puede borrar o no, y aquí es dónde _yo_ optaría por el borrado logico es decir hacer un UPDATE.
Lo que me paniquea de este metodo es que si el sistema se le agrega un modulo de pagos en dónde hay que registrar lugar donde pago, entonces hay que agregar a la validación anterior una tercera consulta y si a mi o al programador de ese momento se le olvida, se comenzará a tener falta de integridad en el sistema.
=======================================================================================
ando bien o ustedes opinan que ando miando fuera del hoyo?
Saludos
@7th_Sign
Armando Argel Arias Castañeda
Jan 6, 2011, 10:25:35 AM1/6/11
to php-m...@googlegroups.com
¿Hay forma se saber si algo puede ser borrado via MySQL sin
necesariamente estarlo borrando?
necesariamente estarlo borrando?
PD: En caso de tablas de catalogo ya que son una entidad debil, sí
puedes hacer delete y aprovechar el sistema de integridad referencial.
--
La Libertad viene en paquetes pequeños, generalmente TCP/IP
Argel Arias <argel...@levhita.net>
http://levhita.net
http://twitter.com/levhita
http://facebook.com/levhita
http://levhita.deviantart.com
Luis Zaldivar
Jan 6, 2011, 10:35:03 AM1/6/11
to php-m...@googlegroups.com
El problema no es tecnico, es de negocio.
Tecnicamente el borrado logico o fisico funciona igual (siempre y cuan lo hagas bien).
Pero en ocasiones es muy probable que el cliente requiera recuperar informacion o regresar a alguna version anterior de la informacion. Una opcion si te lo permite, otra no. asi de simple.
Tecnicamente el borrado logico o fisico funciona igual (siempre y cuan lo hagas bien).
Pero en ocasiones es muy probable que el cliente requiera recuperar informacion o regresar a alguna version anterior de la informacion. Una opcion si te lo permite, otra no. asi de simple.
Genaro Contreras
Jan 6, 2011, 11:13:58 AM1/6/11
to php-m...@googlegroups.com
para eso existen los respaldos que periódicamente se deben de hacer de una base de datos. José Genaro Contreras Ocampo.
Jorge Ramírez
Jan 6, 2011, 11:17:16 AM1/6/11
to php-m...@googlegroups.com
Les comentaré lo que yo comúnmente hago en mis proyectos.
Como muchos han comentado, dependerá de los requerimientos propios del proyecto.
En la mayoría de mis proyectos pequeños utilizo MyISAM (Hosting compartido) y como todos saben, este no soporta integridad referencial. Ahora bien, siempre utilizo tres niveles de usuarios, solo 1 de ellos tiene derecho a borrar los registros en caso de ser necesario y de ser borrados sigo 3 caminos:
1.- Para aquellos datos críticos como por ejemplo catalogo de productos ('sandías rojas japonesas') catalogo de clientes('juan perez') utilizo 'triggers' para poder evitar el borrado físico. Ejemplo: cuando alguien intenta borrar el producto 'sandias rojas japonesas' o el cliente 'juan perez' se ejecuta un 'trigger' para verificar que los ID's en cuestión no existan por lo menos en la tabla Hijo más importante como es el caso de VENTAS, de existir me regresan un mensaje diciendome que estoy por dejar huerfanos a varios registros en la tabla VENTAS.
2.- En el caso de los catálogos secundarios como lo son: Conceptos, Tipos, Propiedades, etc, suelo utilizar borrado lógico ya que comúnmente estos catálogos no variaran mucho en su contenido durante la vida del proyecto.
3.- En el caso de los catálogos fijos como lo son: Estados, Paises, Lenguajes, Monedas, Formatos, no suelo utilizar la opción de borrado del lado del usuario, ya que en la mayoria de las cosas son datos fijos y existe el 0.01% de que sean borrados, en su lugar utilizo un estatus de que si el cliente quiere o no que se visualize en el dato en cuestion.
Por otro lado, en un proyecto que actualmente estamos trabajando y que esta pensado para entrar al mundo del Cloud Computing (hosting dedicado), estamos utilizando InnoDB, ya que esto nos permitirá tener una mejor integridad en nuestros registros debido a que no solo será un cliente, por el contrario serán varios utilizando la misma base de datos, sin embargo hay que tomar en cuenta que con el uso de la Integridad Referencial en InnoDB le haces mas grande la chamba al servidor y este caso ya entra el hardware en juego.
Al final de cuentas, todo dependerá de las caracteristicas del proyecto, entre más grande sea este, más necesitaras el uso de integridad referencial ya que si no lo haces, todo caerá en una palabra de 4 letras :) CAOS por tener tantos registros huerfanos.
Saludos.
Jorge Ramírez.
PD: por cierto respondiendo a la pregunta de Ivan Rico, creo que no nay chicas PHPeras, o si?
Genaro Contreras
Jan 6, 2011, 11:19:04 AM1/6/11
to php-m...@googlegroups.com
PD: por cierto respondiendo a la pregunta de Ivan Rico, creo que no nay chicas PHPeras, o si?
Iván Rico
Jan 6, 2011, 11:19:21 AM1/6/11
to php-m...@googlegroups.com
Argel Arias, lo mismo se me había ocurrido, conocer si se puede borrar pero no borrarlo, creo que las transacciones pueden ser utilidad para este caso, pero mi infimo conocimiento en MySQL no me permite implementarlo
mi logica sería:
STAR TRANSACTION
DELETE FROM TABLA WHERE XXXX
ROLLBACK
IF SUCCESS THEN
UPDATE
ELSE
RAISE ERROR('NO SE PUEDE')
END IF;
alguien puede confirmar si esto puede aplicar??
mi logica sería:
STAR TRANSACTION
DELETE FROM TABLA WHERE XXXX
ROLLBACK
IF SUCCESS THEN
UPDATE
ELSE
RAISE ERROR('NO SE PUEDE')
END IF;
alguien puede confirmar si esto puede aplicar??
El 6 de enero de 2011 10:13, Genaro Contreras <jgn...@gmail.com> escribió:
pAk0s
Jan 6, 2011, 11:20:00 AM1/6/11
to PHP México
@Iván Rico llegas a una interesante conclusión, pero como ya se dijo
depende de.. la funcionalidad de borrado en cascada tiene esa
protección e inconvenientes que se mencionan aunque el programador
debe de analizar el error para saber por que se ha generado y dar un
mensaje de por que no se puede eliminar el registro humanamente
compresible para el usuario final, creo que es mas factible el borrado
lógico y este pude pasar a ser un borrado físico en un proceso de
mantenimiento de borrar los registros que son basura y lo que no los
deja ya... otra salida hacer uso stored procedures y transacciones,
también el usar OOP puede simplificar el mantenimiento y la
escalabilidad del sistema ya que el Delete ya sea lógico o fisco se
encapsula en este método especifico solo tendrías que documentar al
equipo de desarrolladores de la existencia dela Clase/método y como se
debe de hacer el eliminado
Luis Zaldivar
Jan 6, 2011, 11:23:02 AM1/6/11
to php-m...@googlegroups.com
A menos que hagas un respaldo tras cada transaccion, hay informacion
en la que no podrias volver atras.
Luis Zaldivar
Jan 6, 2011, 11:24:20 AM1/6/11
to php-m...@googlegroups.com
Una de las cosas que me hacen que el ojo me brinque.
Cloud computing no es hosting dedicado.
Just saying.
Cloud computing no es hosting dedicado.
Just saying.
Iván Rico
Jan 6, 2011, 11:24:46 AM1/6/11
to php-m...@googlegroups.com
@Genaro Contreras jalalas para aca a esas chicas, para que participen en el movimiento php-mexico
Ricardo Rivas
Jan 6, 2011, 11:34:46 AM1/6/11
to php-m...@googlegroups.com
Borrado lógico o Físico:
Creo que es cuestión de la necesidad del proyecto, espacio de almacenamiento en el servidor y un poco de gusto del desarrollador. Tienes que sentarte a meditar con calma.
Si usas borrado lógico, puede llegar a pasar que borren un montón de registros y quien lo hizo no recuerde cuales eran!! Lo que te causara problemas administrativos. Tu como desarrollador puedes recuperar los registros fácilmente, pero el problema fue de capa 8. A mi me paso en un CRM que el gerente tiene permisos de hacer todo, y como veía muchas tareas pendientes que no eran de el, entonces pensó: "hay todas estas tareas que!! las borrare" y borro todas las tareas de toda la empresa!! 0_0 . Gracias a un log descubrimos quien fue, y gracias al respaldo automatico de las 5 am recuperamos la tabla de tareas.
Lo mas recomendable a mi humilde punto de vista!! Es ser obsesivo en cuanto a logs y respaldos de los respaldos. A mi me gusta hacer un dump diario de la base de datos, ya sea con tarea de cron o tarea programada (en windows). Ademas crear un log donde guarde registros de las actividades importates y/o peligrosas, porque repito "aunque sea borrado lógico es peligro BORRAR".
Creo que es cuestión de la necesidad del proyecto, espacio de almacenamiento en el servidor y un poco de gusto del desarrollador. Tienes que sentarte a meditar con calma.
Si usas borrado lógico, puede llegar a pasar que borren un montón de registros y quien lo hizo no recuerde cuales eran!! Lo que te causara problemas administrativos. Tu como desarrollador puedes recuperar los registros fácilmente, pero el problema fue de capa 8. A mi me paso en un CRM que el gerente tiene permisos de hacer todo, y como veía muchas tareas pendientes que no eran de el, entonces pensó: "hay todas estas tareas que!! las borrare" y borro todas las tareas de toda la empresa!! 0_0 . Gracias a un log descubrimos quien fue, y gracias al respaldo automatico de las 5 am recuperamos la tabla de tareas.
Lo mas recomendable a mi humilde punto de vista!! Es ser obsesivo en cuanto a logs y respaldos de los respaldos. A mi me gusta hacer un dump diario de la base de datos, ya sea con tarea de cron o tarea programada (en windows). Ademas crear un log donde guarde registros de las actividades importates y/o peligrosas, porque repito "aunque sea borrado lógico es peligro BORRAR".
Todo es tu decisión a fin de cuentas...
Por cierto!! " Gracias a todos por su participación en este hilo :D "
El 6 de enero de 2011 10:13, Genaro Contreras <jgn...@gmail.com> escribió:
Jorge Ramírez
Jan 6, 2011, 11:36:20 AM1/6/11
to php-m...@googlegroups.com
Es muy cierto lo que comenta Luis Zaldivar, Cloud computing NO es hosting dedicado, lo que quise decir es que ese proyecto en particular se aloja en un servidor dedicado y los pequeños en Hosting compartido :)
Iván Rico
Jan 6, 2011, 11:40:24 AM1/6/11
to php-m...@googlegroups.com
Pues a usar borrado lógico, pero tambien me agrada la opción 3 que dio Jorge Ramirez, no permitir el borrado por el lado del usuario aunque sea lógico
Este post me abre un poco mas la perspectiva sobre el tema
http://www.dosideas.com/noticias/base-de-datos/712-no-se-recomienda-borrar-datos.html
Iván Rico
Jan 10, 2011, 11:30:06 AM1/10/11
to php-m...@googlegroups.com
Raza, pues ya por fin encontré la respuesta mi pregunta y es aplicable para todos los proyectos (bueno... eso creo).
aprovecho para hacer un comercial de mi página ya que en la última entrada describo la solución.
http://ivan.rico.org.mx
chequenla.
se aceptan criticas constructivas y también destructivas (¿por qué no? ) xD
saludos
aprovecho para hacer un comercial de mi página ya que en la última entrada describo la solución.
http://ivan.rico.org.mx
chequenla.
se aceptan criticas constructivas y también destructivas (¿por qué no? ) xD
saludos
Armando Argel Arias Castañeda
Jan 10, 2011, 12:32:27 PM1/10/11
to php-m...@googlegroups.com
Pues señor que buena implementación se chuto, me gusta el concepto, demasiado.
2011/1/10 Iván Rico <ivan...@gmail.com>:
--
Reply all
Reply to author
Forward
0 new messages