Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Propuesta de modelo #3

Open
larous25 opened this issue Mar 21, 2015 · 3 comments
Open

Propuesta de modelo #3

larous25 opened this issue Mar 21, 2015 · 3 comments

Comments

@larous25
Copy link
Contributor

Buenas tengo una propuesta para el modelo, es muy simple pero con ella se puede comenzar trabajar para que el cliente como el server concuerden a la hora de enviar datos
Pensando en un CMS se compone de artículos y que se debe tener usuarios que comenten o administran, no si les parezca esta idea de crear un api Rest para los usuario y una para los artículos

documentos

supongo que es los documentos son uno a uno, excepto artículos que es uno a muchos y supongo que para rendimiento debe esta indexado

   users:{
        "_id":""
        "name":"",
        "email":"",
        "password":"",
        "type":""
    };
    article:{
        "_id": ""
        "title":"",
        "text":"",
        "autor": users._id,
        "tags":[],
        "date":""
        "comments":[
            "comment":
            {
                "author":users._id
                "date":""
            }
        ]
    };

articulos crud

  • /articles/:id? get consige un usuario
  • /articles/:id? put actualiza un usuario
  • /articles/:id? delete elimina un usuario
    ##usuarios crud
  • /users/ get lista todos los usuarios
  • /users/:id? get consige un usuario
  • /users/:id? put actualiza un usuario
  • /users/:id? delete elimina un usuario
@bjrmatos
Copy link
Member

Lo de la api rest esta excelente, refuerza la buena practica de encapsular
el modelo para despues ser utilizada en aplicaciones.

Hasta ahora veo bien la estructura de los documentos (tablas), solo debemos
identificar que otras entidades necesitamos en base a las funcionalidades,
luego de eso y al final de implementar consultas podremos identificar
cuales son los campos comunes en dichas consultas para poder crear indices
en base a eso

El sáb, mar 21, 2015 03:21 PM, brian esteban bustos baquero <
notifications@github.com> escribió:

Buenas tengo una propuesta para el modelo, es muy simple pero con ella se
puede comenzar trabajar para que el cliente como el server concuerden a la
hora de enviar datos
Pensando en un CMS se compone de artículos y que se debe tener usuarios
que comenten o administran, no si les parezca esta idea de crear un api
Rest para los usuario y una para los artículos
documentos

supongo que es los documentos son uno a uno, excepto artículos que es uno
a muchos y supongo que para rendimiento debe esta indexado

users:{
"_id":""
"name":"",
"email":"",
"password":"",
"type":""
};
article:{
"_id": ""
"title":"",
"text":"",
"autor": users._id,
"tags":[],
"date":""
"comments":[
"comment":
{
"author":users._id
"date":""
}
]
};

articulos crud

  • /articles/:id? get consige un usuario
  • /articles/:id? put actualiza un usuario
  • /articles/:id? delete elimina un usuario ##usuarios crud
  • /users/ get lista todos los usuarios
  • /users/:id? get consige un usuario
  • /users/:id? put actualiza un usuario
  • /users/:id? delete elimina un usuario


Reply to this email directly or view it on GitHub
#3.

@calderaro
Copy link
Member

me gustaría mas que comments fuera un documento diferente ya que los comentarios son una característica que tiende a ser bastante utilizada y por tanto seria bastante peso en un solo documento. Propongo que por rendimiento se separen y se vinculen con populate de mongoose o con programación.

@bjrmatos
Copy link
Member

me parece que lo que menciona @calderaro tiene mucho peso, sobretodo cuando estamos hablando de mongodb como BD, ya que un documento solo soporta hasta 16mb de data y al estar los comentarios anidados esto puede llevar a sobrepasar este limite en un articulo muy popular.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants