Как работать с «расширяющимися» таблицами

Question

Я разрабатываю приложение, включающее «страницы», которые имеют много «блоков», из которых есть несколько типов блоков.Однако я изо всех сил пытаюсь найти хороший способ сохранить эти данные в базе данных.Я предполагаю, что есть популярный способ сделать это, вот два, которые я рассматриваю:

Первый подход

• Таблица страниц
  • id
  • пользователь
  • создан, обновлен и т. д.
• Blocks
  • id
  • page (Blocks.page = Pages.id)
  • создано, обновлено
  • block_type (например, "text")
  • block_id (Blocks.block_id = nBlocks.id где n = block_type)
• Текстовые блоки
  • id
  • текстовые атрибуты

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

Подход второй

• Страницы по-прежнему
• Текстовые блоки
  • id
  • page
  • тело, текстовые элементы
  • создано, обновлено, заказ
• Список блоков
  • id
  • page
  • элементы списка
  • создано, обновлено, заказано и т. Д.

Плюсы этого - устранение запутанного способа поиска правильной таблицы для запроса для каждого блока.Минусы в том, что порядок блоков не может быть легко управляемым (update where order in any other block != $order), и что каждая таблица должна иметь одинаковые созданные, обновленные и т. Д. Поля, что требует немного усилий, если их необходимо изменить.Более серьезная проблема заключается в том, что каждая таблица, относящаяся к конкретным блокам, должна запрашиваться для каждой страницы, а не только таблицы блоков, у которых определенно есть блоки для страницы.

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

Answer 1

Подход Два имеет огромный недостаток: порядок.

Я бы выбрал первый подход, или этот: (я знаю, это выглядит грязно, но это работает)

• Страницы как один подход
• Блоки
  • ID
  • страница
  • block_type
  • текстовые элементы (все обнуляемые)
  • элементы списка (все обнуляемые)
  • xxxx-специфичные предметы (все обнуляемые)
  • создано, обновлено, заказ

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

Плюсы: То же, что и в первом подходе

Минусы:

• если у вас много типов блоков или много определенных элементов для каждого типа, у вас будет широкая и запутанная таблица для чтения.
• все можно обнулять, поэтому вы не можете быть уверены, какие поля являются обязательными, просто взглянув на таблицу

Дополнительный совет

Если вы планируете создать приложение с помощью VisualStudio, используйте Entity Data Model (файл .edmx), создайте сущности с наследованием «так, как должно быть», а затем нажмите «Создать базу данных из модели». я считаю, что в этом есть все плюсы и минусы обоих ваших подходов.