MyOODB: base de datos orientada a objetos

ByLuis

MyOODB (Java) es una base de datos orientada a objetos, forma parte de un SDK, que junto a MyOOWEB y MyOOSDK, permite realizar aplicaciones web pequeñas pero muy robustas.
Dispone de un cliente que permite acceder a los datos mediante los protocolos TCP, TCPS, HTTP o HTTPS. A diferencia de otras OODB, en este caso los objetos solo existen en el servidor, en la aplicación solo se tratan de objetos distribuidos.
Otra de las características a destacar es que tiene un sistema de anti-corrupción de datos, si unos bloques del sistema de ficheros están corruptos, no se pierde la BD.
MyOODB

Similar Posts

Comparativa de Data Stores

ByLuis

Entendiendo por Data Stores los sistemas de almacenamiento tanto RDBMS o NoSQL, el PDF que referencio compara los distintos tipos de data stores que hay:

  • Almacenamientos clave-valor
  • Almacenamiento de documentos
  • Similares al BigTable de Google
  • BD relacionales escalables

De cada tipo de data store explica cuales son y que características tiene, y por último hace comparativa entre ellos. También nos dice posibles ejemplos de uso:

  • Sistemas clave-valor: útil cuando los datos almacenados se basan en el acceso de información mediante un ID (sin joins) y que se actualiza pocas veces o se actualiza siempre de la misma manera.
  • Almacenamiento de documentos: cuando la información almacenada depende de varios campos (por ejemplo un stock de vehículos).
  • Sistemas basados en BigTable: se puede tratar de aplicaciones similares a los almacenamientos documentales, pero con la diferencia de que es necesario un elevado número de registros.
  • RDBMS escalables: cuando nuestra aplicación necesita de relaciones entre distintos datos y nuestro servidor se queda corto para aguantar el volumen de datos o de transacciones.

Me gustaría destacar que entre estos data store, se encuentra Cassandra, proyecto open source de Facebook, que ahora es un proyecto de Apache y que Twitter va a usar para sustituir MySQL.

High Performance Scalable Data Stores

Cuando no hay que normalizar la base de datos

ByLuis

La normalización es el proceso por el cual se optimizan las tablas de una base de datos para que no haya datos redundantes, se optimice el espacio en disco y se evite errores en la actualización de datos. Ahora bien, aunque la normalización es el estado idóneo para la base de datos, eso no quiere decir que sea el más idóneo para nuestra aplicación.
Existen un caso perfecto cuando la normalización no es adecuada y es cuando la obtención de datos es lenta. Si normalizamos y eso implica que para obtener los datos tengamos que realizar varios joins, al haber muchos datos puede darse la situación de que las consultas sean lentas.
Algo parecido nos ha pasado en Bitacoras.com, ha sido necesario desnormalizar para mejorar la velocidad de respuesta. Imaginaros, teníamos que mostrar dentro de la Comunidad de los usuarios los posts de los usuarios a los que sigues y su actividad (tal sigue a cual).
Como se puede apreciar son datos totalmente distintos y lógicamente van en tablas diferentes, y a parte hay que obtener los datos de los usuarios a los que se sigue y usarlos para obtener sus posts (de todas sus bitácoras) y sus actividades y ordenarlos por fecha descendiente. Solo de leerlo ya me aparecen unos cuantos joins por la mente.
La solución ha sido crear una tabla de enlaces a ids de otras tablas. En la misma tabla tengo enlaces a los posts y a las actividades y a los ids de los usuarios. Es más rápido (unas 300 veces) debido a que existe paginación y es preferible obtener ids de dos tablas en una consulta sencilla y luego obtener n registros sencillos, que obtenerlo en una única consulta.
Otra cosa que he observado es que puede ser más rápido obtener una lista de IDs (sacadas de una consulta) y luego comparar haciendo un IN que hacer un join de dos tablas, cuando una de estas tablas se obtiene mediante una consulta.
Al final lo que nos queda es que la teoría no es siempre válida y que las situaciones en las que nos podemos encontrar hacen que la solución menos elegante sea la más efectiva

|

PHPillow: librería PHP para CouchDB

ByLuis

PHPillow es una librería PHP que nos permite interactuar con CouchDB (base de datos documental de Apache basada en JSON).

Ahora que el NoSQL es una alternativa a las bases de datos relacionales, esta librería nos ayudará bastante a la hora de realizar nuestra aplicación, ya que el código es bastante sencillo.

class myBlogDocument extends phpillowDocument { 
  protected static $type = 'blog_entry'; 
  protected $requiredProperties = array( 'title', 'text', ); 
  public function __construct() { 
    $this->properties = array( 
      'title' => new phpillowStringValidator(), 
      'text' => new phpillowTextValidator(), 
      'comments' => new phpillowDocumentArrayValidator( 'myBlogComments' )
    ); 
    parent::__construct(); 
  } 
  protected function generateId() { 
    return $this->stringToId( $this->storage->title ); 
  } 
  protected function getType() { 
    return self::$type; 
  } 
}

PHPillow

| |

Usar polimorfismo en PHP5 para acceder a diferentes BD

ByLuis

Gracias al tratamiento de objetos que nos permite PHP5, es posible diseñar aplicaciones de una forma más eficiente. Un caso de ello es el polimorfismo, lo cual va a permitir acceder y trabajar con diferentes tipos de bases de datos de una forma única.
En el artículo en el que hacemos referencia, explican detalladamente cómo usar el polimorfismo para acceder a datos mediante MySQL y SQLite. Para ello se crearán una clase abstracta y dos clases que extenderán de esta, siendo cada una de estas las encargadas de tratar el acceso a MySQL o a SQLite.
Después se deberá crear una clase que maneje estas clases, dependiendo de un parámetro, se usará una de las clases (MySQL o SQLite). Esta última clase será la que instancie el usuario final, por lo que para él será transparente el tratamiento que se haga de una u otra base de datos.
Algo que también destacaría de este artículo es la forma de no hacerlo, algo que me he encontrado en alguna ocasión en Java (donde hay polimorfismo desde siempre). La forma incorrecta de hacerlo es creando una única clase y diferenciando en cada método diferentes códigos dependiendo de si se trata de una BD u otra.
Abstracting Database Access Using Polymorphism with Objects in PHP 5

|

Juntion PHP: capa de persistencia de datos

ByLuis

junction.pngJuntion PHP es una capa de persistencia de datos desarrollada por la gente de Zend. Para aquellos que no les suene qué es una capa de persistencia de datos, diremos que se trata de una capa intermedia en nuestra aplicación que ofrece servicios de persistencia
y recuperación de información a las capas superiores.
Junction mapea la base de datos a objetos, permitiendo al desarrollador concentrarse en otros detalles de la aplicación. Debido a ello no nos tendremos que preocupar más en las sentencias CRUD.
Además de lo dicho anteriormente, Junction por ahora permite cláusulas WHERE sencillas, configuración de la base de datos, capa DAO, tests y buena documentación ya sea en el código como para el usuario final.
Juntion PHP
Vía / PHPDeveloper.org