Если я вношу многостраничный отчет в базу данных, я должен сделать каждую часть отдельной таблицей?Основы базы данных базы данных SQL
Отчет может содержать дополнительные части, добавленные к нему со временем.
Неправильная практика создания таблицы, в которой со временем будут добавлены столбцы?
Благодаря
«Это плохая практика, чтобы создать таблицу, которая будет иметь столбцы добавляемые к нему, как время идет?»
Nope. Пока это одна вещь.
Отделите свои данные от основных существительных, а затем разработайте типы отношений между ними.
Если это один-ко-многим, тогда поместите внешний ключ на многих, указывающих на один. Если это много-ко многим, введите таблицу сопоставления.
EDIT: Для того, чтобы расширить, используя пример, приведенный в альтернативном ответ ...
Invoice An состоит из DescriptionDateNotes и т.д., поэтому они должны быть поля на счете-фактуре. Однако, поскольку он имеет многоInvoiceItems, это должна быть отдельная таблица с внешним ключом, чтобы ее можно было легко развернуть.
Должен ли я сделать каждую часть [отчета] отдельной таблицей?
Как правило, нет.
Отчеты представляют собой механизм «отображения». В общем, у них нет никакой структуры в базе данных. Однако структура отчета может получить структуру базы данных.
Например, счет-фактура. Как правило, счета-фактуры (тип отчета) будет использовать по крайней мере две таблицы, каждая из которых представляет собой «раздел» счета-фактуры:
InvoiceHeader
Name
Address ...etc
InvoiceLineItems
ItemID
Quantity ...etc
Кроме того, вы можете потенциально иметь таблицы, которые представляют собой разделы отчета, но которые не является частью фактических данных. Однако было бы сложно рассуждать о том, как они могут выглядеть, не зная больше о вашем конкретном приложении.
Это действительно зависит от содержания отчета. Что такое «mulitpart»?
Например, если бы я должен был сообщить о сотрудниках в конкретном отделе, я бы ожидал, что одна таблица содержит весь штат (или один набор таблиц, если эта нормализация имеет смысл), но для этого позволяет отображать одну таблицу). Тогда у меня может быть отчет с несколькими разделами, по одному на каждого сотрудника.
Однако, если в отчете есть раздел о сотрудниках, другой - о том, сколько виджета они сделали, а другое - о том, сколько дней они работали, я бы ожидал иметь одну таблицу для персонала, одну для виджетов и одну для рабочих дней.
Затем мой отчет будет извлекать из соответствующих таблиц для заполнения отчета.
Как правило, правила нормализации связаны с необходимостью эффективного хранения данных, а не с дизайном отчета. Нормализация старается избегать вставки, удаления и обновления аномалий, гарантируя, что каждая часть данных хранится только один раз и не зависит от изменений других частей данных. Это приводит к более чем одному отчету или любому другому отдельному действию.