La mejor forma de crear una matriz anidada a partir de tablas: múltiples consultas / loops VS sola consulta / estilo de bucle

Digamos que tengo 2 tablas, que puedo "fusionar" y representar en una sola matriz anidada.

Estoy deambulando cuál sería la mejor manera de hacerlo, teniendo en count:

  • eficiencia
  • mejores prácticas
  • Compensación del uso de DB / server
  • que deberías hacer en la vida real
  • mismo caso para 3, 4 o más tablas que pueden "fusionarse" de esa manera

La pregunta es sobre CUALQUIER lado del server / relacional-db.

2 maneras sencillas en las que estaba pensando (si tiene otras, sugiérale, observe que estoy pidiendo un SERVER-SIDE y una RELATIONAL-DB simples , así que no pierda el time explicando por qué no debería usar este tipo de DB, usar layout MVC, etc., etc. …):

  1. 2 loops, 5 consultas "SELECT" simples
  2. 1 loop, 1 consulta "JOIN"

Intenté dar un ejemplo simple y detallado, para explicarme y comprender mejor tus respuestas (aunque la forma de escribir el código y / o encontrar posibles errores no es el problema aquí, así que trata de no concentrarte en eso … .)

SCRIPTS SQL PARA CREAR E INSERTAR DATOS EN TABLAS

CREATE TABLE persons ( id int NOT NULL AUTO_INCREMENT, fullName varchar(255), PRIMARY KEY (id) ); INSERT INTO persons (fullName) VALUES ('Alice'), ('Bob'), ('Carl'), ('Dan'); CREATE TABLE phoneNumbers ( id int NOT NULL AUTO_INCREMENT, personId int, phoneNumber varchar(255), PRIMARY KEY (id) ); INSERT INTO phoneNumbers (personId, phoneNumber) VALUES ( 1, '123-456'), ( 1, '234-567'), (1, '345-678'), (2, '456-789'), (2, '567-890'), (3, '678-901'), (4, '789-012'); 

UNA REPRESENTACIÓN DE JSON DE LAS TABLAS DESPUÉS DE QUE LAS "FUNDICIÓN":

 [ { "id": 1, "fullName": "Alice", "phoneNumbers": [ "123-456", "234-567", "345-678" ] }, { "id": 2, "fullName": "Bob", "phoneNumbers": [ "456-789", "567-890" ] }, { "id": 3, "fullName": "Carl", "phoneNumbers": [ "678-901" ] }, { "id": 4, "fullName": "Dan", "phoneNumbers": [ "789-012" ] } ] 

CÓDIGO PSEUDO PARA 2 VÍAS:

1.

 query: "SELECT id, fullName FROM persons" personList = new List<Person>() foreach row x in query result: current = new Person(x.fullName) "SELECT phoneNumber FROM phoneNumbers WHERE personId = x.id" foreach row y in query result: current.phoneNumbers.Push(y.phoneNumber) personList.Push(current) print personList 

2.

 query: "SELECT persons.id, fullName, phoneNumber FROM persons LEFT JOIN phoneNumbers ON persons.id = phoneNumbers.personId" personList = new List<Person>() current = null previouseId = null foreach row x in query result: if ( x.id != previouseId ) if ( current != null ) personList.Push(current) current = null current = new Person(x.fullName) current.phoneNumbers.Push(x.phoneNumber) print personList 

IMPLEMENTACIÓN DEL CÓDIGO EN PHP / MYSQL:

1.

 /* get all persons */ $result = mysql_query("SELECT id, fullName FROM persons"); $personsArray = array(); //Create an array //loop all persons while ($row = mysql_fetch_assoc($result)) { //add new person $current = array(); $current['id'] = $row['id']; $current['fullName'] = $row['fullName']; /* add all person phone-numbers */ $id = $current['id']; $sub_result = mysql_query("SELECT phoneNumber FROM phoneNumbers WHERE personId = {$id}"); $phoneNumbers = array(); while ($sub_row = mysql_fetch_assoc($sub_result)) { $phoneNumbers[] = $sub_row['phoneNumber']); } //add phoneNumbers array to person $current['phoneNumbers'] = $phoneNumbers; //add person to final result array $personsArray[] = $current; } echo json_encode($personsArray); 

2.

 /* get all persons and their phone-numbers in a single query */ $sql = "SELECT persons.id, fullName, phoneNumber FROM persons LEFT JOIN phoneNumbers ON persons.id = phoneNumbers.personId"; $result = mysql_query($sql); $personsArray = array(); /* init temp vars to save current person's data */ $current = null; $previouseId = null; $phoneNumbers = array(); while ($row = mysql_fetch_assoc($result)) { /* if the current id is different from the previous id: you've got to a new person. save the previous person (if such exists), and create a new one */ if ($row['id'] != $previouseId ) { // in the first iteration, // current (previous person) is null, // don't add it if ( !is_null($current) ) { $current['phoneNumbers'] = $phoneNumbers; $personsArray[] = $current; $current = null; $previouseId = null; $phoneNumbers = array(); } // create a new person $current = array(); $current['id'] = $row['id']; $current['fullName'] = $row['fullName']; // set current as previous id $previouseId = $current['id']; } // you always add the phone-number // to the current phone-number list $phoneNumbers[] = $row['phoneNumber']; } } // don't forget to add the last person (saved in "current") if (!is_null($current)) $personsArray[] = $current); echo json_encode($personsArray); 

PD este enlace es un ejemplo de una pregunta diferente aquí, donde traté de sugerir la segunda manera: tablas para solo json

Preliminar

Primero, gracias por poner tanto esfuerzo en explicar el problema y por el formatting. Es genial ver a alguien que tenga claro lo que está haciendo y lo que está pidiendo.

Pero debe tenerse en count que eso, en sí mismo, forma una limitación: usted se fija en la noción de que esta es la solución correcta, y que con una pequeña corrección u orientación, esto funcionará. Eso es incorrecto. De modo que debo pedirte que renuncies a esa noción, dar un gran paso atrás y ver (a) todo el problema y (b) mi respuesta sin esa noción.

El context de esta respuesta es:

  • todas las consideraciones explícitas que has dado, que son muy importantes, que no repetiré

  • los dos más importantes de los cuales es, qué mejor práctica y qué haría en la vida real

Esta respuesta tiene sus raíces en los estándares, el order superior o el framework de las mejores prácticas . Esto es lo que hice en la vida real desde 1990, lo que significa que desde 1990 nunca tuve la necesidad de escribir código como el suyo. Esto es lo que el mundo comercial Cliente / Servidor hace, o debería estar haciendo.

Este problema, todo este espacio problemático, se está convirtiendo en un problema común. Daré una consideración completa aquí, y así responderé también a otra pregunta SO. Por lo tanto, podría contener un poco más de detalle que requiera. Si lo hace, por favor perdona esto.

Consideración

  1. La database es un recurso basado en server, compartido por muchos usuarios. En un sistema en línea, la database cambia constantemente. Contiene esa versión única de la verdad (a diferencia de One Fact in One Place, que es un tema de normalización separado) de cada hecho.

    • el hecho de que NONsqls de mickey mouse no tiene una architecture de server, y que, por lo tanto, la noción de server en dicho software es falsa y engañosa, son puntos separados pero notados.
  2. Según tengo entendido, las estructuras JSON y similares a JSON son necesarias por "razones de performance", precisamente porque el "server" no funciona, no puede funcionar como server. El concepto es almacenar en caching los datos en cada (cada) cliente, de modo que no los esté obteniendo del "server" todo el time.

    • Esto abre una lata de gusanos apestosa. Si no diseñas e implementas esto correctamente, los gusanos invadirán la aplicación y el hedor te matará.

    • Tal implementación es una grave violación de la architecture Cliente / Servidor, que permite un código simple en ambos lados, y una implementación apropiada de software y componentes de datos, de modo que los times de implementación son pequeños y la eficiencia es alta.

    • Además, tal implementación requiere un esfuerzo de implementación sustancial, y es compleja, que consta de muchas partes. Cada una de esas partes debe estar diseñada apropiadamente.

    • La web, y los muchos libros escritos en esta área temática, proporcionan un abismo de methods, comercializados sobre la base de la supuesta simplicidad; facilitar; cualquiera puede hacer cualquier cosa; freeware-puede-hacer-cualquier cosa; etc. No hay base científica para ninguna de esas propuestas.

No architecture y Sub-estándar

Como se evidencia, usted ha aprendido que esa mitología comercializada es fraudulenta. Has encontrado un problema, una instancia en la que ese consejo es falso. Tan pronto como resuelvas este problema, el siguiente problema, que no es aparente para ti en este momento, quedará expuesto. Las nociones son un set interminable de problemas.

No voy a enumerar todas las nociones falsas que estos expertos (en realidad, fanáticos del circo que ignoran la tecnología) venden. Confío en que a medida que avance en mi respuesta, notará que una después de la otra noción comercializada es falsa.

Las dos líneas inferiores son:

  1. Las nociones violan los Estándares de Arquitectura y Diseño, a saber, Arquitectura Cliente / Servidor; Arquitectura abierta ; Principios de ingeniería; y para un menor en este problema en particular, Principios de layout de la database.

  2. Lo que lleva a personas como usted, que están tratando de hacer un trabajo honesto, siendo estafados, engañados, seducidos, en la implementación de nociones simples, que se convierten en implementaciones masivas. Implementaciones que nunca funcionarán del todo, por lo que requieren un mantenimiento sustancial continuo, y eventualmente serán reemplazadas, al por mayor.

Arquitectura

El principio central que se viola es nunca duplicar nada. En el momento en que tiene una location donde se duplican los datos (debido a la duplicación o el almacenamiento en caching o dos aplicaciones monolíticas separadas, etc.), crea un duplicado que se desconectará en una situación en línea. Entonces el principio es evitar hacer eso.

  • Claro, para el software de terceros serio, como una herramienta de informe gruñón, por layout, bien pueden almacenar en caching los datos del server en el cliente. Pero tenga en count que han puesto cientos de años hombre en implementarlo correctamente, con la debida consideración a lo anterior. El tuyo no es una pieza de software.

En lugar de dar una conferencia sobre los principios que deben entenderse, o los males y costos de cada error, el rest de esta respuesta proporciona lo solicitado, ¿qué harías en la vida real , utilizando el método arquitectónico correcto (un paso por encima de las mejores prácticas ) .

Arquitectura 1

No confundir

  • los datos
    que debe ser Normalizado

con

  • el set de resultados
    que, por definición, es la vista aplanada ("desnormalizada" no es del todo correcta) de los datos.

Los datos, dado que están Normalizados, no contendrán valores duplicates; grupos repetitivos. El set de resultados contendrá valores duplicates; grupos repetitivos. Eso es peatonal.

  • Tenga en count que la noción de sets nesteds (o relaciones anidadas), que los esquizofrénicos comercializan en gran medida, se basa precisamente en esta confusión.

  • Durante cuarenta y cinco años desde el advenimiento de la RM , no han podido diferenciar las relaciones de base (para las cuales se aplica la Normalización) de las relaciones derivadas (para las cuales no se aplica la Normalización).

  • Dos de los monstruos están actualmente montando un asalto a la definición de la Primera Forma Normal. Esto es un asalto al intelecto. Esto (si se acepta) normalizaría la locura. 1NF es la base de las otras NF, si se acepta esta locura, todas las NF se dañarán, se degradarán, se restarán de valor. El resultado sería que la normalización en sí misma (escasamente definida en términos matemáticos, pero claramente entendida como una ciencia por los profesionales) será severamente dañada, si no destruida.

Arquitectura 2

Existe un principio científico o de ingeniería de siglos de antigüedad, según el cual el contenido (datos) debe estar separado del control (elementos del progtwig). Esto es porque el análisis; layout; y la implementación de los dos es completamente diferente. Este principio no es less importante en las ciencias del software, donde tiene una articulación específica.

Para mantener este breve (ja, ja), en lugar de un discurso, asumiré que usted comprende:

  • Que existe un límite científicamente exigido entre los datos y los elementos del progtwig. Mezclarlos da como resultado objects complejos que son propensos a errores y difíciles de mantener.

    • La confusión de este principio ha alcanzado proporciones epidémicas en el mundo OO / ORM, las consecuencias alcanzan a lo largo y ancho.

    • Solo profesionales educados evitan esta locura. Por lo demás, la gran mayoría, aceptan esta locura como "normal", y se pasan la vida solucionando problemas que simplemente no tenemos.

  • La superioridad arquitectónica, el gran valor, de los datos se almacenan y presentan en forma tabular según el model relacional del Dr. EF Codd. Que hay reglas específicas para la normalización de datos.

  • Y, lo que es más importante, puedes determinar cuándo las personas en la casa enloquecida, que escriben y comercializan libros, recomiendan methods no relacionales o antirrelacionales.

Arquitectura 3

Si almacena datos en caching en el cliente:

  1. Caché el mínimo absoluto.

    Eso significa almacenar en caching solo los datos que no cambian en el entorno en línea. Eso significa solo tablas de reference y búsqueda, las tablas que pueblan los clasificadores de nivel superior, los menus desplegables, etc.

  2. Moneda

    Para cada tabla que haga caching, debe tener un método para (a) determinar que los datos en caching se han quedado obsoletos, en comparación con la versión única de la verdad que existe en el server, y (b) actualizarla del server, (c) tabla por tabla.

    Normalmente, esto implica un process en segundo plano que se ejecuta cada (e) cinco minutos, que consulta el time de actualización actualizado de MAX para cada tabla almacenada en caching en el cliente frente a DateTime en el server y, si se modifica, actualiza la tabla y todas sus tablas secundarias. aquellos que dependen de la tabla modificada.

    Eso, por supuesto, requiere que tenga una columna UpdatedDateTime en cada tabla. Eso no es una carga, porque de todos modos lo necesita para las Transacciones OLCI ACID (si tiene una database real, en lugar de una cantidad de files subestándar).

Lo que realmente significa, nunca repetir, la carga de encoding es prohibitiva.

Arquitectura 4

En el mundo subcomercial, no server, entiendo que los fanáticos aconsejan lo contrario (las personas locas siempre contradicen la cordura), el almacenamiento en caching de "todo".

  • Esa es la única forma en que los progtwigs como PusGresQl, producidos por sus cohortes en el mismo asilo, pueden usarse en un sistema multiusuario, la única forma en que pueden propagar su cáncer.

  • Siempre obtienes lo que pagas: pagas cacahuetes, obtienes monos; pagas cero, obtienes cero.

El corolario de Architecture 3 es que, si almacena los datos del caching en el cliente, no coloque en caching las tablas que cambian con frecuencia. Estas son las tablas de transactions e historial. La noción de almacenamiento en caching de tales tablas, o todas las tablas, en el cliente está completamente en quiebra.

En una implementación genuina Cliente / Servidor, debido al uso de estándares aplicables, para cada window de datos, la aplicación debe consultar solo las filas que se requieren, para esa necesidad particular, en ese momento particular, en function de los valores de context o filter, etc. La aplicación nunca debe cargar toda la tabla.

Si el mismo usuario que utiliza la misma window inspeccionó su contenido, 15 minutos después de la primera inspección, los datos estarían 15 minutos desactualizados.

  • Para las plataforms freeware / shareware / vapourware, que se definen por la ausencia de una architecture de server, y por lo tanto por el resultado, ese performance es inexistente, seguro, debe almacenar en caching más que las tablas mínimas en el cliente.

  • Si lo hace, debe tener en count todo lo anterior e implementarlo correctamente, de lo contrario su aplicación se romperá y el hedor impulsará a los usuarios a search su terminación. Si hay más de un usuario, tendrán la misma causa y pronto formarán un ejército.

Arquitectura 5

Ahora veremos cómo almacena en caching esas tablas cuidadosamente elegidas en el cliente.

Tenga en count que las bases de datos crecen, se extienden.

  • Si el sistema se rompe, una falla, crecerá en pequeños incrementos y requerirá mucho esfuerzo.

  • Si el sistema tiene incluso un pequeño éxito, crecerá exponencialmente.

  • Si el sistema (cada una de las bases de datos y la aplicación, por separado) está diseñado e implementado correctamente, los cambios serán fáciles, los errores serán pocos.

Por lo tanto, todos los componentes de la aplicación deben diseñarse correctamente para cumplir con los estándares aplicables y la database debe estar completamente normalizada. Esto, a su vez, minimiza el efecto de los cambios en la database, en la aplicación y viceversa.

  • La aplicación consistirá en objects simples, no complejos, que son fáciles de mantener y cambiar.

  • Para los datos que hace caching en el cliente, usará matrices de algún tipo: múltiples instancias de una class en una plataforma OO; DataWindows (TM, google para él) o similar en un 4GL; matrices simples en PHP.

( Aparte. Tenga en count gravemente que lo que personas en situaciones como la suya producen en un año, proveedores profesionales como yo produzco en una semana, usando una plataforma SQL comercial, un 4GL comercial y cumpliendo con Arquitectura y estándares ) .

Arquitectura 6

Asummos que usted entiende todo lo anterior y aprecia su valor, particularmente Arquitectura 1 y 2.

  • Si no lo hace, deténgase aquí y haga preguntas, no continúe con el siguiente.

Ahora que hemos establecido el context completo, podemos abordar el meollo de su problema.

  • En esas matrices en la aplicación, ¿por qué en la Tierra almacenaría vistas planas de datos?

    • y consecuentemente meterse con y agonizar sobre los problemas
  • en lugar de almacenar copys de las tablas normalizadas?

Responder

  1. Nunca duplique nada que pueda derivarse. Ese es un Principio Arquitectónico, no se limita a la Normalización en una database.

  2. Nunca fusionar nada.

    Si lo haces, estarás creando :

    • duplicación de datos, y una gran cantidad de ella, en el cliente. El cliente no solo estará gordo y lento, sino que estará anclado al piso con el lastre de datos duplicates.

    • código adicional, que es completamente innecesario

    • complejidad en ese código

    • código que es frágil, que tendrá que cambiar constantemente.

    Ese es el problema preciso que estás sufriendo, una consecuencia del método, que sabes intuitivamente que es incorrecto, que debe haber una mejor manera. Usted sabe que es un problema genérico y común.

    Tenga en count también que el método (el veneno que se comercializa), ese código, constituye un ancla mental para usted. Mire la forma en que lo ha formateado y lo ha presentado de forma tan bella: es importante para usted. Soy reacio a informarte de todo esto.

    • La reticencia se supera fácilmente, debido a su actitud sincera y franca, y al conocimiento de que no inventó este método, que siguió a "maestros" que, como se evidencia, ignoran por completo la ciencia relevante, que comercializan la locura; no ciencia; sin sentido, como "ciencia".
  3. En cada segmento de código, en el momento de la presentación, cuando sea necesario:

    a. En el context comercial Cliente / Servidor
    Ejecute una consulta que se una a las tablas simples, normalizadas y no duplicadas, y recupere solo las filas calificadas. De este modo, se obtienen valores de datos actuales. El usuario nunca ve datos obsoletos. Aquí, las vistas (vistas planas de datos normalizados) se utilizan a menudo.

    segundo. En el context subcomercial no server
    Cree una matriz de set de resultados temporal, y únase a las matrices simples y no duplicadas (copys de las tablas que se almacenan en la memory caching) y rellene con solo las filas calificadas, desde las matrices de origen. La moneda de la cual se mantiene por el process de background.

    • Use las teclas para formar las uniones entre las matrices, exactamente de la misma manera que las keys se usan para formar las uniones en las tablas relacionales en la database.

    • Destruye esos componentes cuando el usuario cierra la window.

    • Una versión inteligente eliminaría la matriz de set de resultados y se uniría a las matrices de origen a través de las Teclas, y limitaría el resultado a las filas calificadas.

Aparte de ser una locura arquitectónica, las matrices anidadas o sets nesteds o las estructuras similares a JSON o simplemente no son necesarias. Esta es la consecuencia de confundir el Principio de Arquitectura 1.

  • Si eliges usar tales estructuras, entonces úsalas solo para las matrices temporales de sets de resultados.

Por último, confío en que este discurso demuestre que n tables no es un problema. Más importante, que m niveles en lo profundo de la jerarquía de datos, el "anidamiento", no es un problema.

Respuesta 2

Ahora que he dado el context completo (y no antes), que elimina las implicaciones en su pregunta, y la convierte en una genérica, núcleo.

La pregunta es sobre CUALQUIER lado del server / relacional-db. [Cual es mejor]:

2 loops, 5 consultas "SELECT" simples

1 loop, 1 consulta "JOIN"

Los ejemplos detallados que ha proporcionado no se describen con precisión anteriormente. Las descripciones precisas son:

  • Su opción 1 2 loops, cada bucle para cargar cada matriz 1 consulta SELECT de una sola tabla por bucle (se ejecuta nxm veces … el bucle más externo, únicamente, es una única ejecución)

  • Su opción 2 1 Una consulta SELECT unida ejecutada una vez seguida de 2 loops, cada bucle para cargar cada matriz

Para las plataforms SQL comerciales, ninguna, porque no se aplica.

  • El server SQL comercial es un motor de procesamiento de sets. Utilice una consulta con las combinaciones necesarias, que devuelve un set de resultados. Nunca pase por las filas utilizando un bucle, que networkinguce el motor de procesamiento establecido a un sistema ISAM anterior a 1970. Use una vista en el server, ya que ofrece el máximo performance y el código está en un solo lugar.

Sin embargo, para las plataforms no comerciales que no son serveres, donde:

  • su "server" no es un motor de procesamiento de sets, es decir. devuelve filas únicas, por lo tanto, debe search cada fila y completarla, manualmente o

  • su "server" no proporciona el enlace Cliente / Servidor, es decir. no proporciona instalaciones en el cliente para vincular el set de resultados entrantes a una matriz receptora, y por lo tanto, tiene que pasar por el set de resultados devuelto, fila por fila, y llenar la matriz, manualmente,

según su ejemplo , la respuesta es, por un amplio margen, su opción 2.

Por favor considere cuidadosamente, y comente o haga preguntas.

Respuesta a los comentarios

Digamos que necesito imprimir esta json (u otra página html) en algunos STOUT (ejemplo: una respuesta http a: GET / allUsersPhoneNumbers. Es solo un ejemplo para aclarar lo que estoy esperando get), debería devolver este json. Tengo una function php que obtuvo estos 2 sets de resultados (1). ahora debería imprimir este json, ¿cómo debería hacerlo? este informe podría ser un salario mensual de un empleado por un año completo, y uno. De una manera u otra, necesito reunir esta información y representarla en una representación ed "ÚNASE"

Tal vez no fui lo suficientemente claro.

  1. Básicamente, no uses JSON. A less que sea absolutamente necesario. Lo que significa enviar a algún sistema que lo requiera, lo que significa que el sistema receptor, y esa demanda, es muy, muy, estúpido.

  2. Asegúrese de que su sistema no exija tales demandas a los demás.

  3. Mantenga sus datos normalizados. Tanto en la database como en cualquier elemento de progtwig que escriba. Eso significa (en este ejemplo) usar un SELECT por table o matriz. Eso es para fines de carga, para que pueda consultar e inspeccionarlos en cualquier punto del progtwig.

  4. Cuando necesites unirte, entiende que es:

    • un set de resultados; una relación derivada; una vista
    • por lo tanto temporal, existe por la duración de la ejecución de ese elemento, solo

    a. Para las tablas, únelas de la manera habitual, a través de Keys. Una consulta, uniendo dos (o más) tablas.

    segundo. Para matrices, úne arrays en el progtwig, de la misma manera que une tablas en la database, a través de Keys.

  5. Para el ejemplo que ha dado, que es una respuesta a alguna request, primero comprenda que es la categoría [4] y luego cumpla con ella.

¿Por qué siquiera considerar JSON?
¿Qué tiene que ver JSON con esto?

JSON es malentendido y la gente está interesada en el factor sorpresa. Es una solución que busca un problema. A less que tenga ese problema, no tiene valor. Verifique estos dos enlaces:
Copter – ¿Qué es JSON?
StackOverflow – ¿Qué es JSON?

Ahora bien, si comprende eso, es principalmente para los feeds entrantes. Nunca para salientes. Además, requiere un análisis sintáctico, deconstrucción, etc., antes de poder usarse.

Recordar:

Necesito recostackr esta información y representarla en una representación ed "JOIN"

Sí. Eso es peatonal. Unido no significa JSONed.

En su ejemplo, el receptor espera una vista aplanada (por ejemplo, spreadsheet), con todas las celdas llenas, y sí, para Usuarios con más de un Número Telefónico, sus datos de Usuario se repetirán en la segunda fila de set de resultados subsiguiente. Para cualquier tipo de print, ej. para la debugging, quiero una vista aplanada. Es solo una:

  SELECT ... FROM Person JOIN PhoneNumber 

Y devuelve eso. O bien, si cumple con la request de las matrices, únase a las matrices Person y PhoneNumber, que pueden requerir una matriz de sets de resultados temporales, y devuélvala.

por favor, no me digas que debes get solo 1 usuario a la vez, etc. etc.

Correcto. Si alguien le dice que regrese al procesamiento de procedimientos (es decir, fila por fila, en un bucle WHILE), donde el motor o su progtwig ha establecido el procesamiento (es decir, procesa un set completo en un command), eso los marca como un idiota. Deja de escucharlos completamente.

Ya he indicado, su Opción 2 es correcta, la Opción 1 es incorrecta. Eso es lo que concierne a GET o SELECT.

Por otro lado, para lenguajes de progtwigción que no tienen capacidad de procesamiento de sets (es decir, no se puede imprimir / establecer / inspeccionar una matriz en un solo command), o "serveres" que no proporcionan encuadernación de matriz del lado del cliente, usted tiene para escribir loops, un bucle por profundidad de la jerarquía de datos (en su ejemplo, dos loops, uno para Persona y uno para PhoneNumber por Usuario).

  • Tienes que hacer eso para analizar un object JSON entrante.
  • Tienes que hacer eso para cargar cada matriz del set de resultados que se devuelve en tu Opción 2.
  • Debe hacer eso para imprimir cada matriz del set de resultados que se devuelve en su Opción 2.

Respuesta al comentario 2

Tengo que devolver un resultado representado en una versión anidada (digamos que estoy imprimiendo el informe en la página), json fue solo un ejemplo para dicha representación.

No creo que entiendas el razonamiento y las conclusiones que he proporcionado en esta respuesta.

  • Para imprimir y mostrar, nunca anide . Imprima una vista aplanada , las filas devueltas desde SELECT por Opción 2. Eso es lo que hemos estado haciendo, al imprimir o mostrar datos Relacionalmente, durante 31 años. Es más fácil de leer, depurar, search, encontrar, doblar, engrapar, mutilar. No se puede hacer nada con una matriz anidada, excepto mirarla, y decir gee que es interesante .

Te estaba dando orientación, de modo que puedes escribir el código requerido, pero eso no está funcionando. Parece que tengo que escribir el código para ti.

Código

Advertencia

Preferiría tomar su código y modificarlo, pero en realidad, al mirar su código, no está bien escrito o estructurado, no puede modificarse razonablemente. En segundo lugar, si uso eso, sería una mala herramienta de enseñanza. Así que tendré que darte un código limpio y fresco, de lo contrario no aprenderás los methods correctos.

Los ejemplos de este código siguen mis consejos, así que no voy a repetir. Y esto es mucho más allá de la pregunta original.

  • Consulta e printing

    Su request, utilizando su Opción 2. Una SELECCIÓN ejecutada una vez. Seguido por un bucle Lo cual puedes "mejorar" si quieres.

En general, es una buena práctica get los datos que necesita en tan pocos viajes a la database como sea posible y luego asignar los datos en los objects apropiados. (Opcion 2)

Pero, para responder a su pregunta, me preguntaría cuál es el caso de uso de sus datos. Si está seguro de que necesitará su persona y los datos de su número de teléfono, entonces diría que el segundo método es su mejor opción.

Sin embargo, la opción uno también puede tener su caso de uso cuando los datos combinados son opcionales. Un ejemplo de esto podría ser que en la UI tiene una tabla de toda su gente y si un usuario desea ver el número de teléfono de una persona en particular, tiene que hacer clic en esa persona. Entonces sería aceptable "cargar perezoso" todos los numbers telefónicos.

    Intereting Posts