<ultraHeader>
<nombreControl>mi nombre aunque se cambie el del fichero este es el original cuando se creó<nombreControl>
<nombreBD>nombre de la bd, aunque se le cambie al archivo, se sabe como se llama</nombreBD>
<nombreHeaders> nombre del fichero de headers para relacionar la BD, con el fichero de headers</nombreHeaders>
</ultraHeader>
<fileHeader> datos del fichero ajeno a los datos en si, estos son campos que solo son consultables por el motor de la BD no por los usuarios, o al menos no por una petición directa y sin privilegios, o al menos no para modificarlos a libre antojo, básicamente debe manejarlos el motor
<ficheroEnUso>ocupado, libre, en espera</ficheroenuso>
<Id_QueryEnuso> 0=ninguna, >1 esa id de query.. 0=bloqueado</Id_QueryEnUso>
<horaAccesoaFichero>momento en el que se le concedió el acceso</HoraAccesoaFichero>
<niveldePrivilegiodeQuery>dado un rango binario expresar dicho nivel</nivelPrivilegiodeQuery>
<permisodeAccesoBD>con contraseña, sin contraseña, partes con y sin contraseña, auditado desde un fichero de usuarios,etc...<permisodeAccesoBD>
...
... otros datos de la bd en general
...
<fileheader>
<querys> mantiene los datos de las querys en curso, siempre será un número limitado y pequeño 4-16-32...puede usarse un trigger para registrar cada query en un log...
<nºQuerysEnCurso>mantiene el ritmo de admitir querys otomándolas de una pila de llamadas de querys en espera de ser procesadas, por ejemplo si se tiene una query en BD dos en Headers está todo ocupado, pero si hay una menos el motor puede aceptar otra query a procesar...</nºquerysEncurso>
<nºQueysenPila>mientras halla más de una el motor de la Bd irá recoogiendo querys y procesando, si hay tareas internas pendientes con preferencia les dará una mayor prioridad si la pila de querys es casi nula que si hay acumuladas 300 peticiones..., por otro lado puede ser más efectivo no tanto llevar la cuenta de ellas sino si hay más de cierto número, lo cual se consultaría tras procesar ese número de consultas si las hay , o más a menudo si dicha cifra es menor, a tal efecto entonces se debería tener una variable.<nºquerysEnPila>
<queryBD>id de query en la BD actualamente 0=esta libre.</queryBD>
<queryValidada>1=si, 0=en proceso(en la query bd ya se supone validada, -1=error de query, la query es errónea, pero en control se indicó reportar si parcialmente la query podía ser procesada (esto ayuda a un usuario (junto al error devuelto) a saber y comprender mejor por donde van los fallos en función de lo que le devuelva) ¡¡¡-esta es una de mis ideas-!!! </queryValidada>
<queryString> por ejemplo Select all from sueldos where profesion='medico' and especialidad='otorrino' and provincia='Huesca'</queryBD>
<horaAceptacion>la hora en que se le asigno la id a la query(moemnto en le que fue cursada su entrada, luego es cuando se valida</horaAceptacion>
<horaSalida>hora a la que se devolvió la salida, este dato procesado con el hora de aceptación determina el tiempo de respuesta de la query, lo cual sirve para evaluar el motor y la propia query...en base a su optimización y rendimiento</horaSalida>
<devolvióDatos>-1=ninguno, no se halló resultados (por si se quiere procesar algún tipo de mensaje cuando len(respuesta)=0, 0=se devuelven pero se ignora si son adecuados (cuando se procesa parcialmente una query errónea, no se totaliza su reultado, ya que el error en si son datos devueltos, es este valor el que determina en destino si es error o no, los datos de error no se dan en formato mensaje emergente, sino igualmente estructurado como cualquier tabla de buen vecino, con todos y cada uno de sus campos bien definidos) esto permite al usuario si quiere ignorar el resultado , es decir para modo debug.... 1=se enviaron datos</devolvioDatos>
...
... otros datos
...
</queryBD>
<queryHeader1>
...
... datos de la query en header, tablas afectadas, tipo de acción para determinar si se bloquea el acceso a la bd a la otra query sin esta terminar antes o no.... en fin cosas para controlar...
...
...
... datos de la query en fichero de cabecera, salvo una query totalmente rechazada, o anulada toda query de este tipo pasa por la query de datos anteriormenete recogida
</queryHeader1>
</queryHeader2>
...
... igual que query 1
...
</queryHeader2>
<queryPrincipal>
...
... cuando la query implique modificar el fichero de headers, dicha query se aloja aquí... ya que los ficheros de headers 1 2 deben ser eliminados y creados nuevamente como copia de este principal tras ser modificado.
...
</queryPrincipal>
<queryConsultas>
<nºQuerysenCache> nº de querys guardadas temporalmente</nºQuerysenCache>
<queryConsultaCache1>
...
... a menudo una query se invoca más de una vez en escaso tiempo, en tal caso mantener en cache un cierto tipo de querys y sus repuestas asociadas, acelera la búsqueda porque solo hay que decidir si las consultas son idénticas y si sigue vigente, es decr una query de consulta en cache, deja de ser vigente tras alterarse los datos a que hace referencia alguna de sus tablas y/o campos afectados (los datos de los campos o los propios campos). también deja de ser vigente tras cierto nº de querys (van rotando) .sería deseable tener al menos hasta 8 consultas en caché de cada tipo, en cualquier caso binario...
...
</queryConsultaCache1>
<queryConsultaCacheN>
...
...
...
</queryConsultaCacheN>
<queryConsultas>
<queryDelete>
<nºquerysenCache> nº de querys guardadas temporalmente</nºQuerysenCache>
<queryDeleteCache1>
...
...
...
</queryDeleteCache1>
<queryDeleteCacheN>
...
...
...
</queryDeleteCacheN>
<queryDelete>
<queryUpdate>
<nºquerysenCache> nº de querys guardadas temporalmente</nºQuerysenCache>
<queryUpdateCache1>
...
...
...
</queryUpdateCache1>
<queryUpdateCacheN>
...
...
...
</queryUpdateCacheN>
<queryUpdate>
<queryCreate> para mi crear una tabla nueva es una petición más al motor de ESTA BD y create una BD es ya de un nivel superior....
<nºquerysenCache> nº de querys guardadas temporalmente esto no suele ser frecuente por lo que su número podría ser más pequeño, aunque a favor tienen que sus datos ocupan menos espacio</nºQuerysenCache>
<queryCreateCache>
...
...
...
</queryCreateCache>
<queryCreateCache>
...
...
...
</queryCreateCacheN>
<queryCreate>
...
... otros datos de control...
...