Re: Criterios de diseño

Hi, yo lo veo desde el punto de vista de administracion de archivos, es
decir una base de datos es una relacion de archivos, basicamente se
puede contruir un ejemplo sencillo con un archivo indice y un archivo de
datos, si se borrara el registro "x" por decirlo de una manera
fisicamente, se tendria que reescribir todo el archivo de datos pero sin
el registro "x" claro actualizando tambien el archivo indice, si se
tuviera una cantidad pequeña de registros esto no demoraria tiempo sin
embargo en cantidades grande de registros esto conllevaria un tiempo
innecesario en cierto punto, se maneja el borrado de manera logica por
motivos de velocidad (utilizando una bandera o attributo), pero llegara
un momento en el que se necesite hacer el borrado de manera fisica por
asi decirlo :-P, ya que el archivo creceria considerablemente, lo que en
postgresql hace el vacuum de cierto modo. Yo tampoco soy un usuario
experimentado, espero que esto siva, si me equivoque en algo corrijanme :-P.

bytes, saludos. :-D.

Jaime Casanova wrote:

>On Wed, 16 Feb 2005 11:47:04 -0300, Gustavo Maximiliano Cortez
><patesi(at)gmail(dot)com> wrote:
>
>
>>Muchachos,
>> Tengo duda a la hora de plantear el diseño de una base de datos.
>> Yo se que esto tiene que ver mas que nada, con los criterios de DBA,
>>pero como yo no tengo mucha experiencia, me baso en el diseño planteado
>>por gente con mas experiencia.
>> Un profesor mio de la Universidad, considera que ningun registro
>>(por ejemplo de empleados o clientes) debe ser eliminado de la base de
>>datos, es decir se deberia colocar un atributo como bandera que indique
>>si el registro (de empleados o clientes) debe o no aparecer en el
>>sistema. Por ejemplo, en la interfaz de usuario si hay un boton que dice
>>"eliminar", no significa que elimine el registro de la base de datos,
>>sino que simplemente le de un valor al atributo ya sea 0 o 1 para que
>>"simulara" que el registro esta eliminado.
>>
>>
>>
>Estoy de acuerdo con tu profesor. Primero por que deben haber
>registros relacionados y no creo que quieras borrar las transacciones
>que realizao ese cliente. Y segundo por historia, para mantener un
>registro estadistico de lo que a ocurrido a traves del tiempo.
>
>
>
>>considero que de esta manera estoy haciendo que la base de datos cresca
>>siempre. Es decis, que no hay posibilidad de disminuir su tamaño
>>eliminando registros desde una interfaz de usuario. Y me parece algo
>>poco elegante, ya que en cada consulta para mostrar el listado de
>>registros (por ejemplo de empleados o clientes), deberia hacer el contro
>>de si el atributo puesto como bandera tiene el valor 1 o 0 segun se haya
>>eliminado o no.
>>
>>
>>
>Eso es lo de menos, una buena base de datos ( y postgresql lo es)
>puede manejar millones de registros sin problemas. de hecho hay una
>regla que dice: (no se si postgresql la cumple, ni si alguna otra la
>cumple. pero todos tratan de llegar a esto) que sin importar la
>cantidad de registros a revisar una base de datos no deberia demorarse
>mas de 3 segundos en devolver la informacion.
>
>atentamente,
>Jaime Casanova
>
>---------------------------(fin del mensaje)---------------------------
>TIP 1: para suscribirte y desuscribirte, escribe a majordomo(at)postgresql(dot)org
>
>
>

--
"hechando a perder se aprende"
"yo solo se que no se nada"
Debian Sarge tuxsoul 2.6.10dma #1 Tue Jan 18 10:03:16 CST 2005 i686 GNU/Linux
Intel Celeron (Coppermine) stepping 06
http://www.tuxsoul.com
http://tuxsoul.blogspot.com
http://www.dolric.com
http://www.deblix.com
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS 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 !z
------END GEEK CODE BLOCK------