¿Está mal diseñada una base de datos con una tabla que tiene un solo registro?

[un_tio]

Por lo menos, queda un poco "feo", pero no veo otra solución para determinadas situaciones. Creo que está bien diseñado, pero a ver si me lo confirmáis.

Imaginad, por poner un ejemplo, el personal de una empresa, que al entrar pasa una tarjeta magnética. Y se queda grabado que ha entrado esa persona, por supuesto, pero aparte se quiere guardar el número total de personas en un momento dado en el edificio.

Es decir, no tener que hacer un cálculo cada vez que se quiera ver eso, sumando todas las que estén, sino un único campo, que se incrementará o decrementará de uno en uno, que nos diga "pues hay 250", o "550".

¿Cómo se haría eso, si no es con una tabla con un solo registro, y para más inri si no se le dota de más funcionalidad, con una sola columna?

[jurena]

Sí, pero no sabrás quiénes están en ese momento, es decir, quiénes son esos 250 o 550.

[gnzsoloyo]

Como dice jurena, lo único que sabrás es cuántos son, pero no quienes, por lo que el dato pasa a ser superfluo.
Un dato así no tiene ningún sentido que se guarde en una base de datos porque carece de significado. Para eso se usan habitualmente en las aplicaciones las variables globales, que tienen existencia mientas la aplicación corre.
Por otro lado, si lo piensas, si quieres saber cuantas personas hay en un momento dado en el edificio, lo único que debes hacer es solicitar a la base que te devuelva la lista de todas las personas que marcaron entrada pero no salida... o la suma total de ellas.
Una de las reglas de la normalización de tablas es nunca grabar aquella información que es calculable. El cálculo no afecta en este caso a la performance de la consulta, entonces ¿qué sentido tiene guardar esa info?

[un_tio]

Iniciado por gnzsoloyo

Como dice jurena, lo único que sabrás es cuántos son, pero no quienes, por lo que el dato pasa a ser superfluo.
Un dato así no tiene ningún sentido que se guarde en una base de datos porque carece de significado. Para eso se usan habitualmente en las aplicaciones las variables globales, que tienen existencia mientas la aplicación corre.
Por otro lado, si lo piensas, si quieres saber cuantas personas hay en un momento dado en el edificio, lo único que debes hacer es solicitar a la base que te devuelva la lista de todas las personas que marcaron entrada pero no salida... o la suma total de ellas.
Una de las reglas de la normalización de tablas es nunca grabar aquella información que es calculable. El cálculo no afecta en este caso a la performance de la consulta, entonces ¿qué sentido tiene guardar esa info?

Sí, claro, pero ya dije que se pretendía ganar eficiencia en el cálculo. Está claro que no sería una tabla normalizada, y yo tampoco creo que sea algo muy recomendable, o como poco, ortodoxo. El único objetivo sería ahorrar en cálculos para mayor rapidez (si no, volver a calcular todo, podría ser mucho tiempo, o forzarte a usar índices).

Lo de la variable tiene de malo que ya depende de la aplicación que uses, y te arriesgas a que se quede colgada.

¿Es demasiado malo usar algo así? ¿Es muy infrecuente, pero se usa?

[gnzsoloyo]

¿Es demasiado malo usar algo así? ¿Es muy infrecuente, pero se usa?

Es malo si la consultas en forma constante o habitual. Una sentencia consume recursos, por lo que una llamada a la tabla es una lectura a disco que necesariamente resulta en tiempo consumido.

El único objetivo sería ahorrar en cálculos para mayor rapidez (si no, volver a calcular todo, podría ser mucho tiempo, o forzarte a usar índices).

Los cálculos a que te refieres no se hacen en disco sino en memoria, y es mucho más rápido leer un índice que ya contiene las claves necesarias (como en la consulta que te propuse), que realizar otro tipo de lecturas secuenciales.
Mi sugerencia es no usar una tabla para guardar un sólo registro. Carece de funcionalidad. Cuando se usan tablas con pocos registros e incluso que no varían en el tiempo, estas tienen sentido en el contexto de determinadas consultas. Ese es el caso de las que guardan los cargos de una empresa codificados, por ejemplo.

Suele decirse en las cursadas de las asignaturas de bases de datos que crear tablas para guardar un dato sólo sólo significa perder recursos de Tablespaces, porque el problema debe poder resolverse de otro modo.

Finalmente: ¿Por qué necesita necesario saber cuánta gente hay en determinado momento en un edificio?
Si la cosa fuera por seguridad, la cantidad no es relevante, lo que es relevante es quiénes son y donde están.
Si es por razones operativas, lo que más importa es cuantas entran, cuándo entran, cuando salen y cuánto estuvieron allí.
¿En qué contexto puede ser necesario saber solamente cuántas están?

[un_tio]

Iniciado por gnzsoloyo

Es malo si la consultas en forma constante o habitual. Una sentencia consume recursos, por lo que una llamada a la tabla es una lectura a disco que necesariamente resulta en tiempo consumido.

Hombre, lo veo justo al revés, se hace esa tabla "cutre" precisamente si se va a consultar muchas veces, por ahorrar tiempo y recursos.

Iniciado por gnzsoloyo

Los cálculos a que te refieres no se hacen en disco sino en memoria, y es mucho más rápido leer un índice que ya contiene las claves necesarias (como en la consulta que te propuse), que realizar otro tipo de lecturas secuenciales.

Pero la lectura de la única tabla, igualmente sería siempre más rápida a la tabla general para a partir de ella hacer los cálculos.

Iniciado por gnzsoloyo

Finalmente: ¿Por qué necesita necesario saber cuánta gente hay en determinado momento en un edificio?
Si la cosa fuera por seguridad, la cantidad no es relevante, lo que es relevante es quiénes son y donde están.
Si es por razones operativas, lo que más importa es cuantas entran, cuándo entran, cuando salen y cuánto estuvieron allí.
¿En qué contexto puede ser necesario saber solamente cuántas están?

Hombre, es sólo un ejemplo. Pero piensa que puede necesitarse únicamente esa información, para saber el número de plazas libres que quedan en el párking.

Que ya, que como "parece pequeña", igual ya puestos la haríamos de otra forma para dotarle de más funcionalidad, como indicando los que han entrado y salido y las horas, como has dicho, pero eso, ¿no sería darle una funcionalidad adicional a la inicial, que era simplemente el grado de ocupación? Y sobre todo, ¿no podría ser que una consulta a la tabla inicial consumiera tanto tiempo que lo desaconsejara?

En fin, yo sigo sin ver clara la creación de esa tabla. Si bien estoy contigo en que "parece" que no aporta mucha funcionalidad, y puede calcularse a partir de otras tablas, sigo pensando que tal vez en determinados casos de muchos datos podría justificarse para ahorrar tiempos de consulta y actualización (lo malo, es que en efecto no estaría normalizada, y podrían darse inconsistencias).

¿Qué harías (es una hipótesis) si la tabla de empleados, o cualquier cosa a contar, tuviera 10 millones de registros o una cantidad que provocara un retardo apreciable?

[gnzsoloyo]

Hombre, lo veo justo al revés, se hace esa tabla "cutre" precisamente si se va a consultar muchas veces, por ahorrar tiempo y recursos.

Por cosas del funcionamiento del hardware y el sistema operativo, en realidad leer 10.000 registros y leer un sólo registro usan en la mayoría de los casos la misma cantidad de tiempo. Es más el tiempo que necesita para cambiar de procesos, acceder al disco y desplazar el cabezal de lectoescritura, que lo que le lleva leer un bloque de datos. En ese sentido, lara el sistema, leer uno o 10000 no importa.
Además piensa esto: Un motor de base de datos no lee un registro. Lee un bloque de datos que ocupa 64 Kb, a donde pone los registros leídos; si el registro en cuestión usa 4 bytes (BIGINT), esto quiere decir que como mínimo realizará una lectura que ocupará 16.000 registros de una sola vez... aunque solamente esté leyendo uno. En ese sentido no le ahorras al sistema ni tiempo ni espacio.
El cruce de datos de dos tablas que contengan 500 registros de 4 bytes usa tres bloques de datos. Nada más. En ese contexto, hacer una relación entre dos tablas que contengan entradas y salidas de un parking de 1.000 plazas, o bien de un edificio de oficinas de 12.000 empleados, ocupan el mismo espacio a nivel de bloques de datos y a nivel de procesos, por lo que en realidad se trata de tiempos despreciables. Son tan pequeños que el parser no pierde el tiempo en optimizarlos porque le llevaría más recursos.

En el caso del uso de los índices, aclaremos: Cuando MySQL se encuentras que la información está en los índices, ni mira las tablas, por lo que a veces las consultas resultan mucho más rápidas de lo esperado, por más largas que sean las tablas.
En este punto depende del tipo de índices. Los índices BTree son inmensamente rápidos porque se recorren con extrema rapidez, y los Hash trabajan casi como con la ALU de los microporcesadores, por lo cual también son muy rápidos.. Piensa, además, que los índices son más pequeños que las tablas, por lo que en un bloque de datos de 64 Kb entran más punteros de índice que registros en la tabla en el mismo espacio.

igual ya puestos la haríamos de otra forma para dotarle de más funcionalidad, como indicando los que han entrado y salido y las horas, como has dicho, pero eso, ¿no sería darle una funcionalidad adicional a la inicial, que era simplemente el grado de ocupación? Y sobre todo, ¿no podría ser que una consulta a la tabla inicial consumiera tanto tiempo que lo desaconsejara?

No necesariamente. Cuando analizas el problema a nivel de consultas los factores de optimización implicados pueden ser muchos, y en muchos de esos casos no se está leyendo la tabla completa. Por dar un ejemplo: Buscar un registro en 10.000.000 puede requerir menos de 25 lecturas de índice, o incluso la lectura de un sólo bloque de datos.

A nivel de procesos de BB.DD. las cosas no son sumatorias de 1+1...