On 7/27/07, Horst H. von Brand <[EMAIL PROTECTED]> wrote: > Aldrin Gonzalo Martoq Ahumada <[EMAIL PROTECTED]> wrote: > > On 7/26/07, Horst H. von Brand <[EMAIL PROTECTED]> wrote: > > [...] > > > > BerkeleyDB [...] tambien hay que considerarlo... y nunca olvidar > > > SQLite <http://www.sqlite.org>. > > > Siempre he tenido encuentros malos con bdb y similares: > > - RPM corruptos obligandote a hacer magia o reinstalar todo [DEB usa > > archivos planos] > > No es RPM corruptos, es base de datos de RPM corrupta. Y eso era en > encarnaciones previas de BDB, que no manejaba transacciones y > rollback. Hace /mucho/ que ya no pasa. > > > - Subversion destrozados (SI, el historial y trabajo de meses de > > codigo a punto de desaparecer) [Ahora FSFS es el backend por omision] > > Mejor usa un SCM de verdad, como git ;-) > > > - LDAP corrupto y sin poder leer ningun maldito registro [menos mal > > hay un backend sql, espero enchufarlos a un postgresql desde ahora]
El backend BDB en openldap se puede "tunear" para optimizar la base de datos, quizas por ahi está tú problema de corrupción de base de datos, es mejor co nfigurar las opciones de la BDB de manera nativa y no usando directivas del archivo slapd.conf > BDB sigue siendo lejos mas rapido... aunque probablemente no haga > diferencia. En todo caso, LDAP es un /directorio/, no una /base de > datos/, los requisitos son parecidos pero no iguales. > > > - ... y otros ejemplos que no recuerdo ... > > > En definitiva: siempre que una aplicacion con backend BDB falla he > > tenido que rezar para recuperar los datos y rehacer lo que quedo fuera > > del respaldo, como dijo Daniel Serpell. > > > > Con mi historial de dramas, yo dejaria fuera cualquier sistema que use BDB. > > Mira las ultimas versiones de esa cosa. > -- > Dr. Horst H. von Brand User #22616 counter.li.org > Departamento de Informatica Fono: +56 32 2654431 > Universidad Tecnica Federico Santa Maria +56 32 2654239 > Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 >
