Привет, читатели! Эта статья посвящена управлению изменениями, происходящими в таблицах базы данных для определенных параметров, которые очень важны для анализа данных.
Мы постоянно разрабатываем приложения, поэтому нам необходимо использовать различные системы баз данных. И в какой-то момент времени, когда в базе данных слишком много записей, мы, как правило, запускаем какой-то анализ данных, чтобы предоставить пользователю более полное представление и чтобы мы могли предоставить наилучшие результаты, когда пользователи ищут или делают что-либо еще. операций.
Давайте возьмем очень простой пример веб-сайта электронной коммерции, где есть множество различных модулей, работающих вместе, чтобы создать конечный продукт для пользователя. На веб-сайте электронной коммерции происходит много анализа, на основе которого мы видим, как данные страниц персонализируются в соответствии с нашим профилем, а иногда предложения или цены изменяются в зависимости от истории просмотров пользователя, и когда-нибудь нам нужно порекомендовать пользователю продукты, которые он или она могут быть заинтересованы в покупке. Все это не что иное, как часть процесса разработки веб-сайта, направленного на увеличение доходов компании и в то же время на улучшение пользовательского опыта на веб-сайте. Поэтому для такого решения я представляю вам несколько методов отслеживания изменений базы данных, происходящих в нашей таблице, и обновления нашей бизнес-стратегии на этой основе.
Итак, ниже я упоминаю несколько методов для того же самого.
- Разные таблицы отслеживания для разных таблиц: –
Первая и самая основная стратегия заключается в том, чтобы хранить разные таблицы истории для таблиц, основанных на разных функциях. Допустим, у вас есть таблица продуктов, в которой есть разные столбцы, такие как ProductName, ProductPrice, ProductDescription и поля, связанные со скидкой. Поэтому мы постоянно намерены менять цены на продукты, чтобы пользователи могли получать последние предложения каждый день в своей истории просмотров.
Имена столбцов в таблице продуктов
Теперь в истории мы можем сохранить схему таблицы для таблицы продуктов как ProductName, ProductPrice, ChangedBy, ChangedTime и так далее…
Вот если завтра вы захотите мониторить значение какого-то другого поля, то вам нужно добавить новое поле в таблицу и оно начнет постоянно расширяться. Поэтому, чтобы избежать этого, у нас может быть другой подход в этом пункте, только со следующей обновленной схемой.
ColumnName, ColumnValues, Changed By, ChangedTime и так далее.
Теперь в столбцах «Имя столбца» и «Значения столбца» в истории вы можете использовать данные в формате XML, чтобы вы могли отслеживать детали.
Преимущества:-
- Легко отслеживать изменения для конкретной функциональности и быстро проверять записи.
Недостатки:-
- Каждый раз, когда нам нужно создать новую таблицу для любой существующей таблицы, связанной с сущностью, и, в конце концов, у нас может оказаться слишком много таблиц или почти вдвое.
- Трудно сопоставить данные в столбцах columnName и столбцах значений столбцов, а затем может возникнуть сложность в повторении и выполнении логики поверх них.
2. Сохранение одной сводной таблицы:
По сравнению с предыдущим подходом в этом подходе мы создадим только одну таблицу для ведения истории по разным таблицам с дополнительным именем столбца «tableName», которое указывает на то, на какую таблицу мы ссылаемся для конкретной записи. . И мы также можем удалить столбец «columnName», и мы сохраним «значения столбца» только из этих двух и сохраним данные в формате, который позволяет нам отслеживать, какой ключ имеет какое значение (Ключ — это столбец имя из основной таблицы, а значение — это значение, на которое оно было изменено по сравнению с предыдущим значением)
Преимущества:-
- У нас будет только одна таблица, которой легко управлять и которую можно быстро создать в разных средах.
- Значения можно легко отслеживать с помощью единственного столбца, содержащего значение в формате ключа и значение в формате XML в реляционной базе данных, и они могут быть основаны на объектах JSON в любой базе данных на основе NoSql.
Недостатки:-
- Мы можем перебирать множество записей в таблице для определенной функциональности, если только они не управляются должным образом.
- Если данные становятся больше, нам могут понадобиться масштабируемые подходы.
Вот некоторые из обсуждаемых подходов, основанные на другой архитектуре проекта, мы можем немного изменить обсуждаемый подход, чтобы он соответствовал нашим требованиям.
Пожалуйста, дайте мне знать, если какие-либо вопросы или какая-либо информация требуется для любого вида разработки веб-приложений или мобильных приложений или разработки архитектуры.
Пожалуйста, оставьте отзыв и любую информационную почту по адресу [email protected].
