8 respuestas en este tema

[mati_pincha]

Hola amigos, les paso a comunicar un problema que no se me ocurre como resolver, pasa que hace bastante no uso delphi y bueno quizas en otra ocasion sabria que hacer jajaja... bueno les cuento que un modulo de mi programa( administracion odontologica)  posee una ficha odontologica con 5 Timage cada una pieza bucal, los Timage conforman cada pieza. ( no tengo otra forma de hacerlo para lo que lo necesito, solo imaginense que tengo muchisimas imagenes) Cada imagen la debo almacenar en una base de datos con toda la informacion de la ficha, cosa que ya hice pero mi duda es la siguiente: al tener tanta informacion no me alcanza en una sola tabla de access, por lo cual debo usar dos unidas no? .  Cual seria la forma correcta de unir las tablas para que sean como una sola? ya que piensen que tengo que tener la informacion de cada paciente relacionada entre las dos tablas y que esta se actualice en ambas a medida que se modifica la informacion en mi programa.. Les agradeceria si me ayudan a resolverlo. Muchas gracias!! Matias

[Delphius]

Hola,
Me resulta extraño de que digas que tienes tanta información que no cabe en una tabla.  ¿Podrías aportar más información sobre la estructura de tu base de datos? Eso podría ayudar a detectar el problema al que te enfrentas.

Describe con más detalles tu caso.
Access si tiene ciertas limitantes, y hasta el momento las que recuerdo están relacionadas con el tamaño máximo del archivo que es de 2GB. A menos de que las imagenes sean muy grandes, 2GB que si bien no son mucho, debiera de aguantar una respetable cantidad de registros.
Se puede hacer tablas/archivos vinculados... que es como distribuir la base de datos (en realidad, sus tablas) en dos o más archivos. No recuerdo el nombre técnico, en la propia ayuda de Access está sobre esto... creo recordar que se lo conoce como tablas vinculadas.

Lo de almacenar imágenes en una base de datos es de continuo debate. Tiene sus pros y contras... no es que es una otra opción sea mejor. Dependiendo de las necesidades, y consideraciones técnicas-operativas en ocasiones es mejor tenerlas en una carpeta específica y almacenar en la base de datos directamente el nombre y/o ruta del archivo. Y en otras ocasiones si es necesario almacenarlas.

Ahora bien, si se trata de un proyecto que podría seguir creciendo lo más adecuado sería que migres a un motor de base de datos serio. Si bien Access puede en ocasiones resultar suficiente, hay que reconocer que más pronto que tarde sus limitaciones lo hacen un producto inadecuado.
Access está más pensado para un entorno mono-usuario y de ofimática que no demande demasiado. Pero llega el momento en que no puede dar un merecido soporte como el que se espera.
Hay variadas opciones, incluso Open Source... como es el caso del gran Firebird; que hasta inclusive es multiplataforma.

Saludos,

[mati_pincha]

Hola, primero gracias por responder. Quizas estuve mal en no aclarar que no almaceno imagenes en la base de datos sino numeros que luego los asocio a una imagen de un imageList. Bueno eso lo tengo todo desarrollado ahora segun entiendo yo access tiene un limite de entradas (columnas) de 255, por lo cual yo tengo muchas imagenes distintas y ese rango no me alcanza, se puede extender de alguna forma? yo tenia entendido que no por eso iba a hacer dos tablas, siendo la segunda una extension de la primera. Por ejemplo para tener una idea mi tabla tiene los datos personales de un paciente y luego cada numero que referencia a una imagen ( 5 imagenes por pieza bucal, con un total de 50 piezas aprox) ej: NOMBRE  APELLIDO  DOMICILIO OBRA_SOCIAL PIEZA1.1 PIEZA1.2 PIEZA1.3 PIEZA1.4 PIEZA1.5 PIEZA2.1. Se entiende? espero que si. Gracias de nuevo! un saludo, Matias

[Delphius]

Hola,
La verdad es que no recuerdo si Access tiene ese límite de cantidad de campos para una tabla. Todos los motores serios tienen limitaciones en este punto, aunque superiores a la cifra que das seguro.

Según estoy entendiendo entonces tu mayor problema está más en como poder estructurar el odontograma en un esquema relacional.
Justamente el que consideres ver esto: PIEZA1.1 PIEZA1.2 PIEZA1.3 PIEZA1.4 PIEZA1.5 PIEZA2.1 en una tabla es un síntoma de que posiblemente se lo está viendo desde una perspectiva equivocada.

Para poder ayudarte debes comentarnos como tienes estructurada tu base de datos, no seas esquivo. Deberás darnos luz sobre tu diseño de otro modo trabajaremos con ciertos supuestos que vaya a saber si se pueden extrapolar a tu diseño sin mayores problemas. Bajemos a tierra, ¿Cómo lo tienes actualmente y a que quieres llegar? En función de eso se pueden plantear alternativas... pero como entenderás: sin conocer realmente en como lo estás llevando es muy difícil que podamos opinar ¿no crees? 

Saludos,

[mati_pincha]

Hola, si entiendo lo que decis y si tenes idea de como es una ficha odontologica habras entendido como diseñe mi tabla. Yo poseo una unica tabla con la informacion de cada paciente, la cual se compone por informacion personal y de las piezas(le asocio un numero a cada parte de la pieza, el cual va a estar en el ImageList y visualizara con una imagen el estado de la pieza) . El problema de manejar la informacion de cada pieza es que yo debo almacenar el estado de cada una de las 5 partes de cada pieza, se entiende? por lo que se me ocurrio hacer una Timage para cada una, los cuales se van a poder ir manipulando a traves del onMouseDown para modificar el estado de la pieza. Mi problema como te dije anteriormente es que una tabla de access me resulta chica en cuanto a campos para toda la info que necesito de cada paciente. La tabla es algo basico como lo que te estoy describiendo. Quiero que sepas que lo que menos trato de ser es esquivo jaja trato de darte toda la informacion necesaria para que puedas ayudarme, lo cual te agradezco. Si se me pasa algo es por no darme cuenta y espero que me lo comentes. Si tenes una mejor forma de administrar las piezas la escuchare con gusto.
              Gracias de nuevo por el tiempo, un saludo, Matias

[Delphius]

Hola mati_pincha, ¿Y porqué sigues sin brindar la estructura de tu tabla entonces? En realidad estás esquivando a la posibilidad de que en verdad se te pueda ayudar.
Me puedo, y me estoy, haciendo una idea de como posiblemente lo estés encarando... pero de allí a que me haga una idea de como en realidad está tu diseño (y en como/que tipos de datos y demás campos tiene tu tabla) puede haber ciertas diferencias.
Repito y sostengo: explica con detalles tu caso porque de una u otra forma estás dando a entender que tienes una falla en tu apreciación y en un muy pobre análisis del sistema y del proyecto en sí.

Para asesorarte debemos ver con detalles tu paso y poder comprender lo mejor posible tu perspectiva. Repito: Tienes un diseño inicial, que al parecer no te convence del todo, y tienes cierta perspectiva de como quisieras que debiera ser (y hacer) al final pero no logras llevarlo a cabo. El problema es que es TU visión y nosotros no contamos con los elementos suficientes para ayudarte.
Es decir concebiste una idea, te enfrentas a un resultado final estimado pero el que obtienes por el diseño inicial no concuerda del todo. Entonces surge el problema y una duda. Una duda y problema que está intentando forzar a ese diseño inicial (que por tu palabras parecieras reticente a cambiarlo aún si aparecieran indicios de que tienes un planteo y diseño débil y sugieran que así no es) a comportarse como algo que no puede.

Mi primer planteo es reestructurar TODA la base de datos. Así de plano. Porque algo me dice que una relación 1-1 entre el cliente y su planilla odontrograma no cuadra. O dime ¿Cómo acaso es que logras entonces llevar el histórico del trabajo que se va realizando al paciente? Si la relación la fuerzas a 1-1 lo que conseguirás es que exista solamente el estado final a la fecha del cliente y por tanto perderás la cronología de como se ha ido trabajando en cada diente (supongo que estás al tanto de que en ocasiones el trabajo sobre un/os diente/s no es algo que se hace en un día). Además es requisito legal que un Ortodoncista lleve un expediente o ficha clínica a modo histórico de como se fue la evolución.

Como segundo punto, de por si el odontrograma tiene un diseño complejo y no es tan elemental llevar a un esquema relacional. Cada "casillero" (o diente) tiene, como seguramente debes de saber, 5 cuadros. Hay 52 casilleros distribuídos horizontal y verticalmente, y si se quisiera llevar un odontrograma en una sola tabla esta tendrá la poca de 260 campos, 5 para cada casillero. Un potencial peligro para que se cometa un buen error de dedo y terminemos haciendo una consulta sobre un campo no deseado.

No terminando allí el asunto resulta además que cada cuadro puede tener varios estados, a lo largo del tiempo. En términos prácticos y de implementación diríamos que el valor que puede asumir este cuadro, en un instante de tiempo, será uno de una lista. Esto sugiere entonces ya, de plano, una hipotética relación (1:M) entre Cuadro y Estado.

El mejor enfoque es romper ese esquema y reemplazarlo por uno multitablas (ya se verá cuantas) que haga más fácil administrar "semejante información". Pero la solución que tu buscas, forzada a que "virtualmente" dos tablas vinculadas se comporten como una sola es un tanto rebuscada ni termina (al menos a mi) convenciendo de que en realidad solucione el verdadero problema aquí.

No te enfades por mis palabras pero es que si sigues con ese planteo, cerrado en una mono-tabla, lo veo difícil. El punto es que tu mismo te estás encerrando en tu diseño y no aceptas la posibilidad de que se le hiciera una sana crítica constructiva y sigues en la intención de que si o si sea una única gran tabla.
Me haces acordar a las pseudos bases de datos de Clarion de allá por los años 80-90 que era una sola cosa con todo seguido. Desde entonces, como dice el dicho... ya corrió mucha agua bajo el puente.
En serio, Ayúdanos a ayudarte.

Saludos,

[mati_pincha]

Hola, yo planteo ese diseño porque es lo que se me ocurrio a mi ya que no necesito manejar mas informacion que la de los pacientes. Estoy seguro que a vos se te ocurriria algo mejor y por eso estoy dispuesto a modificar lo que sea.
En cuanto a la tabla es como te dije, no tiene  ninguna ciencia y creo que es algo basico, a lo sumo que yo este pasando por alto algo de lo que llamas estructura, sino es solo lo que te dije. Además no necesito guardar las historias de los pacientes. Solo una ficha para cada uno la cual se va a ir sobreescribiendo con las nuevas practicas que hará el dentista sobre cada paciente, por eso lo de la relacion 1-1. Esto se hace asi porque es solo para que el dentista tenga un registro de lo elaborado con cada paciente, digamos que es aparte a la entrega que el mismo debe hacer sobre las prestaciones al paciente. Vuelvo a repetirte que hago todo para que me ayudes porque es lo que mas quiero jaja, te pasaria la tabla de access si podria pero no se puede y siento si no me expreso bien. Gracias de nuevo y espero que ese dato te sirva para resumirlo.
            Un saludo, Matias

[elarys]

nadie quiere tu archivo access, lo mas facil seria que dibujaras tu tabla o tablas con todos los campos, para que puedan o podamos ayudar

asi no se entiende (por lo menos yo)
NOMBRE  APELLIDO  DOMICILIO OBRA_SOCIAL PIEZA1.1 PIEZA1.2 PIEZA1.3 PIEZA1.4 PIEZA1.5 PIEZA2.1.

pero si orientas de esta forma en cuanto a tablas, puede que ayudes
NOMBRE
APELLIDO
DOMICILIO
OBRA_SOCIAL
PIEZA1.1
PIEZA1.2
PIEZA1.3
PIEZA1.4
PIEZA1.5
PIEZA2.1

deberias hacer la relacion de 1 a muchos como dice delphius, tener por un lado los datos personales y en otra tabla las piezas, se me ocurre

TABLA PACIENTE
Codigo_Paciente
NOMBRE
APELLIDO
DOMICILIO
OBRA_SOCIAL

TABLA PIEZAS
ide_pieza
nro_pieza
Codigo_Paciente
Lugar_donde_esta_esa_pieza

Es una vaga idea de lo que me diste a entender

[mati_pincha]

Hola, si en realidad mi tabla es como vos la pusiste solo que yo la indique en la vista de columnas y no como vos la detallaste pero es lo mismo, mi tabla tiene esa estructura. Y si es verdad ahora que pienso seria conveniente que utilice una relacion de uno a muchos por la cantidad de piezas que debo manejar. Hace bastante que no uso Delphi y la imaginación se me fue perdiendo jaja. Gracias por la ayuda. Un saludo