• Jueves 28 de Marzo de 2024, 10:05

Autor Tema:  Que Deveria Tener Una Bd?  (Leído 7452 veces)

su -

  • Moderador
  • ******
  • Mensajes: 2349
    • Ver Perfil
Que Deveria Tener Una Bd?
« en: Jueves 8 de Junio de 2006, 01:41 »
0
Hola.
Bueno, ya que he tenido que hacer un motor de base de datos, me pregunto, que deveria de tener para que fuera perfecta?
 :blink:
*******PELIGRO LEE ESTO!!*******

There is no place like 127.0.0.1

Conecto luego existo, no conecto luego insisto.

ing_marco

  • Miembro MUY activo
  • ***
  • Mensajes: 263
    • Ver Perfil
Re: Que Deveria Tener Una Bd?
« Respuesta #1 en: Jueves 8 de Junio de 2006, 14:22 »
0
Hola, me llamo mucho la atencion tu post, explicame como asi hiciste un motor de base de datos.
Si puedes facilitarme documentacion seria perfecto y te lo agradeceria y monton.

Atte
Ing_Marco
MARCO DIAZ
Ing_Marco
Bachiller Ing de Sistemas.
UNT
Trujillo-Peru

JuanK

  • Miembro de ORO
  • ******
  • Mensajes: 5393
  • Nacionalidad: co
    • Ver Perfil
    • http://juank.io
Re: Que Deveria Tener Una Bd?
« Respuesta #2 en: Jueves 8 de Junio de 2006, 14:30 »
0
manejo de integridad referencial
indexacion binaria
indexacion por mapas de bit
indexacion basada en funciones
control de acceso
administracion de recursos entre sesiones
soporte para pl/sql
soporte para sql
soporte para al menos uno de los lenguajes de punta ( java, .net )
particionamiento
cluster
constraints
jobs
administracion de tablespaces
secuencias
vistas
sinonimos
snapshots
rollback segments
queues
db directories
types
triggers
dblink
perfiles
politicas
sinonimos
mecanismos de recuoperacion
bakups
securitty logs
planes de ejecucion
generacion de estadisticas
planes de ejecucion determinables en tiemop de ejecucion a traves de estadisticas
soporte para transacciones en paralelo
estadisticas detalladas de datos ( histogramas) para determinar planes de ejecucion
optimizer hints
Builtings como utilitarios estandart y no estandart para manejo de cadenas, archivos, generacion de estadisticas, ejecucion de pl/sql sql dinamico, programacion de tareas, salidas por consola etc
Soporte para sentencias DDL y DML
etc
etc
etc.

en resumen, tener como minimo todo lo que tiene una base de datos ORACLE.  :scream:  :o
[size=109]Juan Carlos Ruiz Pacheco
[/size]
Microsoft Technical Evangelist
@JuanKRuiz
http://juank.io

ing_marco

  • Miembro MUY activo
  • ***
  • Mensajes: 263
    • Ver Perfil
Re: Que Deveria Tener Una Bd?
« Respuesta #3 en: Jueves 8 de Junio de 2006, 14:32 »
0
Jejejeje creo que fuiste muy explicito con tu ultimo parrafo.
Pero expliquenme como hacer una manejador de base de datos.
MARCO DIAZ
Ing_Marco
Bachiller Ing de Sistemas.
UNT
Trujillo-Peru

su -

  • Moderador
  • ******
  • Mensajes: 2349
    • Ver Perfil
Re: Que Deveria Tener Una Bd?
« Respuesta #4 en: Jueves 8 de Junio de 2006, 21:47 »
0
Wow, Juank, gracias por el listado, veo que voy a tener que trabajar mas.
Citar
Hola, me llamo mucho la atencion tu post, explicame como asi hiciste un motor de base de datos.
Si puedes facilitarme documentacion seria perfecto y te lo agradeceria y monton.

Atte
Ing_Marco
Lo que he hecho es muy simple y lo tengo que implementar, es tan solo una libreria que crea un archivo para almacenar datos.
Por ahora es muy simple, pero se puede mejorar, esta es la idea:
Se crea un archivo con un encabezado que contiene lo que indica el tipo de archivo, y el numero de bits en el que se encuentran las tablas, es decir:
DB 1:12:2:80...
El prgrama lee sieta cantidad de bits, hasta que el final de la linea sea una nueva (\n)
Despued de la palabra DB hay un espacio o un caractel para saber cundo empiesa la informacion de las tablas, no hay informacion sin tablas, es decir, toda la info esta en tablas.
el numero de la tabla es seguido por dos puntos (:) y el numero de bits donde empiesa la tabla, esto lo hago asi, porque no encuentro forma de hacerlo sin que se sature la memoria, es decir, normalmente haria un while para esto usando open, pero uso binmode, seek y read (fopen de stdio en C) y fuera de eso, lo hago asi por que cada tabla estaria compresa con LZW, ya se que todo esto suena muy mal, muy lento, pero realmente no lo es, ya que las funciones de abrir y la informacion de la BD funcionan por separado:
En la libreria, se crea una funcion (todo en OO) que abre la BD y lee la informacion (el archivo se sierra), al momento de guardar o leer un talba/elemento esta nuevamente abre el archivo y lo guarda segun las espesificaciones, realmente la BD nunca es trabajada en memoria.
Tambien doy la opcion de encryptarla con Blowfish...
Lo otro que dice Juank, esta en camino  ;)
*******PELIGRO LEE ESTO!!*******

There is no place like 127.0.0.1

Conecto luego existo, no conecto luego insisto.

ing_marco

  • Miembro MUY activo
  • ***
  • Mensajes: 263
    • Ver Perfil
Re: Que Deveria Tener Una Bd?
« Respuesta #5 en: Miércoles 14 de Junio de 2006, 04:50 »
0
Me rayaste con tu explicacion,creo que revisare mas acerca de esto para poder implementarlo.

Si puedes mandarmealgo de informacion seria excelente y estariamuy agreadecido.

Atte
Ing_Marco
MARCO DIAZ
Ing_Marco
Bachiller Ing de Sistemas.
UNT
Trujillo-Peru

chimps

  • Miembro MUY activo
  • ***
  • Mensajes: 208
    • Ver Perfil
    • http://quiqueq.blogspot.com
Re: Que Deveria Tener Una Bd?
« Respuesta #6 en: Miércoles 14 de Junio de 2006, 05:11 »
0
solo por curiosidad su -, que estructura de datos estas usando para el manejo de informacion?...guardas todo secuencialmente en archivos binarios o usas una mezcla de arboles (B+, rojinegro...lo que sea) y tablas hash?

su -

  • Moderador
  • ******
  • Mensajes: 2349
    • Ver Perfil
Re: Que Deveria Tener Una Bd?
« Respuesta #7 en: Sábado 22 de Julio de 2006, 00:06 »
0
Cita de: "chimps"
solo por curiosidad su -, que estructura de datos estas usando para el manejo de informacion?...guardas todo secuencialmente en archivos binarios o usas una mezcla de arboles (B+, rojinegro...lo que sea) y tablas hash?
Perodon por no responder antes, pero no vi el post  :rolleyes:
La estructura es muy similar a XML y esta fragmentada como HTML (en forma de tablas con TR, TD...) en donde cada objeto es compreso con LWP o Zlib.
La idea es hacerlo por medio de hashes multidimencionales (en forma de vectores) y almacenado en una forma basada en bioperl algo asi como:
Código: Text
  1. <table="nombre" size="tamaño_de_tabla">
  2. <Item="nombre">dato bla bla bla</item>
  3. </table>
  4.  
  5.  
Ahora estoy mirando un par de modulos para implementarlo.
*******PELIGRO LEE ESTO!!*******

There is no place like 127.0.0.1

Conecto luego existo, no conecto luego insisto.

Last Dragon

  • Miembro MUY activo
  • ***
  • Mensajes: 109
    • Ver Perfil
    • http://www.lastdragon.net
Re: Que Deveria Tener Una Bd?
« Respuesta #8 en: Domingo 23 de Julio de 2006, 21:11 »
0
salvo tengas en mente un algoritmo nuevo y revolucionario, lo mejor seria que ese tiempo lo inviertieras en hacer perfecta postgress =)
Servidor Personal de Last Dragon



www.lastdragon.net

JuanK

  • Miembro de ORO
  • ******
  • Mensajes: 5393
  • Nacionalidad: co
    • Ver Perfil
    • http://juank.io
Re: Que Deveria Tener Una Bd?
« Respuesta #9 en: Domingo 23 de Julio de 2006, 21:43 »
0
Cita de: "Last Dragon"
salvo tengas en mente un algoritmo nuevo y revolucionario, lo mejor seria que ese tiempo lo inviertieras en hacer perfecta postgress =)
Creo que lo que su- quiere es aprender.  :smartass:  y no hay nada mejor que eso. :kicking:
[size=109]Juan Carlos Ruiz Pacheco
[/size]
Microsoft Technical Evangelist
@JuanKRuiz
http://juank.io

su -

  • Moderador
  • ******
  • Mensajes: 2349
    • Ver Perfil
Re: Que Deveria Tener Una Bd?
« Respuesta #10 en: Domingo 23 de Julio de 2006, 22:07 »
0
Cita de: "JuanK"
Cita de: "Last Dragon"
salvo tengas en mente un algoritmo nuevo y revolucionario, lo mejor seria que ese tiempo lo inviertieras en hacer perfecta postgress =)
Creo que lo que su- quiere es aprender.  :smartass:  y no hay nada mejor que eso. :kicking:
Correcto  :D
*******PELIGRO LEE ESTO!!*******

There is no place like 127.0.0.1

Conecto luego existo, no conecto luego insisto.

su -

  • Moderador
  • ******
  • Mensajes: 2349
    • Ver Perfil
Re: Que Deveria Tener Una Bd?
« Respuesta #11 en: Martes 9 de Enero de 2007, 02:56 »
0
Pues, para al que le interese lo que he hecho:
Ya no uso nada de "tags", eso de <table> es muuuy lento si el archivo es muy grande, ahora estoy intentando una forma mas funcional, no se como se llama el algoritmo pero es muy similar a los archivos creados por ar (como los paquetes de debian) pero, a diferensia de ar o tar no se crea headers por cada archivo, me explico:
Un archivo ar tiene este formato (sin comtar el numero magico):
Código: Text
  1. headers
  2. archivo
  3. headers
  4. archivo
  5.  

En la base de datos trato de hacer algo como:
Código: Text
  1. headers
  2. archivo
  3. archivos
  4.  

Ahora ¿Por que?
Bien, la forma de un .ar es rapida pero requiere de una lectura constante para llegar a X archivo, digamos que tienes 3 archivos en un .ar; si quieres sacar el #2 tendras que leer el primero para pasar por al segundo y leer los headers para verificar si ese es el archivo, claro, los datos de los headers no queda en buffer pero si toma mas tiempo de lo que tengo en mente (y en codigo  ;) )
Si metemos todos lo headers desde el inicio tenesmos una lectura mas rapida para actuar en un bloque o tabla de datos pero, claro, jugamos con el problema de saber donde se inicia un dato y donde termina, pero eso es determinado por el tamaño del archivo que esta puesto en los headers (incluye un checksum MD5, como tar, para ver si el archivo esta dañado) y asi no tenemos que leer toda la parte de los datos y meterlo en un buffer, solo tenemos que leer desde un punto dado (por el tamaño de datos) aunque en mas dificil de lidiar requiere de menos recursos en cuanto a lectura.
*******PELIGRO LEE ESTO!!*******

There is no place like 127.0.0.1

Conecto luego existo, no conecto luego insisto.

dBase3

  • Miembro activo
  • **
  • Mensajes: 85
    • Ver Perfil
Re: Que Deveria Tener Una Bd?
« Respuesta #12 en: Jueves 11 de Enero de 2007, 15:56 »
0
-su fantastica idea esa, lo que me cuesta un montón leer tus posts por los cambios que haces en el lenguaje, y lo intento .. me pierdo en ver q quieres decir con la gramatica.
instalate el firefox 2 y directamente te da un link para el diccionario, te subraya en rojo hasta los acentos por ejemplo monton lo tengo subrayado.

Al grano:
-Yo creo q lo fundamental es hacer un gestor en plan cola-cache por un lado que gestione la transacciones y por otro el motor ensi mismo.
Yo hice algo asi con dbase como base de datos q es muy rápida sinceramente. y por otro lado un gestor con la cola.

Revisa el codigo internamente ... de como esta hecho el dbase III, que es facil de conseguir en internet y te explica los separadores y cabeceras que usan te puede dar alguna idea.
Por otro lado no deben ser de longitud fija los registros.
Puedes hacer ficheros separados para cada tabla o no.

Bueno suerte y felicidades por la idea ...


@-su si tuvieras unas notas organizadas donde explicas la estructura y el acceso, asi como las transacciones, sería más facil.(cuando veas el de dbase sabras lo q digo)

Aqui tienes el link que no es el gestor de cola cache que hice para el manejo de dbase(no la publiqué), pero si es una aproximación ya que asi se admite multi acceso y otras opciones(seudo Locking)

Gestionar Dbase desde un programa externo con transacciones (no del tipo SQL, sino tipo DBASE)

@JuanK bueno creo q te pasaste, como en la lista de los reyes magos para la basedatos, no se si es demasiado para -su.

@-su Con que incluya algunas mejoras como q :
  • Funcione rápido tanto en lectura como en escritura</li>
  • Haga sus copias de seguridad (mirrorring)</li>
  • Tenga el cache/gestor y un sistema de indices por arbol básico. </li>
  • Acepte SQL en un puerto cualquiera fantástico.</li>
Ya con esto que he dicho y se me queda algo, creo q sería mejor que el mismismo access en cuanto estructura, rapidéz y ahorro de espacio. No hablemos del acceso para redes.
(la verdad q he puesto el liston bajo jejeje,  pero hay q empezar por ahi)

Por seguir avanzando con tu proyecto Una vez tengas una versión estable:
Si te parece bien, me gustaría hacer una pequeña librería para usar tu base de datos para los que usamos Autoit (si funcionara) también valdría para hacer tus páginas dinámicas web tipo php-mysql.

Si necesitas hacer alguna utilidad rápida para la base te lo hago en Autoit.(con tiempo)

su -

  • Moderador
  • ******
  • Mensajes: 2349
    • Ver Perfil
Re: Que Deveria Tener Una Bd?
« Respuesta #13 en: Domingo 14 de Enero de 2007, 02:38 »
0
:o  Bueno gracias dBase3 tomo en cuenta lo que decis.

Bien me tratare de explicar un poco mejor:

La base de datos que estoy haciendo esta hecha en Perl (suena feo, pero no lo es  :D  ) y usa lectura por bytes (no por linea como normalmente se hace en Perl para archivo chicos).

Si has visto un comando en Unix llamado Ar, tendras una idea de lo que hago.

El Ar funciona muy simple, hace un header de archivo (nombre, tamaño, uid, gid), pone el archivo y hace esto para cada uno es decir:
header de archivo 1
archivo 1
header de archivo 2
archivo 2
Y asi con cada uno.
Este sistema es tan bueno y simple que se usa Tar (archivos .tar) pero tiene un problema cuando intentas aplicarlo a una base de datos: cuando quieres sacar X dato que no es del primer archivo te toca buscar por cada archivo hasta llegar al que se quiere y eso consume muchos recursos  cuando la base de datos es muy grande.

Mi idea es poner todos los headers al inicio del archivo y asi solo tendria que ir al lugar en el que esta.
El problema es mantener los headers y los datos en el lugar correcto.

Bien, ahora ¿Por que Perl?
Es el lenguaje con el que mejor me llevo  :rolleyes:
Asi puedo integrar cualquier base de datos que yo quiera con el modulo DBI si es que quiere hacer la parte de redes.
Una de las ideas para hacer esto es que lo podre usar en todos mis proyectos que necesiten guardar datos pero que no requieran algo muy grande ni nada por red.

Por ahora tengo unos problemas de portabilidad y otras cosas, la idea es mas amplia de lo que crees y tengo en mente unos conceptos nuevos que no deceo que mo los quiten  :P (la verdad es que no tengo ninguno)
*******PELIGRO LEE ESTO!!*******

There is no place like 127.0.0.1

Conecto luego existo, no conecto luego insisto.

Nebire

  • Miembro HIPER activo
  • ****
  • Mensajes: 670
    • Ver Perfil
Re: Que Deveria Tener Una Bd?
« Respuesta #14 en: Domingo 9 de Septiembre de 2007, 06:19 »
0
Hola -su, es curioso... a mi también me interesa mucho los motores de base de datos, de hecho estoy diseñando (en los tiempos libres) los esquemas y reuniendo ideas para hacer un miniSQL que en esencia tendría todo lo que tiene un SQL pero sin tanta tontería, es decir esos recovecos que casi nadie conoce y cuya utilidad es muy muy limitada y es la que sirve de pie a los fallos de seguridad.

Aparte de eso, pretendo algunas cosas más, lo más esencial es la sencillez de uso, para ello lo implementaré tal como es el español, donde cada parte de la oración gramatical puede casi cambiar de sitio y seguir teniendo el mismo significado, esto evita los errores por falta de ese aprendizaje concienzudo que se requiere para manjar bien las bases de datos.

También quiero proveerlo de sinónimos, es decir porqué usar siempre 'delete' y solo delete ?? .. en el lenguaje normal usamos hasta una veintena de sinónimos, entonces en mi bd 'borrar' 'eliminar' 'destruir' 'tirar' podrán usarse indistintamente, además daré soporte a sinónimos particulares, es decir si uno prefiere emplear el término 'ahorcar' para referirse a 'borrar' podrá hacerlo (de acuerdo a unas sencillas reglas.... aunque la idea del sinónimo libre de usuario va más enfocado a exportarlo a otros idiomas partiendo de una tabla o esquema que se tomaría de un archivo como tabla de traducción... dicho de otro modo que nadie tendrá que aprender el manejo de dicha base de datos en español o inglés, sino en su propio idioma de su país (o en el de su familia si así se quiere y contruye dicha tabla).

La parte más relevante ... el de velocidad lo tengo resuelto, pués he desarrollado el algortimo más eficiente del mundo en cuanto a ordenar listas se refiere, de hecho aun en alto nivel es el doble y más de rápido que cualquiera en escrito en bajo nivel, además sea el nivel de desorden que haya tarda siempre exactamente lo mismo en calcularlo, no hay por tanto ni mejor ni peor caso... ya que soy de lo más pobretón, quiero patentarlo y ver si me deja algún beneficio que me permita vivir un poco dignamente y tapar esos agujeros (si negros, negros.. vamos hacienda o no es negro ?)...

Quería comentarte de paso algo sobre tu esquema.... y ya me dirás:
Citar
cuando quieres sacar X dato que no es del primer archivo te toca buscar por cada archivo hasta llegar al que se quiere y eso consume muchos recursos  cuando la base de datos es muy grande.

Mi idea es poner todos los headers al inicio del archivo y asi solo tendria que ir al lugar en el que esta.
El problema es mantener los headers y los datos en el lugar correcto.

Te entiendo, pero yo lo que haría en este caso tuyo es mantener otro archivo sólo para esto, es decir por un lado los datos y por otro las referencias de los datos, es decir la tabla tal empiez en el byte 45678, esos punteros los pondría en otro fichero, y ese otro fichero si que tendría 'headers' para los nombres de las tablas (tal como indicas similar a la estructura xml) y por tanto haciendo su búsqueda en árbol tampoco en modo secuencial...

un esquema un poco rápido sería algo como esto:
esquema para el fichero de cabeceras de la BD
Código: Text
  1.  
  2. &#60;ultraHeader&#62;
  3.    &#60;nombreHeaders&#62; nombre de este fichero de headers para relacionar la BD, con el fichero de headersy de control&#60;/nombreHeaders&#62;
  4.    &#60;nombreControl&#62;mi nombre aunque se cambie el del fichero este es el original cuando se creó&#60;nombreControl&#62;
  5.    &#60;nombreBD&#62;nombre de la bd, aunque se le cambie al archivo, se sabe como se llama&#60;/nombreBD&#62;
  6. &#60;/ultraHeader&#62;
  7.  
  8. &#60;HeaderFile&#62;  descripción: contendría info esencial de la BD
  9.    &#60;finHeaderFile&#62;byte en el que acaba el headerfile&#60;/finheaderfile&#62;
  10.    &#60;nºTablasAlojadas&#62;cuantas tablas tiene alojadas dicho fichero&#60;/nºTablasAlojadas
  11.    &#60;incrementoBD&#62;tamaño en Mb. que se autoincrementará la BD (se reserva) para aumentar si queda cierto espacio libre... impedirá que una base de datos se cuelgue si no hay espacio en disco....habrá triggers para comprobar esta situación &#60;/incrementoBD&#62;
  12.    &#60;%libreParaIncremento&#62;el incremento será automático cuando quede menos del tanto porciento de espacio libre en la BD&#60;/%libreParaIncremento&#62;
  13.    &#60;LibreDesde&#62;puntero al byte  en el fichero de la bd donde ya está libre, para calcular espacio libre y ocupado , y puntero donde escribir nuevos datos&#60;/LibreDesde&#62;
  14.     ..
  15.     ..
  16.     ..
  17. &#60;/HeaderFile&#62;
  18. &#60;nºTablas&#62; cuantas tablas tiene la bd&#60;/nºTablas&#62;
  19.    &#60;Tabla&#62;
  20.       &#60;nombreTabla&#62; nombre de una tabla dada&#60;/NombreTabla&#62;
  21.       &#60;PunteroTabla&#62; puntero en byte donde comienza esta tabla en el fichero de datos&#60;/PunteroTabla&#62;
  22.       &#60;finPunteroTabla&#62;puede no ser relevante, pero de entrada no está de más&#60;finPunteroTabla&#62;
  23.       &#60;nºCampos&#62; cuantos campos tiene para procesar su info&#60;/nºCampos&#62;
  24.          &#60;campo&#62;
  25.             &#60;tipoValor&#62; string, booleano, integer...etc...&#60;/tipovar&#62;
  26.             &#60;EsId?&#62;indica si está marcado como identificador&#60;/esId?&#62;
  27.                &#60;EsAutoIncremental&#62;booleano que indica si se autoincrementa&#60;/.....&#62;
  28.               ...
  29.               ...   otros datos que recoge cada campo
  30.               ...
  31.          &#60;/campo&#62;
  32.          &#60;campo&#62;
  33.              ... los sigueintes campos  
  34.          &#60;/campo&#62;
  35.       &#60;nºRelaciones&#62;cantidad de relaciones que tiene la tabla&#60;/nºRelaciones&#62;
  36.          &#60;RelacionConTabla&#62; nombre de tabla relacionada&#60;/RelacionConTabla&#62;
  37.          &#60;CantidadCamposRelacionados&#62;se usa para saber cuantas etiequetas de las que siguen hay que repetir&#60;/cantidadCamposRelacionados&#62;
  38.             &#60;relacion&#62;
  39.                &#60;RelacionDesdeCampo&#62; nombre del campo LOCAL de esta tabla &#60;/RelacionDesdecampo&#62;
  40.                &#60;RelacionConCampo&#62;campo INVITADO tabla relacionada,estos dos etiqetas van emparejas tantas como indique cantidad de campos relacionados&#60;/RelacionConCampo&#62;
  41.                &#60;primario&#62;en esta relación el campode esta tabla es quien relaciona o es relacionado (dirección  de la relación)&#60;/primario
  42.            &#60;/relacion&#62;
  43.            &#60;relacion&#62;
  44.                  ...
  45.                  ...datos de la relacion...
  46.                  ...
  47.            &#60;/relacion&#62;
  48.          ...
  49.          ... mas datos de tabla
  50.          ...
  51.    &#60;/tabla&#62;
  52.    &#60;tabla&#62;
  53.           ...
  54.           ...
  55.           ...
  56.    &#60;/tabla&#62;
  57.        ...
  58.        ... más tablas
  59.        ...
  60.  
  61.  
Como puedes ver en este esquema, si se hace bastante completido ya puede ser complejo y profundo, por ello entiendo que es más fácil y mejor tratar independientemente cada aspecto de la base de datos, además esto facilita la concurrencia, me explico:
 Supongamos que tenemos creado esos dos ficheros de los datos de la BD (el de cabeceras con info de la tabla y el de los datos ) de entrada al abrir la base de datos hago DOS copias del fichero de cabeceras, usando el mismo nombre y canbiando la extensión como quiera que aunque una DB sea muy grande, este fichero siempre será bastante más pequeño por tanto esta copia es rápida... bien si ahora hago una solicitud de BUSQUEDA (no delete ni insert : table, ni modificar aspectos de los campos, es decir que no hace variar a este fichero)  mientras se procesa la solicitud buscando en dicho fichero(en una copia), otra consulta puede estar buscando en el fichero de datos, así no es preciso que quede libre el fichero de cabeceras para iniciarse otra query, ya que las querys alternan el uso de una copia u otra según la que no esté en uso, luego el primero que termina de procesar en el fichero de cabeceras 'marca' que ya empieza a usar el fichero de datos, así si mientras la otra query termina si debe esperar, pero al mismo tiempo que se marca que empieza a buscar en el fichero de datos, marca que el fichero de cabecera x ya está libre para otra concurrencia de query, así mientras se valida una query con el fichero de cabeceras, etc... otra consulta está trabajando cen el fichero de datos, luego los tiempos de espera se reducen...

Si en un momento dado la query solicitada es modificar una tabla, eliminarla o crear, implica modificar el fichero de cabeceras, en este caso,  esta query mientras se valida debe esperar a que se marquen libres las 2 copias, estas se eliminan y si aún no está libre el fichero de datos se espera, luego se rematan las acciones en aquella y mientras se hace esto se crean nuevamente esas copias de los ficheros de cabeceras... vamos que una query está en la BD(datos), mientras otras 2 pueden estar en las bd(cabeceras) validando las querys....

Fíjate que con tu sistema de todo en un sólo fichero sólo puedes indicar otro proceso cuando el primero termine totalmente su cometido, es decir hay muchos tiempos de espera, en bases de datos con muchos usuarios...

Y porque usamos las 2 copias y no la original BD(cabecera) ?: porque en ella cada query 'marca' , 'estoy trabajando en la tabla x.y,m si quereis consultar esperad'...claro que marcar esto es mucho más rápido que validar la query y más rápido aún que procesar los datos de la query en la BD(datos).... vamos es un esquema bastante más óptimo, dado que el tuyo queda monousuario.

Naturalmente debe haber un pequeño conjunto de reglas, si voy a alñadir datos a la tabla 'sueldos' y luego voy a hacer la media, pero debo esperar a la consulta saliente deje la bd, la 2ª consulta, pongamos que es más rápido en validarse la query 'hallar la media de la tabla sueldos en el campo medicos' que validar la query 'actualizar la tabla sueldos en los campos medicos, hospital, horario, extrax relacionado con la tabla atrasos_pendientes en los campos medicos, horarios,hospital,extras', en ese caso no puedo enviar a la query 2ª (la que hallaba la media) a la bd, ya que los datos de ésta dependen de la anterior.... una norma básica pués sería: si id_query (a cada query se le da un id, como en las colas del paro, que representa tu 'turno') que ha sido validada (query2 es mayor que la id_query(de la query en proceso de validación, llamémosla query1) y la query 2 trabaja en alguna tabla que la query 1 ha marcado y la query no es consultar datos(leer), sino escribir, entonces query2 debe esperar a que query1 termine...

....me estoy extendiendo...

Citar
la idea es mas amplia de lo que crees y tengo en mente unos conceptos nuevos que no deceo que mo los quiten

jejeje.... a mi me pasa lo mismo, pero suele ocurrir 2 cosas casi a igual promedio, que la mitad de esas ideas-conceptos nadie los tiene concebiso, y que por el contrario la mitad de esas ideas-conceptos gran parte tambien lo tiene concebido... normalmente los segundos surgen de los defectos o carencias que te vas encontrando, los primeros surgen de la lucidez cuando trabajs en otro campo y de repente una solución para una cosa extraña te das cuenta que con pocos cambios, o algunos más vale aplicarlo a otro campo, es por ello que resulta difícil que otros estén también en eso mismo, aunque estén en otras cosas que de algún modo compete por ahí pero de manera muy alejada...

ah...una cosa olvídate de las bases de datos en dbse, te recomiendo centrarte en bases de datos relacionales de última generación, aunque cualquier base de datos puede enseñar muchas cosas, las antiguas suelen llevar por el camino, cuyo final es un callejón sin salida, digo sin futuro ... no en vano van siendo abandonadas poco a poco (poco a poco porque de un plumazo no puedes dejar a los usuarios colgados, si no lo harían).

...Entonces retomando el hilo(que me he saltado), el fichero de datos tendría un esquema sin los headers de la tabla, más aún existe la necesidad de tener otro fichero con datos acerca del fichero de datos (no acerca de los datos contenidos, para eso era el fichero de cabeceras de tablas y campos) ni tampoco los datos que en si mismos se valen, sino de otros datos acerca del fichero como cualquier fichero, pero por lo mismo que lo anterior, para evitar problemas de concurrencia, digamos que aunque su escritura es rápida, impide lectura que es donde está el gran tiempo empleado en las querys, por tanto todo proceso que alivie a dicho archivo bienvenido sea... vamos que las piernas han de correr, no pensar , para eso está la cabeza que ella no puede correr...

...y aunque este puede tener algunos esquemas diferentes que pueden merecer su buena lógica, uno de ellos podrías ser algo como:
fichero de control del fichero de datos
Código: Text
  1.  
  2. &#60;ultraHeader&#62;
  3.    &#60;nombreControl&#62;mi nombre aunque se cambie el del fichero este es el original cuando se creó&#60;nombreControl&#62;
  4.    &#60;nombreBD&#62;nombre de la bd, aunque se le cambie al archivo, se sabe como se llama&#60;/nombreBD&#62;
  5.    &#60;nombreHeaders&#62; nombre del fichero de headers para relacionar la BD, con el fichero de headers&#60;/nombreHeaders&#62;
  6. &#60;/ultraHeader&#62;
  7. &#60;fileHeader&#62; 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
  8.    &#60;ficheroEnUso&#62;ocupado, libre, en espera&#60;/ficheroenuso&#62;
  9.       &#60;Id_QueryEnuso&#62; 0=ninguna, &#62;1 esa id de query.. 0=bloqueado&#60;/Id_QueryEnUso&#62;
  10.       &#60;horaAccesoaFichero&#62;momento en el que se le concedió el acceso&#60;/HoraAccesoaFichero&#62;
  11.       &#60;niveldePrivilegiodeQuery&#62;dado un rango binario expresar dicho nivel&#60;/nivelPrivilegiodeQuery&#62;
  12.    &#60;permisodeAccesoBD&#62;con contraseña, sin contraseña, partes con y sin contraseña, auditado desde un fichero de usuarios,etc...&#60;permisodeAccesoBD&#62;
  13.    ...
  14.    ... otros datos de la bd en general
  15.    ...
  16. &#60;fileheader&#62;
  17.  
  18. &#60;querys&#62; 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...
  19.    &#60;nºQuerysEnCurso&#62;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...&#60;/nºquerysEncurso&#62;
  20.    &#60;nºQueysenPila&#62;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.&#60;nºquerysEnPila&#62;
  21.    &#60;queryBD&#62;id de query en la BD actualamente 0=esta libre.&#60;/queryBD&#62;
  22.       &#60;queryValidada&#62;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-!!! &#60;/queryValidada&#62;
  23.       &#60;queryString&#62; por ejemplo Select all from sueldos where profesion='medico' and especialidad='otorrino' and provincia='Huesca'&#60;/queryBD&#62;
  24.       &#60;horaAceptacion&#62;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&#60;/horaAceptacion&#62;
  25.       &#60;horaSalida&#62;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&#60;/horaSalida&#62;
  26.       &#60;devolvióDatos&#62;-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&#60;/devolvioDatos&#62;
  27.       ...
  28.       ... otros datos
  29.       ...
  30.    &#60;/queryBD&#62;
  31.    &#60;queryHeader1&#62;
  32.        ...
  33.        ... 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...
  34.        ...
  35.        ...
  36.        ... 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
  37.    &#60;/queryHeader1&#62;
  38.    &#60;/queryHeader2&#62;
  39.           ...
  40.           ... igual que query 1
  41.           ...
  42.    &#60;/queryHeader2&#62;
  43.    &#60;queryPrincipal&#62;
  44.         ...
  45.         ... 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.
  46.         ...
  47.    &#60;/queryPrincipal&#62;
  48.    &#60;queryConsultas&#62;
  49.       &#60;nºQuerysenCache&#62; nº de querys guardadas temporalmente&#60;/nºQuerysenCache&#62;
  50.       &#60;queryConsultaCache1&#62;
  51.           ...
  52.           ... 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...
  53.           ...
  54.       &#60;/queryConsultaCache1&#62;
  55.       &#60;queryConsultaCacheN&#62;
  56.             ...
  57.             ...
  58.             ...
  59.       &#60;/queryConsultaCacheN&#62;
  60.    &#60;queryConsultas&#62;
  61.    &#60;queryDelete&#62;
  62.       &#60;nºquerysenCache&#62; nº de querys guardadas temporalmente&#60;/nºQuerysenCache&#62;
  63.       &#60;queryDeleteCache1&#62;
  64.            ...
  65.            ...
  66.            ...
  67.       &#60;/queryDeleteCache1&#62;    
  68.       &#60;queryDeleteCacheN&#62;
  69.            ...
  70.            ...
  71.            ...
  72.       &#60;/queryDeleteCacheN&#62;
  73.    &#60;queryDelete&#62;
  74.    &#60;queryUpdate&#62;
  75.       &#60;nºquerysenCache&#62; nº de querys guardadas temporalmente&#60;/nºQuerysenCache&#62;
  76.       &#60;queryUpdateCache1&#62;
  77.            ...
  78.            ...
  79.            ...
  80.       &#60;/queryUpdateCache1&#62;    
  81.       &#60;queryUpdateCacheN&#62;
  82.            ...
  83.            ...
  84.            ...
  85.       &#60;/queryUpdateCacheN&#62;
  86.    &#60;queryUpdate&#62;
  87.    &#60;queryCreate&#62; 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....
  88.       &#60;nºquerysenCache&#62; 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&#60;/nºQuerysenCache&#62;
  89.       &#60;queryCreateCache&#62;
  90.            ...
  91.            ...
  92.            ...
  93.       &#60;/queryCreateCache&#62;    
  94.       &#60;queryCreateCache&#62;
  95.            ...
  96.            ...
  97.            ...
  98.       &#60;/queryCreateCacheN&#62;
  99.    &#60;queryCreate&#62;
  100.         ...
  101.         ... otros datos de control...
  102.         ...
  103.  
  104.  

Para mi la ventaja de la cachés es clara si se guardan ciertas cachés es más rápido servirlas que procesarlas, aún así puede haber unas reglas de uso,,, el admin de la BD decide si usarlas o no, si el tamaño de una salida de cahcé sobrepasa cierto tamaño queda desechada, el admin determina el tamaño en base a la memoria que dispone su sistema, una repesuesta procesada demasiado simple quizás no suponga excesiva ventaja meterla en caché. No obstante buscar entre 32 registros la coincidencia de una querystring es más rápido que realizarlo en la BD además la salida ya está procesada y además si sale coincidencia con la que exista en caché  la bd está libre para otra previa más tiempo que si esta estuviera en la cola... de todos modos el uso de cachés que sea acertado o no dependerá de como se utilice la bd, no es lo mismo un BD que aloja datos estadísticos de población  que una Bd de compras de como ebay, por poner un ejemplo o igual que una web corporativa de repuestos de automóovil... estás últimas posiblemente tengan poca carga de trabajo y no necesiten cachés y además sus consultas pueden ser muy sencillas limitándose en la mayoría de los casos a verificar si tienen un producto en stock y solicitarlo y consultar si fue enviado o totalizar facturas, etc...

bueno el esquema de los datos creo que ya puedes deducir más o menos como yo lo trazaría por tanto no me extiendo en hacerte algún esquema. Ahora bien si hay cosas en las que quieras profundizar, pués charlemos...

... bueno lo dicho me he estendido...
p.d.: se me olvidaba aclarar que eso del 'ultraHeader' sería para hacer corresponder los 3 ficheros entre si, ya que el motor debería mantener internamente una tabla con las bases de datos registradas en ellas y donde debería mantener campos para esos 3 ficheros, tanto el nombre del archivo como el nombre de la BD para evitar incongruencias, vamos que al abrir una bd el primer intentos es ir a dicha tabla localizar dicho nombre, tomar la ruta, comprobar que en dicha ruta existe ese archivo y que realmente es un archivo de la BD no un archivo cuialquiera renombrado...
«Ma non troppo»
----> ModoVacaciones = False<----

su -

  • Moderador
  • ******
  • Mensajes: 2349
    • Ver Perfil
Re: Que Deveria Tener Una Bd?
« Respuesta #15 en: Domingo 18 de Noviembre de 2007, 01:26 »
0
El tiempo corre pero el tema sigue...

Resulta que mi metodo es bastente malo y el de Nebire es un poco mejor, pero teambien es malo:


El mio es muy malo por una razon tipica en los file systems.
Todo empieza con FastFS (FFS), el file system usado por AROS y creado por Berkeley... resulta que usa un sistema similar al que yo uso ( toda la info al inicio del archivo como un header ) y fracaso porque al hacer archivos grandes y navegar por ellos tenia que leer el inicio del file system ( header ) para poder encontrar el archivo.
Para modificar, tenia que buscar el archivo, modificar y modificar el header... eso quiere decir que el disco duro sufre mucho y FastFS termina siendo muy lento.
Algo similar pasa con este modelo de DB, y mas al estar comprimido y al tener una firma digital.
El problema se puede solucionar creando un index, pero solo para lectura ya que no soluciona el de escritura.

El modelo de Nebire comprende de tablas, tendria un gran problema.... buscar una tabla en una DB de un par de Gb  o al usar un parse para asegurarse de que la tabla que esta leyendo si es una tabla de la DB y no de un data ingresado u otra DB guardada en esa DB.

El problema radica en usar puramente superblocks, el truco esta en los B-Trees o Trees... en fin, mi proyecto ha muerto y he aprendido lo suficiente, creo  :devil:
*******PELIGRO LEE ESTO!!*******

There is no place like 127.0.0.1

Conecto luego existo, no conecto luego insisto.