Создание таблиц SQL на лету при загрузке нового контента - плохая идея? - PullRequest
2 голосов
/ 05 апреля 2009

У меня есть интересная проблема, которую я изучал, и буду признателен за несколько советов:

Я пытаюсь создать инструмент, который имитирует основные возможности инструмента управления требованиями в рамках проекта компании.

Базовая конструкция - настройка папок и документов в стиле Windows Explorer. Документы можно открывать в графическом интерфейсе, редактировать и сохранять.

Сам документ содержит иерархическую электронную таблицу (подумайте об Excel с главами, если это имеет смысл). Каждая глава содержит строки, которые на самом деле представляют собой просто текст требований + некоторые другие значения, которые дополняют его. При отображении текст требования и значения атрибутов отображаются в виде независимых столбцов (как и в Excel) с возможностями фильтрации.

Представить иерархию пользователей / полномочий / папок / etc для этого типа программ довольно просто, но я зацикливаюсь на самом содержании документа ...

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

В среднем я ожидаю ~ 500 документов в репо; Каждый документ, вероятно, будет иметь ~ 20000 активных строк; В течение года не исключено, что будет принято ~ 20 000 правок (т. Е. Каждый документ будет приобретать дополнительно 20 000 строк в год и в год).

Умножается на количество документов, которое составляет почти 10 000 000 строк (с дополнительными 10 000 000 в следующем году, в следующем году и т. Д.). Старые истории могут быть очищены, но это может быть выполнено только администратором (и не желательно, чтобы он / она это делал).

На мой взгляд, есть два способа справиться с этой ситуацией:

  • Я могу попытаться представить список всех строк всех документов в одной таблице (очень похоже на то, как phpBB хранит все сообщения всех форумов в одной таблице), или ...

  • Я могу попытаться сохранить строки каждого документа в таблице с уникальным именем (то есть каждый документ имеет свою собственную таблицу); Таблице должно быть присвоено уникальное имя, а основная таблица будет содержать список всех документов и имена таблиц, которые соответствуют каждому.

Итак, мой вопрос: что действительно предпочтительнее? Не являются ли действительно хорошими вариантами? Может ли кто-нибудь дать совет, какой подход вы считаете более подходящим, учитывая потребности?

Ответы [ 4 ]

5 голосов
/ 06 апреля 2009

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

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

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

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

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

3 голосов
/ 05 апреля 2009

Несколько моментов, которые следует учитывать при использовании нескольких таблиц:

  • Нужно ли искать информацию во всех документах? Если да, вам нужно будет искать во всех таблицах, что не так просто достичь.
  • Если схема меняется, обновить базу данных непросто, поскольку все таблицы, представляющие сущности одного и того же типа, должны быть изменены
  • Отслеживание информации о пользовательских изменениях также не очень простое, поскольку она разбита на несколько изменений (например: рассмотрим сценарий «какие документы пользователь изменил»)

Рассматривали ли вы альтернативные подходы к хранению данных? Нужно хранить каждую строку excel в базе данных как строку таблицы? Хранить данные в формате XML и сохранять только idexes в базе данных? Или, может быть, хранить только отслеживание изменений и версий документа? Приложение может взять на себя часть нагрузки базы данных и выполнить фильтрацию?

0 голосов
/ 06 апреля 2009

Возможно, вы захотите рассмотреть какую-то систему управления документами. Это похоже на то, что может сделать SharePoint - его можно настроить на создание новой версии документа при его регистрации. Документам также могут быть назначены метаданные, что может потребоваться.

0 голосов
/ 05 апреля 2009

Нет ничего плохого в том, чтобы иметь много таблиц. Кажется, для вас более разумно использовать много таблиц.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...