spreadsheets - numeros a letras google sheets
Base de datos: la mejor forma de modelar una hoja de cálculo (4)
Estoy tratando de encontrar la mejor manera de modelar una hoja de cálculo (desde el punto de vista de la base de datos), teniendo en cuenta:
- La hoja de cálculo puede contener un número variable de filas.
- La hoja de cálculo puede contener una cantidad variable de columnas.
- Cada columna puede contener un solo valor, pero su tipo es desconocido (entero, fecha, cadena).
- Tiene que ser fácil (y eficaz) generar un archivo CSV que contenga los datos.
Estoy pensando en algo como:
class Cell(models.Model):
column = models.ForeignKey(Column)
row_number = models.IntegerField()
value = models.CharField(max_length=100)
class Column(models.Model):
spreadsheet = models.ForeignKey(Spreadsheet)
name = models.CharField(max_length=100)
type = models.CharField(max_length=100)
class Spreadsheet(models.Model):
name = models.CharField(max_length=100)
creation_date = models.DateField()
¿Puedes pensar en una mejor manera de modelar una hoja de cálculo? Mi enfoque permite almacenar los datos como una cadena. Me preocupa que sea demasiado lento generar el archivo CSV.
Es posible que desee estudiar los modelos de datos EAV (Entity-attribute-value), ya que están tratando de resolver un problema similar.
La mejor solución depende en gran medida de la forma en que se utilizará la base de datos. Intenta encontrar algunos de los casos de uso más importantes que esperas y luego decide el diseño. Por ejemplo, si no hay un caso de uso para obtener el valor de una determinada celda de la base de datos (los datos siempre se cargan en el nivel de fila, o incluso en un grupo de filas), entonces no es necesario tener una ''celda'' almacenada como tal.
Las bases de datos no están diseñadas para esto. Pero puedes probar un par de maneras diferentes.
La manera ingenua de hacerlo es hacer una versión de One Table To Rule Them All. Es decir, crea una tabla genérica gigante, todos los tipos son (n) varchars, que tiene suficientes columnas para cubrir cualquier hoja de cálculo previsible. Luego, necesitará una segunda tabla para almacenar metadatos sobre la primera, como el nombre de la columna de la hoja de cálculo de Column1, qué tipo almacena (para que pueda ingresar y salir), etc. Luego necesitará desencadenantes para ejecutar contra inserciones que verifican los datos que ingresan y los metadatos para asegurarse de que los datos no estén corruptos, etc. etc. Como puede ver, de esta manera es un clúster completo y completo. Corría gritando desde allí.
La segunda opción es almacenar sus datos como XML. La mayoría de las bases de datos modernas tienen tipos de datos XML y algo de soporte para xpath dentro de las consultas. También puede usar XSD para proporcionar algún tipo de validación de datos y xslts para transformar esos datos en CSV. Actualmente estoy haciendo algo similar con los archivos de configuración, y está funcionando bien hasta el momento. Todavía no se conocen los problemas de rendimiento, pero confío en Knuth en eso.
La primera opción es probablemente mucho más fácil de buscar y más rápida para recuperar datos, pero la segunda es probablemente más estable y definitivamente más fácil de programar.
En momentos como este, desearía que Celko tuviera una cuenta SO.
desde un punto de vista relacional:
Spreadsheet <-->> Cell : RowId, ColumnId, ValueType, Contents
no es necesario que las filas y columnas sean entidades, pero puede hacerlo si lo desea