Для нашей системы контрольный список определяется как группа элементов. Каждый элемент имеет два возможных состояния: он в порядке или не в порядке (NOK). При заполнении контрольного списка в нашем приложении, если пользователь помечает элемент как NOK, отображается список возможных проблем. Затем пользователь может выбрать одну или несколько проблем, связанных с текущим элементом контрольного списка. Мы считаем, что элемент в порядке, если пользователь не выбрал опцию NOK.
Пример товара:
Примером предмета будет: Мороженое
Если пользователь пометит этот элемент как NOK, список возможных вариантов может быть:
Расплавленный
Дурной вкус
...
База данных для этой системы имеет следующие таблицы:
CHECKLIST_TEMPLATE:
Все шаблоны возможных контрольных списков, на которые пользователь может ответить, сохраняются в этой таблице. Пользователь может создавать или редактировать столько шаблонов, сколько он хочет.
CHECKLIST_ITEMS:
Здесь мы связываем, какие элементы принадлежат какому шаблону. Элемент может принадлежать только одному шаблону, но шаблон может содержать несколько элементов.
CHECKLIST_ITEMS_NOK_OPTIONS:
В этой таблице мы связываем опции NOK с элементом контрольного списка. Параметр NOK может принадлежать только одному элементу, но элемент может иметь несколько параметров NOK.
Это основные таблицы для запуска контрольного списка. У нас есть другой набор таблиц для сохранения контрольных списков, на которые отвечают пользователи:
CHECKLIST:
Эта таблица содержит: что ответил пользователь, какой шаблон и когда. Каждая запись в этой таблице имеет свой уникальный идентификатор.
CHECKLIST_ANSWERS:
В этой таблице мы связываем идентификатор контрольного списка (из таблицы CHECKLIST) с параметром NOK. Если элемент имеет 5 опций NOK, мы сохраняем в этой таблице пять записей, сообщая, выбрал ли пользователь эту опцию NOK при ответе на контрольный список (далее вы поймете, почему мы используем этот подход).
Теперь к проблеме:
Контрольный список с 30 пунктами, каждый элемент с 3 опциями NOK добавит к таблице CHECKLIST_ANSWERS 90 строк. Эта таблица в настоящее время растет на 100 тыс. Строк в день, и мы обеспокоены размером таблицы. Эта таблица имеет тенденцию расти еще быстрее со временем. Таким образом, в следующем месяце может быть 120 тыс. Строк в день, остальные 150 тыс. Строк в день (к концу 2018 г. мы оцениваем, что эта таблица будет расти по 400 тыс. Строк в день, а в середине 2019 г. - 2 тыс. Строк в день) ...
Мы не можем удалить старые контрольные списки, поскольку они используются для генерации некоторых отчетов нашим клиентам.
Воссоздание отвеченных контрольных списков
(далее вы поймете, почему мы используем этот подход)
Мы решили сохранить каждый параметр NOK, потому что пользователь может редактировать шаблон. Так, например, он может изменить описание предмета. Это опасная функция (которая также необходима), поскольку, если пользователь изменяет , что означает элемента, уже отвеченные контрольные списки могут быть скомпрометированы. Чтобы преодолеть эту проблему и обеспечить целостность контрольных списков, когда пользователь редактирует элемент, мы проверяем в серверной части, чтобы определить, изменился ли смысл элемента. Если это происходит, текущий элемент деактивируется (со всеми его параметрами), а другой элемент автоматически создается и связывается с шаблоном. Это гарантирует, что старые контрольные списки связаны со старым элементом, а новые будут связаны с новым элементом.
Та же логика происходит, если пользователь также редактирует опцию NOK.
В связи с этим нам необходимо знать, для каждого контрольного списка, на который отвечает пользователь, какие элементы были включены в шаблон в то время. Именно поэтому мы сохраняем все параметры NOK для всех элементов в таблице CHECKLIST_ANSWERS. С помощью простого объединения мы можем воссоздать тот же контрольный список, на который ответил пользователь в данный конкретный момент, с учетом того, какие элементы или опции NOK были активными.
Чтобы решить проблему быстрого роста стола, до сих пор мы предлагали 4 возможных решения. Два из них предполагают, что мы не будем изменять то, что мы сохраняем в таблице CHECKLIST_ANSWERS, мы будем продолжать сохранять все опции NOK, выбранные или нет. Два других считают, что мы меняем реализацию, и вместо сохранения каждой опции NOK и указания, выбрал ли пользователь эту опцию или нет, мы бы сохранили только выбранных опций. Поэтому, если с предметом все в порядке, в таблице не будет записей для этого предмета.
Решения, сохраняющие ту же логику в CHECKLIST_ANSWERS:
1 - разбить текущую таблицу CHECKLIST_ANSWERS на две другие таблицы
Мы можем разбить текущую таблицу CHECKLIST_ANSWERS на две части: CHECKLIST_ANSWERS_SELECTED и CHECKLIST_ANSWERS_NOT_SELECTED. Это решение легко внедрить, но выгода не так велика. В большинстве отвеченных контрольных списков более 90% опций NOK не выбраны, поэтому таблица CHECKLIST_ANSWERS_NOT_SELECTED будет продолжать быстро расти.
2 - Создать конкретные таблицы по периодам
Идея этого подхода заключается в том, что мы разбиваем таблицу CHECKLIST_ANSWERS на некоторый период времени. Таким образом, мы могли бы иметь таблицу по году или месяцу. Чтобы упростить SELECT, мы могли бы инкапсулировать создание отвеченного контрольного списка внутри представления (или функции), чтобы проверить дату контрольного списка и получить данные из правильной таблицы.
Решения, изменяющие таблицу CHECKLIST_ANSWERS для сохранения только выбранных параметров NOK:
1 - Отслеживание выпусков шаблонов контрольных списков
Каждый раз, когда шаблон контрольного списка редактируется, мы можем сохранять состояние каждого элемента и опции NOK (если это было в порядке или недостаточно). Поэтому, когда нам нужно пересоздать контрольный список, нам нужно будет проверить, какие пункты и опции NOK были активны, когда на контрольный список был дан ответ. Сравнение даты контрольного списка с историей шаблона контрольного списка. Помимо сложности, которую это может добавить, мы могли бы инкапсулировать эту проверку внутри представления (или функции).
2 - Создайте еще один шаблон контрольного списка, когда будет сделано каждое издание
Вместо того, чтобы отслеживать, какие элементы и параметры NOK были (де) активированы в каждой редакции шаблона контрольного списка, мы могли бы просто создать новый шаблон контрольного списка с новыми элементами и новыми параметрами NOK. Нам не нравится это решение, потому что элементы или опции NOK могут часто менять идентификаторы (даже если текст элемента остается прежним), поэтому было бы трудно создать отчеты, указывающие, например, на наиболее выбранный NOK, потому что нам нужно было бы рассмотреть все разные идентификаторы опции NOK. Сам шаблон контрольного списка может изменить свой уникальный идентификатор, но это легко исправить, просто создав высокоуровневый шаблон контрольного списка. Таким образом, этот шаблон высокого уровня может иметь только активный шаблон низкого уровня одновременно. В любом случае, мы не думаем, что преимущества такого подхода оправдывают его проблемы.
Теперь мы не понимаем, какой путь выбрать. Если мы проведем рефакторинг таблицы, чтобы сохранить только выбранные параметры NOK для контрольного списка (если элемент в порядке, то для этого элемента в таблице не будет записи), мы потеряем простой способ воссоздать отвеченный контрольный список, уже рассматривающий активные элементы и параметры NOK. , Стоит ли это того?
Мы также могли бы объединить решения из разных категорий, поэтому возможен другой подход: разбить текущую таблицу CHECKLIST_ANSWERS на две другие таблицы
И Следите за выпусками шаблонов контрольных списков.
Как лучше всего справиться с этим быстро растущим столом? Может быть, какие-то другие техники, которые мы пропустили?