¿Es recomendable una tabla con 1000 columnas?

[tito87]

Hola a todos.

Estoy haciendo una aplicación web, para la toma de una serie de valores al hacer una ronda de pantallas.
La aplicación va mostrando pantallas (unas 80) en cada pantalla hay una serie de campos en los que hay que escribir o bien botones que pulsar, en total tengo como unos 1000 campos (botones, selectores, inputs de texto). Al acabar la ronda tengo que guardar en un BD el valor/estado de todos esos campos para después poder consultarlos.
Todavía no he pensado en como guardar esos datos en una tabla final de resultados pero había pensado en usar una sola con (más o menos) 1000 columnas.
Cada día la ronda se hace tres veces por tanto la tabla crecería en 3 filas cada día.
Es esto viable??
Se os ocurre como puedo estructurar mejor los resultados??
Sería conveniente separar por pantallas y hacer una tabla para cada pantalla???

Un saludo y gracias.

[gnzsoloyo]

¿1.000 columnas?
Salvo que quieras tener pesadillas, me parece desde el vamos algo insensato.
El hecho de que tengas 1000 objetos en las diferentes pantallas no significa que esos 1000 objetos sean datos a almacenar, eso es un error conceptual gravísimo. Podrían ser muchos menos o muchos más, no lo podemos saber sin conocer el sistema.
Pero desde el vamos, por experiencia, el tema es que no tienes definido ni siquiera el DER lógico, por lo que ni siquiera se puede empezar a hablar de tablas.

Sería mucho mejor que hicieras al menos un esquema básico de entidades y relaciones, porque me resulta difícil creer que tengas una entidad con 1000 atributos.

[tito87]

A ver, os cuento:
Mi aplicación se usará para la adquisición de datos a la hora de hacer la ronda de pantallas en una sala de control de una central electrica.
El sistema de control está dividido en pantallas (comunes-caldera1,comunes-caldera2, caldera-aguadealimentacion-motoraltapresion, caldera-aguadealimentacion-motorbajapresion...) En total tengo unas 85 pantallas, dentro de cada una de las pantallas hay que tomar valores, por ejemplo temperatura agua, temperatura motor, nivel aceite ... y comprobar si hay alarmas activas o no(representadas por botones). Y esto multipiplicado por 2 ya que hay dos "fábricas" iguales.
Bien, para cargar todos los valores a tomar en cada pantalla uso una tabla en la que tengo definidos todos los "textinputs" "buttons" "select". Esta tabla tendrá un total de unas 1000 filas.
Una vez acabada la ronda de pantallas se supone que se han tomado estos 1000 valores, es cierto que todos los botones que representan alarmas, si no están activas no hace falta guardarlos, pero esto nos puede reducir a unos 600 valores más o menos.
Yo necesito guardar estos 600 valores para poder consultarlos después 3 veces al día 7 días a la semana multiplicado por 2 "fabricas".

He pensado que puedo hacer una tabla por cada pantalla y guardar ahí los valores tomados. Esto implicaría tener 85 tablas, y cada tabla crecería al orden de 90 filas al día.

Esto supondría una base de datos mostruosa verdad???

Espero haberme explicado.

Gracias

[gnzsoloyo]

Sigues in entender el problema, o al menos eso parece.
Partamos de una base: ¿Qué entiendes del modelo entidad-relación? ¿Cuánto sabes de sistemas de bases de datos relacionales?
¿Cuál es tu experiencia en análisis de sistemas?

La descripción que das no sirve para nada desde el punto de vista de la arquitectura de datos. No aporta información relevante para una aproximación al modelo de datos, porque necesitaríamos una descripcion global del sistema, a que se refiere y de algún modo lo que se denomina "requerimientos del negocio", es decir las reglas que nos permitan inferir el esquema de entidades.
Las pantallas son temas de proceso, no de datos. La arquitectura de datos responde al sistema subyacente, y no a meras pantallas, que son la interfaz del usuario, pero no son el sistema.
Lo que describes de una central eléctrica, no alcanza para ver el modelo de sistema de la misma, pero por lo pronto, estás entremezclando componentes base (las calderas, por ejemplo), con sus mediciones o datos a través del tiempo, que son conceptos distintos desde el punto de vista del modelo de datos.
Que haya 85 pantallas o 200 no nos aporta nada, si no sabemos qué información conceptualmente hablando se muestra en cada una de ellas.
Todas esas 85 pantallas bien podrían ser tablas independientes, y muy probablemente lo sean, si lo consideramos desde el momento en que cada una de ellas represente un tema, o imagen de un segmento del funcionamiento de la central.

En síntesis, sigues encarando mal todo, porque no estás viendo ni analizando el sistema desde una perspectiva lo suficientemente global como para construir una base de datos eficiente.
Y no, una única tabla no va a ser eficiente para manejar un ingente conjunto de datos que pui probablemente correspondan a entidades independientes entre si..

[tito87]

Mi experiencia en análisis de sistemas o con bases de datos es nula.
Esto es proyecto personal y no profesional y hasta ahora lo máximo que había hecho eran páginas web con usuarios y poco más.

Seguro que mi enfoque es erroneo pues no me han enseñado a hacerlo de otro modo, pero como lo he enfocado de manera global es:
Tengo que guardar X datos tres veces al día en una Base de Datos.
Y me surge la duda de si serán muchas entradas en la base de datos o no y de si esta la podré hacer ágil o se convertirá en algo explosivo.

El hecho de que los datos a nivel simbólico sean del mismo tipo (temperaturas, presiones, intensidades de corriente...) no se si lo debería tener en cuenta para hacer lo que quiero.

Ya se que las pantallas es interface de usuario, lo que quería es que entendieras lo que trataba de explicar. Lo he enfocado como si cada pantalla fuera un formulario por así decirlo.

No tengo experiencia para enfocar el proyecto de otro modo pero me gustaría llegar a hacerlo.

Gracias por tu ayuda

Edit: Intentando entender las Entidades relacionadas he llegado a la conclusión de que mi aplicación solo tiene dos. Usuario - Introduce - Datos. Y estos datos se guardan en la base de datos.

[kobety]

mira, yo me haría tantas tablas como páginas tenga..... y en cada tabla (a cada consulta de esas 3 diarias le voy asignando un id único que vaya incrementado) y en cada tabla guardo los valores de cada página y y el id al que pertenece, así luego podrías buscando la fecha de consulta y el id que se le ha asignado todos los resultados ;)

[gnzsoloyo]

mira, yo me haría tantas tablas como páginas tenga.

Eso tampoco es correcto, porque una "pantalla" o vista puede estar conteniendo datos de más de una tabla, y debes además considerar las relaciones entre tablas...
Lo de los ID es irrelevante. Dependerán del diseño de relaciones y las PK que se puedan identificar, porque no es obligatorio que sean numericos, sino que identifiquen univocamente a cada registro, y que no sean NULL.

Intentando entender las Entidades relacionadas he llegado a la conclusión de que mi aplicación solo tiene dos. Usuario - Introduce - Datos. Y estos datos se guardan en la base de datos.

Total y absoluto error. Sólo en la breve descrición que diste, yo ya he identificado siete.
No confundas acciones de la aplicación con entidades. No son la misma cosa.

Francamente, necesitas ayuda de alguien que conozca sobre BBDD. Te recomiendo buscar en el foro de búsqueda de colaboradores alguien que pueda asistirte: http://www.forosdelweb.com/f143/

[kobety]

A ver supongo que en cada página tendrá elementos de "tablas" diferentes, si no sería ir guardando los valores que sean de cada "tabla" mediante post (si se hace en php) y de que los tengas todos almacenarlos en una tupla . Perdón si no me he expresado correctamente pero esa era la idea :P

[tito87]

Eso tampoco es correcto, porque una "pantalla" o vista puede estar conteniendo datos de más de una tabla, y debes además considerar las relaciones entre tablas...

Todas las vistas obtienen los campos de una sola tabla llamada inputs. En esta tabla se definen el tipo de input, el tamaño, la posición etc... Esta tabla podrá crecer en el futuro si por ejemplo se añaden más "pantallas" con más campos a ingresar.

El problema es como guardo todos esos datos ingresados por el usuario, si en una sola tabla, en tantas como páginas etc..

Probablemente no me sepa explicar bien, y por eso creo que no estás entendiendo lo que quiero que haga mi programa.

Total y absoluto error. Sólo en la breve descrición que diste, yo ya he identificado siete.
No confundas acciones de la aplicación con entidades. No son la misma cosa.

Si me pudieras decir cuales son para hacerme una idea... Seguiré leyendo a ver si consigo hacer un DER correctamente.

A ver supongo que en cada página tendrá elementos de "tablas" diferentes, si no sería ir guardando los valores que sean de cada "tabla" mediante post (si se hace en php) y de que los tengas todos almacenarlos en una tupla .

Supongo que esta es la opción más fácil. Crear una tabla llamada result-identificadorpantalla para cada pantalla donde almacenar el valor de los campos de cada pantalla.

gracias

[guardarmicorreo]

a riesgo de complicar más las cosas y ponérselo más difícil a gnzsoloyo, voy a intentar expresar de otra manera lo que gnzsoloyo quiere decir.

teoría

en una base de datos se guardan datos, estos no dependen de qué interfaz tenga el usuario.

una base de datos en un sistema es la memoria del sistema.

yo veo las bases de datos como una ciencia y en el momento en que hay que diseñar una base de datos para un sistema estamos hablando de un trabajo interdisciplinar.

en tu caso tito87, la base de datos va a recoger una serie de datos que si bien van a venir por separado, pueden estar aglutinados en tablas o base de datos según el sistema.

pero sobre todo para qué lo quieres, si es para tener un registro histórico o solamente un control de problemas diarios.
si los datos van a ser accesibles internamente en red local o también por internet (seguridad), etc.
¿estás seguro que el tipo de base de datos es el adecuado para el ambiente en el que va a funcionar la BD?
entre otras preguntas

practica

para llevar a la práctica todo lo anterior hay que navegar hasta el detalle partiendo de lo genérico

tienes dos centrales térmicas, ok.

en estas dos centrales térmicas ¿son las dos del mismo tipo o son distintas?

¿en cada una de ellas hay núcleos o mejor dicho unidades operativas que arrojen mismo tipo de datos? ¿o cada unidad arroja distintos tipos de datos?

con unidad operativa me refiero a si hay espacios, salas, habitaciones, con una bomba, un termómetro, un manómetro, etc. ¿o cada sala, espacio, habitación es distinta de las anteriores? ¿o las unidades resulta que no son físicas sino meramente funcionales?

si no hay unidades, ¿cuantas entidades distintas, unas de otras, hay?

es decir, ¿en cada central hay una bomba que funciona distinto y con distinta finalidad? ¿o son iguales?

en cada central ¿hay un termómetro y manómetro con funciones distintas y funcionamiento distinto? ¿o son iguales?

luego está el asunto de qué datos arrojan todas estas unidades o cada entidad.

¿devuelven números? si es que sí ¿de qué tipo?

¿o solo devuelven true o false? ¿o devuelven string?

eso es entender cómo funciona el sistema y ahora hay que adaptar la base de datos al sistema:

si en las dos centrales todo se puede abarcar por unidades operativas y además tienen las mismas y la misma cantidad entonces ¿una base de datos o dos bases de datos? ¿tablas A_bomba01, A_bomca02, etc y B_bomba01, B_bomba02, etc.?

¿qué relación hay entre unidades operativas o entre componetes de cada unidad operativo o incluso entre unidades?

si no hay ni una sola unidad operativa, entonces no hay un solo componente del sistema que se repita en cuanto a propósito, dato que reporta y ubicación.

por lo tanto ¿una tabla para cada entidad? ¿cómo y para qué se relaciona con otras entidades del sistema?







espero haber podido ayudar en algo. por lo menos lo intenté :D

saludos!

He EDITADO para cambiar la palabra núcleo por unidad para que se entienda mejor el concepto.

[tito87]

El problema obviamente es de planteamiento desde un inicio.

La central (sond 2 Unidades Iguales) se controla por pantallas, mediante un HMI (Human Machine Interface).
Hasta ahora la ronda de pantallas se hacía mediante un excel, hay que ir pantalla por pantalla e ir anotando en un excel los valores que sean requeridos. En este momento, con el excel, da igual si lo que estás mirando es una temperatura, una presión, una alarma etc... todo se apunta de la misma manera.

Partiendo de esto yo "ideé" la interface de mi aplicación con capturas de pantalla del HMI y en los huecos donde hay que tomar datos coloco un campo, de texto, un botón, un select... Pero, como yo lo he planteado, me da igual que sea una temperatura, una presión, una intensidad de corriente...

Al final lo que quiero es que esos datos queden guardados en un bd con fecha para depsués hacer en la aplicación una sección de consulta, en el que metas el nombre del valor (cada valor lleva un nombre único) y te salga una gráfica con los valores desde las fechas que le pongas.

El problema me surgió al ir diseñando la parte gráfica, es decir todos los campos a rellenar, que me salieron muchos, pongamos 600. Esto multiplicado por 3 veces al día, multiplicado por 2 unidades me generan unos 3600 valores que tengo que guardar en la BD al día. Y aquí es donde me "asusté" pensando en como guardar tantos datos de la manera más ordenada posible.

Igual estoy siendo pesado en explicaros mi idea de aplicación, pero no sé hacerlo de otro modo y quería saber si así es una locura o si realmente necesito hacer un análisis tan exhaustivo de la aplicación.

Gracias.

[gnzsoloyo]

El problema de la metodología de toma de datos que refieres, es que para nosotros, como desarrolladores de BBDD, no "da igual", qué es lo que sea, de donde se origina, y qué información es la que refiere cada dato.
Para nosotros diferenciar cada entidad (real o conceptual) es fundamental a la hora de realizar las consultas, reportes consolidaciones, etc.
Si no podemos crear un modelo del sistema, no podemos crear la base de datos. Por eso necesitamos entender el sistema y describirlo en un modelo de datos coherente.
La información que das es insuficiente para eso.

[guardarmicorreo]

Iniciado por tito87

El problema obviamente es de planteamiento desde un inicio.

La central (sond 2 Unidades Iguales) se controla por pantallas, mediante un HMI (Human Machine Interface).
Hasta ahora la ronda de pantallas se hacía mediante un excel, hay que ir pantalla por pantalla e ir anotando en un excel los valores que sean requeridos. En este momento, con el excel, da igual si lo que estás mirando es una temperatura, una presión, una alarma etc... todo se apunta de la misma manera.

Partiendo de esto yo "ideé" la interface de mi aplicación con capturas de pantalla del HMI y en los huecos donde hay que tomar datos coloco un campo, de texto, un botón, un select... Pero, como yo lo he planteado, me da igual que sea una temperatura, una presión, una intensidad de corriente...

Al final lo que quiero es que esos datos queden guardados en un bd con fecha para depsués hacer en la aplicación una sección de consulta, en el que metas el nombre del valor (cada valor lleva un nombre único) y te salga una gráfica con los valores desde las fechas que le pongas.

El problema me surgió al ir diseñando la parte gráfica, es decir todos los campos a rellenar, que me salieron muchos, pongamos 600. Esto multiplicado por 3 veces al día, multiplicado por 2 unidades me generan unos 3600 valores que tengo que guardar en la BD al día. Y aquí es donde me "asusté" pensando en como guardar tantos datos de la manera más ordenada posible.

Igual estoy siendo pesado en explicaros mi idea de aplicación, pero no sé hacerlo de otro modo y quería saber si así es una locura o si realmente necesito hacer un análisis tan exhaustivo de la aplicación.

Gracias.

craso error respecto a lo que tienes en negrita.

da igual lo que quieras generar (tipos de gráficas, tablas, cuestionarios, etc.), lo que importa es la manera correcta de organizar los datos para que tanto de manera independiente como de manera grupal los datos sean accesibles.

imagínate una única tabla excel con 1000 columnas.

imagínate que la columna 1 guarda las fechas, la columan 2 guarda la hora, la columna 78 guarda una determinada temperatura, la columna 400 una presión y la 974 guarda una alarma.

solo para llegar hasta la columna 974 ¿cuanto tardarías?

imagínate que quieres imprimir solo las columnas fecha, hora y presión, tendrías que recorrer cada fila desde la 1 luego la 2 y después hasta la 400 en una sola tabla con miles y miles y miles de datos generados en solo una semana.

lo mismo para obtener una búsqueda de alarmas generadas, etc.

ahora viene el jefe, y te dice que por una nueva ley de transparencia esos datos tienen que publicarse en una web oficial y que le prepares las consultas al programador web.

dichas consultas deben estar separadas por áreas operativas y dentro de cada área tienes que generar valores para cada componente que hay en ese área para generar una visual animada para una sección didáctica de la web. te vería sudando horrores por no haber separado correctamente y lógicamente los datos unos de otros.

harías consultas lentas, no tendrías registros en la base de datos separados con una lógica enfocada a entender la base de datos y tampoco a futuros proyectos.

tendrías que comenzar de nuevo o tendrías que trabajar sobre esa tabla para separar los datos, lo cual implica más pérdida de tiempo o tendrías que explicar que esos datos ya no estarían disponibles en los futuros proyectos que te propongan.

[tito87]

craso error respecto a lo que tienes en negrita.

da igual lo que quieras generar (tipos de gráficas, tablas, cuestionarios, etc.), lo que importa es la manera correcta de organizar los datos para que tanto de manera independiente como de manera grupal los datos sean accesibles.

imagínate una única tabla excel con 1000 columnas.

imagínate que la columna 1 guarda las fechas, la columan 2 guarda la hora, la columna 78 guarda una determinada temperatura, la columna 400 una presión y la 974 guarda una alarma.

solo para llegar hasta la columna 974 ¿cuanto tardarías?

imagínate que quieres imprimir solo las columnas fecha, hora y presión, tendrías que recorrer cada fila desde la 1 luego la 2 y después hasta la 400 en una sola tabla con miles y miles y miles de datos generados en solo una semana.

lo mismo para obtener una búsqueda de alarmas generadas, etc.

ahora viene el jefe, y te dice que por una nueva ley de transparencia esos datos tienen que publicarse en una web oficial y que le prepares las consultas al programador web.

dichas consultas deben estar separadas por áreas operativas y dentro de cada área tienes que generar valores para cada componente que hay en ese área para generar una visual animada para una sección didáctica de la web. te vería sudando horrores por no haber separado correctamente y lógicamente los datos unos de otros.

harías consultas lentas, no tendrías registros en la base de datos separados con una lógica enfocada a entender la base de datos y tampoco a futuros proyectos.

tendrías que comenzar de nuevo o tendrías que trabajar sobre esa tabla para separar los datos, lo cual implica más pérdida de tiempo o tendrías que explicar que esos datos ya no estarían disponibles en los futuros proyectos que te propongan.

No es que yo quiera hacer una tabla con 1000 columnas obviamente es una locura y una burrada.

Siguiendo el consejo del otro compañero había pensado en crear tantas tablas como "secciones/pantallas" tengo y dentro de estas tablas guardar los datos correspondientes a ellas. Así la tabla solo tendría 5 columnas (idresult, relatedInputId, inputValue, date, unit), cada vez que se hiciera la ronda esa tabla almacenaría tantas filas como datos hubiera que coger en esa pantalla (entre 1 y 10 más o menos).

Creo que de este modo las consultas sería mucho más rápidas aunque cada tabla tuviera unas 36 entradas diarias.

No se si me he explicado ejejeje.

Gracias.

[guardarmicorreo]

Iniciado por tito87

No es que yo quiera hacer una tabla con 1000 columnas obviamente es una locura y una burrada.

Siguiendo el consejo del otro compañero había pensado en crear tantas tablas como "secciones/pantallas" tengo y dentro de estas tablas guardar los datos correspondientes a ellas. Así la tabla solo tendría 5 columnas (idresult, relatedInputId, inputValue, date, unit), cada vez que se hiciera la ronda esa tabla almacenaría tantas filas como datos hubiera que coger en esa pantalla (entre 1 y 10 más o menos).

Creo que de este modo las consultas sería mucho más rápidas aunque cada tabla tuviera unas 36 entradas diarias.

No se si me he explicado ejejeje.

Gracias.

anteriormente dijistes

Al final lo que quiero es que esos datos queden guardados en un bd con fecha para depsués hacer en la aplicación una sección de consulta, en el que metas el nombre del valor (cada valor lleva un nombre único) y te salga una gráfica con los valores desde las fechas que le pongas.

aquí ya tienes dos contradicciones bien claras:

si vas a hacer una gráfica con un solo valor en una fecha determinada, vas a repetir datos, puesto que todos los valores van a tener una fecha en que han sido grabados en la bd.

vas a repetir 80 veces la misma fecha tres veces al día, día tras día por cada pantalla. eso en tu base de datos va a ser terriblemente costoso en cuanto a memoria.

otra contradicción es que si quieres hacer una gráfica de un solo valor, pues ok.

pero si quieres hacer una gráfica comparativa con otros valores similares de otras pantallas

¿vas a hacer 80 consultas (una por pantalla) hasta obtener todos los datos que quieres de imaginemos un mes completo? ya no solo son 80 consultas, sino buscar en cada tabla los valores que quieres de un mes determinado.

yo te lo intenté explicar, gnzsoloyo también, pero sigues sin intender que las bases de datos son para guardar datos, es como una biblioteca, donde hay referencias por las que buscar, hay secciones y hay normas.

lo que quieres hacer en tu caso es organizar la biblioteca según unas pantallas.

quieres poner filas de libros detrás de cada pantalla y que el lector escoja los libros según la pantalla, si el lector quiere navegar entre pantallas tendrá que moverse 80 veces.

¿qué tal si aglutinas los datos según sean de un tipo u otro para que el lector haga los menos posibles viajes dentro de la biblioteca?

no entiendes lo que te queremos decir porque no sabes de modelos relacionales en las bases de datos.

cuando leas lo suficiente sobre esto veras que lo que estás planteando es un error y otro error y más errores y no pararán de surgirte errores porque el diseño que planteastes dependía de 80 pantallas, es algo variable, los datos almacenados son insertados y pensados para que tengan una persistencia de datos óptima.

creo que te falta mucho que leer sobre el modelo relacional para entender que distas mucho de la solución.

si sigues con dudas el siguiente paso es darte enlaces a vídeos youtube donde te explican bases de datos, cómo diseñarlas y además yo te pondría dibujos para que entiendas el concepto. solo si sigues interesado.

saludos! :)

[tito87]

cuando leas lo suficiente sobre esto veras que lo que estás planteando es un error y otro error y más errores y no pararán de surgirte errores porque el diseño que planteastes dependía de 80 pantallas, es algo variable, los datos almacenados son insertados y pensados para que tengan una persistencia de datos óptima.

creo que te falta mucho que leer sobre el modelo relacional para entender que distas mucho de la solución.

si sigues con dudas el siguiente paso es darte enlaces a vídeos youtube donde te explican bases de datos, cómo diseñarlas y además yo te pondría dibujos para que entiendas el concepto. solo si sigues interesado.

saludos! :)

comenzaré a ello ahora mismo.

Agradeceré toda la info útil que me puedas proporcionar y tu ayuda por supuesto.

No voy a poder pagar nada ya que esto es un proyecto personal dentro de la empresa pero sin remuneración (es a parte de mi trabajo diario).

Muchas gracias por la ayuda.

[guardarmicorreo]

Iniciado por tito87

comenzaré a ello ahora mismo.

Agradeceré toda la info útil que me puedas proporcionar y tu ayuda por supuesto.

No voy a poder pagar nada ya que esto es un proyecto personal dentro de la empresa pero sin remuneración (es a parte de mi trabajo diario).

Muchas gracias por la ayuda.

y para eso es este foro no? ayuda gratuita a otros colegas :D

siempre pienso que un vídeo es más ilustrativo que un libro, así que te dejo el canal youtube de luis marion sobre bases de datos y sql, en él encontrarás todo lo fundamental sobre bases de datos y el modelo relacional.

http://www.youtube.com/playlist?list=PLF7CE6A3246EF3889

que tienes dudas? preguntalas

[tito87]

Hola,

he estado mirandome los videos que me recomendaste. La verdad es que están muy bien y son muy ilustrativos. Hay muchas cosas que ya sabía pero muchas otras que no.

Creo que en cuanto a tablas relacionales tengo muchas cosas claras pero mi gran problema es hacer un DER bueno y representativo de mi problema.

Voy a intentar describir mi problema:

Tengo una Planta de generación, en ella tenemos dos unidades iguales (U1 y U2) y unos elementos comunes a ambas unidades. En las pantallas de sala de control cada unidad está dividida en pantallas o secciones y en estas pantallas se representa información de temperaturas, caudales, niveles, presiones, posición, desplazamientos... de bombas, tanques, tuberías, válvulas... Por ejemplo hay una sección que es Turbina de Gas - Control - Main, en ella hay una representación de la turbina de gas, con una serie de válvulas y tuberías, se pueden ver datos referentes a presiones, temperaturas, posicionamiento de válvulas así como información del estado de la turbina (si está en marcha o parada, modo de funcionamiento... ).
El programa tiene que ser capaz de almacenar información de las dos Unidades y de los elementos comunes en función del estado de las unidades, que pueden ser tres: parada, en marcha o con sellos y vacío.
También tiene que ser capaz de representar estos valores en una gráfica en función de la fecha de introducción.

Con este tocho necesito sacar mi diagrama de entidad-relación y es aquí donde me atasco sobremanera. Supongo que es la parte más dificil de cualquier proyecto y es normal pero necesito asesoramiento. No se si considerar entidad a cada elemento que aparece en esas secciones o bien considerar como entidad el dato de temperatura o de presión etc. No se si cada bomba diferente o cada tante, o cada válvula o cada tubería representan entidades diferentes o algunas de ellas se pueden agrupar.

Voy a intentar hacer una primera aproximación a un DER. cuando lo tenga lo subo.

Muchas gracias

[guardarmicorreo]

me voy a la playa unos días, agosto y españa ya sabes :D

pero he visto tu mensaje y cuenta conmigo para ayudarte en el proyecto. está muy interesante lo que haces y ayudarte en el der va a ser muy entretenido.

evidentemente para diseñar bien una base de datos hace falta entender el sistema para lo que se va a diseñar.

toma cada elemento del sistema que genera un valor que vas a guardar como una entidad particular y única, esto no significa que para cada elemento debas crear una tabla. ojo con eso eh.

hasta ahí bien.

qué es lo siguiente?

qué elementos comunes a todos los datos vas a tener en la base de datos?

en tu caso son elementos temporales y de ubicación.

todos los elementos generarán unos valores cada x tiempo y cada uno de ellos desde una ubicación distinta.

por lo que, qué tal si comienzas a repartir la base de datos de la siguiente manera (todavía sobre papel eh):

una tabla para las fechas y horas:

id_fech_hor(primaria)|date_time (tipo datetime)

una tabla para cada tipo de sistema cada una con una clave foránea unida a la id primaria de fecha y hora:

id_sistema(primaria)|circ_agua|energia|ventilacion |...|id_fech_hor(foránea)

esto continuaría con más tablas, pero no me puedo detener mucho más a expresar la idea que tengo al respecto, volveré el sábado y lo continuamos hablando, te dejo mi mail por mensaje para que me contactes desde el sábado. me temo que ya si infringimos las normas del foro al hacer el tema un diálogo de dos.

hasta entonces, un saludo! :D

[quimfv]

He leido todo lo que habeis dicho y yo veo lo siguiente

TblUnidades
idU
...Campos para los datos generales de la unidad...

TblElementos
idE
idTpE FK a TblTpElementos
idU FK a TblUnidades
...campos comunes a todos los elementos (posición ???...)...

TblTpElementos
idTpE
...Campos que describen al tipo de elemento (nombre, tamaño...??)

TblLecturas
idL
idE FK a TblElementos
idTpL FK a TblTpLecturas
fechaHora (datetime) (No debe ser único podría haber distintas lecturas que se toman al mismo tiempo)
valor
...Quizas no hacen falta mas campos....

TblTpLecturas
idTpL
unidades
...otros campos...

TblRTpElementoTpLecturas
idR
idTpE FK
idTpL FK
... otros (frecuencia?)...

(Con esta tabla consigues obtener los objetos de formulario que se deben mostrar en la pantalla de un elemento)


Tbl---Tabla
Tp---Tipo de
TblR --- Tabla de relación


Con esta estructura es muy posible que puedas representar tu sistema... sin, seguramente, agregar muchos campos en las entradas con suspensivos de cada tabla. Seguro que no necesitas agregar 1000 campos.

Con esto tendras muchos registros en las tablas Elementos y Lecturas pero pocos campos....

Código MySQL:

SELECT fechahora,
             valor 
FROM TblLecturas 
WHERE idTpL=X 
     AND idE=Y 
     AND YEAR(fechahora)=2013 
     AND MONTH(fechahora)=1;
 

Esta sencilla consulta te da los datos del grafico de enero del 2013 para la lectura X del elemento Y.

Código MySQL:

SELECT L.fechahora,
             L.idE,
             L.valor 
FROM TblLecturas L
     INNER JOIN TblElementos E
          ON L.idE=E.idE
WHERE L.idTpL=X 
     AND E.idTpE=Y 
     AND YEAR(L.fechahora)=2013 
     AND MONTH(L.fechahora)=1;
 

Esta los del grafico de todos los elementos de tipo Y, pera el mismo tipo de lectura y periodo.

Se puede complicar con join para obtener la unidad y los datos del elemento pero para el grafico es suficiente.

Ojo no es el esquema ER (Entidad/Relación) son las tablas físicas. (Sabes que no toda Entidad se convierte en tabla fisica ni a la inversa) Obviamente se puede complicar pero para eso debería conocer mas el caso.

[tito87]

Muchas gracias a los dos.
Mañana tengo una reunión con mi jefe y seguramente cambiemos cosas de la aplicación que igual hacen que sea menos compleja y ya me pondré a seguir vuestros consejos.
Según vayan saliendo más dudas os comento.

Gracias.