База данных: лучший способ смоделировать электронную таблицу

Question

Я пытаюсь найти лучший способ моделирования электронной таблицы (с точки зрения базы данных) с учетом:

• Электронная таблица может содержать переменное количество строк.
• Электронная таблица может содержать переменное количество столбцов.
• Каждый столбец может содержать одно значение, но его тип неизвестен (целое число, дата, строка).
• Должно быть легко (и эффективно) генерировать файл CSV, содержащий данные.

Я думаю о чем-то вроде:

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()

Можете ли вы придумать лучший способ моделирования электронной таблицы? Мой подход позволяет хранить данные в виде строки. Я обеспокоен тем, что он слишком медленный для создания файла CSV.

Answer 1

с реляционной точки зрения:

Spreadsheet <-->> Cell : RowId, ColumnId, ValueType, Contents

не требуется, чтобы строки и столбцы были сущностями, но вы можете, если хотите,

Answer 2

Базы данных не предназначены для этого. Но вы можете попробовать несколько разных способов.

Наивный способ сделать это - создать версию One Table To Rule All All. То есть создайте гигантскую универсальную таблицу, все типы которой (n) varchars, в которой достаточно столбцов, чтобы охватить любую видимую электронную таблицу. Затем вам понадобится вторая таблица для хранения метаданных о первой, например, какое имя столбца электронной таблицы Column1, какой тип он хранит (чтобы вы могли вводить и выводить) и т. Д. Затем вам понадобятся триггеры для запуска. вставки, которые проверяют поступающие данные и метаданные, чтобы убедиться, что данные не повреждены и т. д. и т. д. и т. д. Как вы можете видеть, этот путь представляет собой полный и полный кластер. Я бегу, крича от этого.

Второй вариант - сохранить ваши данные в формате XML. Большинство современных баз данных имеют типы данных XML и некоторую поддержку xpath в запросах. Вы также можете использовать XSD для проверки данных и xslts для преобразования этих данных в CSV. В настоящее время я делаю что-то похожее с файлами конфигурации, и пока все работает нормально. Пока нет слов о проблемах с производительностью, но я доверяю Кнуту в этом вопросе.

Первый вариант, вероятно, намного проще для поиска и быстрее извлекает данные, но второй, вероятно, более стабилен и определенно проще для программирования.

Сейчас такие времена, я бы хотел, чтобы у Селко был такой счет.

Answer 3

Возможно, вы захотите изучить модели данных EAV (Entity-attribute-value), поскольку они пытаются решить аналогичную проблему.

Значение атрибута сущности - Википедия

Answer 4

Лучшее решение во многом зависит от того, как будет использоваться база данных. Попробуйте найти пару ожидаемых вариантов использования, а затем определитесь с дизайном. Например, если нет варианта использования для получения значения определенной ячейки из базы данных (данные всегда загружаются на уровне строк или даже в группе строк), тогда нет необходимости хранить «ячейку» как таковую.

Answer 5

Это хороший вопрос, требующий множества ответов, в зависимости от того, как вы к нему подходите, я бы хотел поделиться с вами мнением. Эта тема является одной из самых разных, о которых мы искали в Zenkit, мы даже написали статью, и мы хотели бы узнать ваше мнение по этому поводу: https://zenkit.com/en/blog/spreadsheets-vs-databases/