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

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

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

Entity-Attribute-Value - Wikipedia

Answer 2

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

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

нет никакого требования для строки и столбца, чтобы быть лица, но вы можете, если вам нравится

Answer 3

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

Answer 4

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

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

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

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

Это время, как я хотел бы, чтобы у Селько была учетная запись SO.