mongodb-user
[Arriba] [Todas las Listas]

[mongodb-Usuario] Re: MongoDB para cualquier tipo de bookable recursos

To: mongodb-user <mongodb-user@xxxxxxxxxxxxxxxx>
Subject: [mongodb-Usuario] Re: MongoDB para cualquier tipo de bookable recursos
From: "'Wan Bachtiar' via mongodb-user" <mongodb-user@xxxxxxxxxxxxxxxx>
Date: Tue, 15 Aug 2017 00:30:33 -0700 (PDT)
Delivery-date: Tue, 15 Aug 2017 03:30:44 -0400
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20161025; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=d2yI9GIyTSXUcahyZ4Vw/BKXC8tPVNw4tICaynvEY/8=; b=pcHnwLcQuiH+PhDQ3TBzH8ZtJoB7L2Q/sylmDG8oqBHo0BkYOjkWtjPgK5oZEM6Z6x MbJiRImd4FQuXrXfv/9Dm+UrX7TA4TPj/XeMpk4i0mEVrqeN4BeFmdkYq5kvejdjCMRf RGx5Ohemqus45rFdX8IbA60UQNF8mb6G3XmkMx3WAr23ifiLXETe+AY7nJ/Fn3Rh2wUT lIe9q7pmvWs9Ue871XFzUA6PhjuzjDW6l5pi+hJUiLUlHPkGRJrOPNIA5iUcvAeBTHfC ZOWG6Ri2FvsZiV1YWix8LB4XGECrleiv1Us24NwW1B4KRYgnb30faYYg3q2q0MhGrRju tfCA==
Envelope-to: traductor@xxxxxxxxxxx
In-reply-to: <55f0f3d6-e347-4bb8-8acc-f67ea5793a9c@googlegroups.com>
List-archive: <https://groups.google.com/group/mongodb-use>
List-help: <https://groups.google.com/support/>, <mailto:mongodb-user+help@googlegroups.com>
List-id: <mongodb-user.googlegroups.com>
List-post: <https://groups.google.com/group/mongodb-user/post>, <mailto:mongodb-user@googlegroups.com>
List-subscribe: <https://groups.google.com/group/mongodb-user/subscribe>, <mailto:mongodb-user+subscribe@googlegroups.com>
List-unsubscribe: <mailto:googlegroups-manage+1044811755470+unsubscribe@googlegroups.com>, <https://groups.google.com/group/mongodb-user/subscribe>
Mailing-list: list mongodb-user@xxxxxxxxxxxxxxxx; contact mongodb-user+owners@xxxxxxxxxxxxxxxx
References: <55f0f3d6-e347-4bb8-8acc-f67ea5793a9c@googlegroups.com>
Reply-to: mongodb-user@xxxxxxxxxxxxxxxx

Así que este tipo de necesidad de conjunto del dato une cuándo el usuario que pide detalles de hotel. Es 
que práctica buena ?

*Hi *Amila, 

El diseño puede varía depender en vuestros requisitos de aplicación. Aun así 
si los recursos para un hotel *don’*t cambio a menudo entonces podrías probar *embedding 
<*https://*docs.*mongodb.*com/Manual/*tutorial/modelo-*embedded-un-a-muchos-relaciones-entre-documenta/> 
la información.
Por ejemplo, la habitación de VIP del recurso o piscina *doesn’*t cambio en 
un periodo corto de tiempo para un hotel a *warrant su colección propia. 

Quiero mantener el documento para #cada recursos. Pero lo duplicado el mismo 
dato 

Esto es una decisión el experto de ámbito de la aplicación tendría que hacer. Si la duplicación 
de dato combina con interacciones de aplicación podrían socavar 
la integridad del dato él, puedes tener que *normalised 
<*https://*docs.*mongodb.*com/Dato/de núcleo/manual-modelo-el diseño/#normalizado-dato-modelos>. 
*Generalmente* esto podría pasar para *duplicated dato que es actualizado 
frecuentemente. 

Quiero saber cómo utilizaré correctamente.

*MongoDB Modelo de dato 
<*https://*docs.*mongodb.*com/Dato/de núcleo/manual-*modeling-diseño/> de introducción 
tendría que ser decidido por equilibrar las necesidades de la aplicación, las 
características de rendimiento del *database motor, y el dato *retrieval 
patrones. Puedes encontrar algunos de los recursos abajo útiles como guía: 

   - 6 Reglas de Pulgar para *MongoDB *Schema Diseño (Parte 1) 
   <*https://www.mongodb.com/*blog/correo/6-reglas-de-pulgar-para-*mongodb-*schema-diseño-parte-1> 
   - *Operational Factores y Modelos de Dato 
   <*https://*docs.*mongodb.*com/Dato/de núcleo/manual-modelo-operaciones/> 
   - Ejemplos de Modelo Contextos de Aplicación Específica 
   <*https://*docs.*mongodb.*com/Dato/de aplicaciones/manuales-modelos-Consideraciones/> 

de aplicaciones,
*Wan. 
​

-- 
Recibiste este mensaje porque eres *subscribed al *Google Grupos "*mongodb-grupo"
de usuario.

Para otro *MongoDB opciones de apoyo técnico, ve: *https://*docs.*mongodb.*com/Apoyo/manual/
--- 
recibiste este mensaje porque eres *subscribed al *Google Grupos "*mongodb-grupo" de usuario.
A *unsubscribe de este grupo y la parón que recibe *emails de él, enviar un *email a *mongodb-usuario+unsubscribe@xxxxxxxxxxxxxxxx.
A correo a este grupo, envía *email a *mongodb-user@xxxxxxxxxxxxxxxx.
Visita este grupo en *https://grupos.*google.*com/Grupo/*mongodb-usuario.
Para ver esta discusión en la visita de web *https://grupos.*google.*com/*d/*msgid/*mongodb-Usuario/6*ee0077un-92*d8-4961-94*bb-*cf6*da664*e89*f%40*googlegroups.*com.
Para más opciones, visita *https://grupos.*google.*com/*d/*optout.

So this type of data set need joins when user requesting hotel details. Is 
that good practice ?

Hi Amila, 

The design can varies depending on your application requirements. However 
if the resources for a hotel don’t change often then you could try embedding 
<https://docs.mongodb.com/manual/tutorial/model-embedded-one-to-many-relationships-between-documents/> 
the information.
For example, the resource VIP room or swimming pool doesn’t change in a 
short period of time for a hotel to warrant its own collection. 

I want to keep the document for each resources. But it duplicate the same 
data 

This is a decision the application domain expert would have to make. If the 
duplication of data combine with application interactions could undermine 
the integrity of the data itself, you may have to normalised 
<https://docs.mongodb.com/manual/core/data-model-design/#normalized-data-models>. 
*Generally* this could happen for duplicated data that are updated 
frequently. 

I want to know how I will use properly.

MongoDB Data Model 
<https://docs.mongodb.com/manual/core/data-modeling-introduction/> design 
would have to be decided by balancing the needs of the application, the 
performance characteristics of the database engine, and the data retrieval 
patterns. You may find some of the resources below useful as a guide: 

   - 6 Rules of Thumb for MongoDB Schema Design (Part 1) 
   <https://www.mongodb.com/blog/post/6-rules-of-thumb-for-mongodb-schema-design-part-1> 
   - Operational Factors and Data Models 
   <https://docs.mongodb.com/manual/core/data-model-operations/> 
   - Examples of Model Specific Application Contexts 
   <https://docs.mongodb.com/manual/applications/data-models-applications/> 

Regards,
Wan. 
​

-- 
You received this message because you are subscribed to the Google Groups "mongodb-user"
group.

For other MongoDB technical support options, see: https://docs.mongodb.com/manual/support/
--- 
You received this message because you are subscribed to the Google Groups "mongodb-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mongodb-user+unsubscribe@xxxxxxxxxxxxxxxx.
To post to this group, send email to mongodb-user@xxxxxxxxxxxxxxxx.
Visit this group at https://groups.google.com/group/mongodb-user.
To view this discussion on the web visit https://groups.google.com/d/msgid/mongodb-user/6ee0077a-92d8-4961-94bb-cf6da664e89f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
<Anterior por Tema] Tema Actual [Siguiente por Tema>
  • [mongodb-Usuario] Re: MongoDB para cualquier tipo de bookable recursos, 'Wan Bachtiar' via mongodb-user <=