framework - pymongo django
qué diagrama usar en NoSql(Mcd, Merise, UML) (1)
de nuevo, disculpe mi tonta pregunta, pero parece que lo que aprendí de la Base de datos de relaciones debe ser "borrado", no hay uniones, así que ¿cómo diablos dibujaré el uso de Merise y UML en NoSql?
http://en.wikipedia.org/wiki/Class_diagram
este no funcionará para NoSql?
Cómo organizas tu proyecto es una noción independiente de la tecnología utilizada para la persistencia; En particular; UML o ERD o cualquier herramienta de este tipo no se aplica particularmente a las bases de datos relacionales más de lo que lo hace a las bases de datos de documentos.
La idea de que NoSQL tenga "No Joins" es a la vez tonto e inútil. Es totalmente correcto que (la mayoría de las bases de datos de documentos no proporcionen un operador de unión; pero eso solo significa que cuando necesitas un join, lo haces en el código de la aplicación en lugar del idioma de la consulta; Los hechos básicos de organizar su proyecto siguen siendo los mismos.
Otra diferencia es que las bases de datos de documentos hacen que expresar algunas cosas sea más fácil y otras cosas más difíciles. Por ejemplo, a menudo es más fácil una restricción de relación de entidad en una base de datos relacional, pero es más fácil expresar una jerarquía de herencia en una base de datos de documentos. Ambas tecnologías pueden ser compatibles con ambas nociones, y seguramente las usará cuando su aplicación las necesite; independientemente de la tecnología que termines usando.
En resumen, debe diseñar su aplicación sin elegir primero una tecnología de persistencia. Una vez que tenga una buena idea de lo que desea persistir, es posible que tenga una mejor idea de qué tecnología se adapta mejor. Puede ser que lo que realmente necesite sea ambos, o podría necesitar algo totalmente diferente de cualquiera.
EDITAR : La idea de una clave externa no es más mágica que simplemente decir "Este es un nombre de ese tipo de cosas". Sucede que muchas bases de datos SQL proporcionan algunas características muy escuetas y útiles para tratar este tipo de cosas; específicamente, restricciones (esta columna hace referencia a esta otra relación, por lo que no puede tomar un valor a menos que haya una fila correspondiente en el referant), y cascadas, (si el estado del referente cambia, haga el cambio correspondiente a la referencia). Esto hace que sea fácil mantener la coherencia de los datos, incluso en el nivel más bajo, ya que no hay forma de decirle a la base de datos que ingrese un estado donde falta el referente.
Sin embargo, lo importante de distinguir es que la idea de proporcionar una entidad de base de datos (una fila en una base de datos relacional, documento en bases de datos de documentos) es distinta de la noción de restricciones de esquema. Una de las cosas buenas de las bases de datos de documentos es que pueden combinarse o reorientarse fácilmente donde viven los datos, de modo que no siempre se necesita un identificador que realmente exista; La mayoría de las bases de datos de documentos usan la clase de documento como parte de la clave, por lo que aún puede estar seguro de que la clave es significativa, incluso si el referente no existe realmente.
Pero la mayoría de las veces, realmente quieres que el referente exista; no desea que una publicación de blog tenga un autor a menos que ese autor realmente exista en su sistema. Lo bien que esto se soporta depende mucho de la base de datos de documentos en particular; Algunas bases de datos proporcionan desencadenantes, u otras herramientas, para hacer cumplir la integridad de la referencia, pero muchas otras solo proporcionan algún tipo de capacidad transaccional, que requiere que la integridad se aplique en la aplicación.
La cuestión es; para la mayoría de los tipos de base de datos, cada valor en la base de datos tiene algún tipo de identificador; en una base de datos relacional, eso es un triple de relación: columna: clave; y en una base de datos documental suele ser algo así como el par document_class: path. Cuando necesita una entidad para referirse a otra, utiliza cualquier tipo de clave que necesite para identificar ese dato para ese tipo de base de datos. Las restricciones de clave externa encontradas en RDBMses son simplemente (realmente útiles) azúcar sintáctico para "si no existe el referéndum existe entonces subir ForeignKeyError", que podría implementarse con la misma potencia de otras maneras, si eso es útil para su uso particular.