Pregunta

Últimamente he estado leyendo mucho acerca de cómo las uniones en las consultas de base de datos ralentizan las cosas. Evidentemente, Google App Engine ni siquiera los permite.

Me pregunto cómo las personas diseñan una aplicación sin uniones, sin embargo. Por ejemplo, estoy trabajando en una aplicación que tiene contactos y organizaciones . Un contacto puede estar en muchas organizaciones y una organización puede tener muchos contactos. ¿Cómo sería posible tener esa relación sin una tercera tabla que conecte las dos entidades ... 

contacts --< contacts_organizations >-- organizations

¿Significa que en GAE no puedes tener una relación de muchos a muchos? ¿Simplemente deja de lado la funcionalidad que requeriría una combinación?

Supongo que podría tener una columna TEXTO organizaciones en la tabla contactos que contiene una lista separada por espacios de los ID de organización para cada contacto. Aunque parece un poco raro.

¿Fue útil?

Solución

Por lo general, cuando se habla de bases de datos que no permiten uniones, se habla de bases de datos muy grandes que no necesariamente caben en un servidor. Los ejemplos recientes son las bases de datos en la nube como SimpleDB de Amazon , SQL Data Services de Microsoft, y Almacén de datos del motor de aplicaciones de Google . Algunos ofrecen una capacidad de unión limitada, pero la gran dificultad es hacer uniones entre " particiones " ;. En grandes bases de datos como esta, particiona sus datos para que no tengan que residir en el mismo servidor. Tienes que decidir la forma correcta de particionarlo.

En su ejemplo, almacenaría una lista de claves de organización en un campo en la tabla de contactos, y viceversa. El diseño de estas bases de datos es diferente de su base de datos normalizada típica. Las tablas suelen ser "tablas dispersas", lo que básicamente significa que cada registro puede tener cualquier número de campos que sean básicamente pares de nombre / valor. Piense en una tabla de productos en Amazon y en cuántos campos diferentes podría haber para diferentes tipos de productos. Los libros tienen varias páginas, pero los MP3 tienen duración. En una tabla dispersa, estos registros se almacenarán en la misma tabla.

Otros consejos

Es un mito que se une al software de ralentización, de la misma manera que sería un mito afirmar que los bucles de escritura en el software de ralentización de código de aplicación.

Quiero decir, ¿por qué escribir un bucle? ¡Eso solo ejecuta las mismas líneas de código una y otra vez! ¿No fue una vez suficiente? ¡Es un tremendo desperdicio!

Las declaraciones anteriores pretenden ser irónicas.

Mi punto es que una consulta contiene una unión con un propósito: obtener la respuesta correcta. Por supuesto, usar uniones de manera ineficiente o innecesaria es un diseño deficiente, como poner código invariante de bucle dentro de un bucle.

Evitar las uniones como política general es un ejemplo de optimización prematura . Si su enfoque para escribir código eficiente es crear reglas generales como esa, entonces evitar las uniones no lo ayudará.

En cuanto a Google App Engine, admite relaciones entre entidades, pero como no es estrictamente un modelo de base de datos relacional, el concepto de unión realmente no surge. En su lugar, puede obtener entidades relacionadas de una referencia dada, que es más como una interfaz ORM para un modelo, no es lo mismo que una unión en SQL.

Puedes leer más aquí: http://code.google.com/appengine/articles/modeling.html

(ese enlace estaba en otra respuesta en este hilo, pero se eliminó)

Punto de selección de liendres: Google no prohíbe los JOIN en su base de datos para evitar que los usuarios ejecuten " caro " consultas la base de datos no es relacional, por lo que " JOIN " El verbo SQL no es realmente aplicable en primer lugar.

De esta manera, BigTable es lo mismo que SimpleDB de Amazon : los datos se desnormalizan y se eliminan. esquemas para que usted efectivamente termine con tablas hash enormes y eficientes con datos arbitrarios permitidos en los grupos.

Estas tablas hash son muy, muy fáciles de escalar, especialmente en comparación con las bases de datos relacionales. Para aplicaciones como GAE, la escalabilidad extrema es una prioridad más alta que un conjunto completo de características.

Utiliza db.ReferenceProperty para vincular objetos, consulte Motor de aplicaciones de Google: ÚNETE DE UNO A MUCHOS para obtener detalles y ejemplos.

Creo que Google le está robando algún mecanismo de cómputo pesado por lo que buscará formas de utilizar más recursos de otro tipo, por ejemplo, discos duros que mantienen tablas de referencia y / o tablas de conteo en lugar de pérdida de ciclos de CPU Uniones y cálculo agregado.

Y no es imposible, solo necesitas solucionarlo utilizando otros tipos de recursos para ayudarte.

Puede realizar combinaciones en su aplicación en lugar del servidor de base de datos, obteniendo los resultados de cada tabla por separado y luego combinándolos, pero para la mayoría de las combinaciones, esto solo lo hará más lento debido a la latencia de realizar varios viajes de ida y vuelta a la base de datos. en lugar de solo uno.

Pero: la verdad honesta es que las uniones no son tu problema. En el momento en que lo estén, si es que alguna vez, ni siquiera necesitarás hacer esta pregunta. Puede contar la cantidad de proyectos de la vida real que llegan a este punto con sus dedos (principalmente Ebay), y no hay evidencia de que eliminar las uniones por completo fue la única forma en que estos proyectos podrían haberse realizado a escala.

Las bases de datos que menciona son, en el mejor de los casos, almacenes de registros versionados diseñados para almacenar grandes volúmenes de datos en múltiples servidores. Llamarlos una 'base de datos' sería un tramo. No admite uniones, ni transacciones ACID, reversiones, etc. Puede escribir aplicaciones sin ellas, pero a menudo tendrá que hacer más trabajo para proporcionar la funcionalidad.

Para: 

contacts --< contacts_organizations >-- organizations

Podrías desmontar y almacenar organizaciones en contactos y contactos en organizaciones. Pero tendrá que hacer cumplir la integridad referencial en el trato de la aplicación con actualizaciones simultáneas a ambas tablas.

Una mejor solución sería almacenar los datos en tres tablas y hacer las "uniones" tú mismo.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top