Блог

Я только начал изучать Neo4J, чтобы отслеживать собственные приложения, использующие SQL Server, какие таблицы и столбцы используют эти приложения.

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

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

[Вопрос] Мой вопрос заключается в следующем.

У меня есть три типа узлов (таблица, столбец, приложение). Я сопоставил взаимосвязь между столбцом -> Таблица и из приложения — > Столбец, но должен ли я сопоставлять взаимосвязь из приложения — > Таблица, поскольку я могу перемещаться по графику, как это приложение -> Столбец -> Таблица

Посмотрите на диаграммы, чтобы получить представление о том, что я имею в виду.

Я включил код Cypher для создания графика.

Я знаю, что в общей схеме вещей я в основном спрашиваю о ТРЕХ (3) взаимосвязях (в моем примере), так зачем вообще беспокоиться, поскольку эти взаимосвязи незначительны по сравнению с количеством взаимосвязей столбцов (просто добавьте их уже).

Причина запроса больше связана с корректностью и изучением лучших практик.

Спасибо за отзыв.

Вот код шифрования, используемый для создания примерного графика

 CREATE (Customers:Table {Name:'Customers'})

CREATE (CustomerId:Column {Name:'CustomerId'})
CREATE (FirstName:Column {Name:'FirstName' })
CREATE (LastName:Column {Name:'LastName' })
CREATE (Address1:Column {Name:'Address1' })
CREATE (City:Column {Name:'City' })
CREATE (State:Column {Name:'State' })
CREATE (Cellphone:Column {Name:'Cellphone' })
CREATE (eMail:Column {Name:'eMail' })

CREATE (App_1:App {Name:'Call Back system'})
CREATE (App_2:App {Name:'Support'})
CREATE (App_3:App {Name:'Marketing'})


 
CREATE (CustomerId)-[:CONTAINED_IN]->(Customers)
CREATE (FirstName)-[:CONTAINED_IN]->(Customers)
CREATE (LastName)-[:CONTAINED_IN]->(Customers)
CREATE (Address1)-[:CONTAINED_IN]->(Customers)
CREATE (City)-[:CONTAINED_IN]->(Customers)
CREATE (State)-[:CONTAINED_IN]->(Customers)
CREATE (Cellphone)-[:CONTAINED_IN]->(Customers)
CREATE (eMail)-[:CONTAINED_IN]->(Customers)

//App 1
CREATE (App_1)-[:REFERENCES]->(Customers)
CREATE (App_1)-[:USES]->(CustomerId)
CREATE (App_1)-[:USES]->(FirstName)
CREATE (App_1)-[:USES]->(LastName)
CREATE (App_1)-[:USES]->(Cellphone)

//App 2
CREATE (App_2)-[:REFERENCES]->(Customers)
CREATE (App_2)-[:USES]->(CustomerId)
CREATE (App_2)-[:USES]->(FirstName)
CREATE (App_2)-[:USES]->(LastName)
CREATE (App_2)-[:USES]->(Address1)
CREATE (App_2)-[:USES]->(City)
CREATE (App_2)-[:USES]->(State)

 //App 3
CREATE (App_3)-[:REFERENCES]->(Customers)
CREATE (App_3)-[:USES]->(CustomerId)
CREATE (App_3)-[:USES]->(FirstName)
CREATE (App_3)-[:USES]->(LastName)
CREATE (App_3)-[:USES]->(eMail)
;  

Не следует вводить избыточные взаимосвязи, если вы не знаете наверняка, что они необходимы в вашей модели данных (например, профилирование важных вариантов использования показало, что возможность выполнить 1 переход вместо 2 приводит к необходимому повышению производительности).

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