Synchronizacja towarów (szybkie sprawdzanie czy towar został zmieniony)

[Mamut Maniek 114]

Szukam optymalnego sposobu na synchronizację towarów. Chciałbym pobierać towary z Subiekt GT do mojej aplikacji ale w sposób szybki i wydajny. Niestety synchronizacja polegająca na sprawdzaniu każdego towaru i każdego jego pola jeden do jeden (symbol, nazwa, ean, producent, waga, cena itp) trwa dość długo. Zastanawiałem się, czy gdzieś w bazie Subiekt GT jest np. wersja towaru, która zmienia się na wyższy numerek dopiero po faktycznej edycji i zmianie towaru przez użytkownika. Dzięki takiemu numeru wersji można by szybko porównać ze swoją bazą czy coś trzeba aktualizować.

Wiem, że w Sello dość dobrze to działa i ciekawi mnie jak tam działa mechanizm wykrywania towarów do aktualizacji.

@Bartosz Rosa może podpowiesz coś?

Niestety w Profilerze nie udało mi się znaleźć żadnej podpowiedzi.

[Marcin Zborowski 42]

Z tego co pamiętam strukturę tabeli tw__towar to nie ma tam takiego pola. Poza tym ta tabel jest powiązana z wieloma innymi tabelami (w kartotece towar widzimy to w jednym miejscu co nie znaczy że w bazie wygląda to tak samo) więc ustalenie wersji jest praktycznie nierealne bo każdy mogły to inaczej interpretować.

[Damian Uruszczak 7]

Dodatkowe triggery (update, insert, delete) na tabeli tw__towar w których zapisujesz Log o zmianie do jakieś swojej tabeli, którą stworzysz.

Edytowane 11 Kwietnia przez Damian Uruszczak

[Marcin Zborowski 42]

2 godziny temu, Damian Uruszczak napisał:

Dodatkowe triggery (update, insert, delete) na tabeli tw__towar w których zapisujesz Log o zmianie do jakieś swojej tabeli, którą stworzysz.

Twój pomysł jest OK ale pop pierwsze wymaga ręcznej dłubaniny (a użytkownikowi chyba chodzi o jakiś automat) a po drugie zawsze istnieje ryzyko że jak wyjdzie nowa wersja to może coś namieszać jak będą zmiany w tabelach którymi triggery operują. 

Jednak jest to jakieś rozwiązanie.

[Damian Uruszczak 7]

Triggery w bazie się dubluje - są Inserta ale można dodać swoje i aktualizacja do wyższej wersji ich nie usuwa. Poprzez log rozumię że w tabeli użytkownika dodaje się wpis z informacjami jaka operacja (dodano , usunięto, zmodyfikowano), symbol lub ID towaru i timestamp logu. Nie trzeba zapisywać co się zmieniło a jedynie sam fakt, że zmiana była. Dopiero synchronizacja właściwa użytkownika apki porówna sobie dane.  Mamut Maniek napisał o swojej aplikacji więc potrafi oprogramować bazę danych. Rozwiązanie bezpieczne - sam korzystam z podobnego rozwiązania.

Edytowane 12 Kwietnia przez Damian Uruszczak

[Mamut Maniek 114]

Triggery są ok ale wiem, że np. Sello radzi sobie z tym super i potrafi bardzo szybko zsynchronizować towary z bazy Subiekt GT do bazy Sello. Jestem ciekaw jak oni to mają ogarnięte. Wiem, że jak zaktualizuje towar w bazie Subiekt GT przez zapytanie UPDATE to taki towar Sello nie wykryje do aktualizacji ale jak go zaktualizuje ręcznie to już tak. Więc coś pokroju mojego pomysłu z wersją towaru pewno jest zaimplementowane.

[Daniel Kozłowski 1 171]

3 godziny temu, Damian Uruszczak napisał:

Triggery w bazie się dubluje - są Inserta ale można dodać swoje i aktualizacja do wyższej wersji ich nie usuwa.

Sprostuję - ogólnie to NIE prawda, wszystko zależy od tego, czy konwersja bazy danych zostanie obsłużona, czy też nie (w przypadku zaszyfrowanego triggera i zmiany struktury tabeli trigger zostanie usunięty podczas aktualizacji).

[Damian Uruszczak 7]

Tak, zgadza się, jeżeli trigger czyta z pola, które jest zmodyfikowane przez update wersji programu. Mamut Maniek chce mieć informację jedynie o zmianie towaru a porównywać będzie później w swoim programie. Szansa, że Insert w aktualizacji wywali tw_Id z tabeli tw__towar ,który jest kluczem dla tej tabeli jest raczej niewielkie 😉

Jeżeli, modyfikacja będzie aż tak duża to aplikacja i tak będzie musiała zostać dostosowana do nowej wersji tabeli - wtedy też dostosować będzie trzeba trigger.

Jak wspomniałem, mam takie rozwiązanie i kilkanaście jeśli nie kilkadziesiąt aktualizacji mam za sobą. 

Rozumiem jednak że "rozwiązania partnerskie" są do zakupienia 😉 

Edytowane 12 Kwietnia przez Damian Uruszczak

[Daniel Kozłowski 1 171]

9 minut temu, Damian Uruszczak napisał:

Tak, zgadza się, jeżeli trigger czyta z pola, które jest zmodyfikowane przez update wersji programu. Mamut Maniek chce mieć informację jedynie o zmianie towaru a porównywać będzie później w swoim programie. Szansa, że Insert w aktualizacji wywali tw_Id z tabeli tw__towar ,który jest kluczem dla tej tabeli jest raczej niewielkie 😉

Jeżeli, modyfikacja będzie aż tak duża to aplikacja i tak będzie musiała zostać dostosowana do nowej wersji tabeli - wtedy też dostosować będzie trzeba trigger.

Niestety kolejny raz się NIE zgadza, nigdzie nie pisałem o modyfikacji kolumn wykorzystywanych przez trigger tylko o zmianie struktury tabeli, nie musi być nic zmieniane, wystarczy, że będzie dodawana nowa kolumna (co do zasady nie są usuwane niewykorzystywane kolumny), gdzie w takim przypadku jest usuwana i zakładana na nowo tabela. Sugeruję po prostu poznać działanie programu przed jego opisywaniem i tym bardziej przed jego rozszerzaniem.

 

11 minut temu, Damian Uruszczak napisał:

Jak wspomniałem, mam takie rozwiązanie i kilkanaście jeśli nie kilkadziesiąt aktualizacji mam za sobą. 

Jakie "dokładnie" rozwiązanie - takie jak opisałem, czy jednak inne skoro działa od tak długiego czasu ? To, że coś działa, nawet od dawna, nie oznacza, że zostało zrealizowane poprawnie, miałem przypadki ujawnienia się błędów rozwiązań dodatkowych po ponad 10 latach, takie przypadki były też opisywane na forum.

 

11 minut temu, Damian Uruszczak napisał:

Rozumiem jednak że "rozwiązania partnerskie" są do zakupienia 😉 

Osobiście nie rozumiem o czym Pan pisze, o jakich "dokładnie" rozwiązaniach.

[Damian Uruszczak 7]

Ustępuję pola. 

Jak to mówią w informatyce "u mnie działa".

Pozdrawiam wszystkich.

Edytowane 12 Kwietnia przez Damian Uruszczak

[Daniel Kozłowski 1 171]

2 minuty temu, Damian Uruszczak napisał:

Ustępuję pola. 

Jak to mówią w informatyce "u mnie działa".

Zapewne działa, gdyż triggery nie zostały zaszyfrowane, dzięki czemu są odtwarzane po konwersji. 

[Bartosz Rosa 1 772]

W dniu 10.04.2024 o 21:45, Mamut Maniek napisał:

Zastanawiałem się, czy gdzieś w bazie Subiekt GT jest np. wersja towaru, która zmienia się na wyższy numerek dopiero po faktycznej edycji i zmianie towaru przez użytkownika

tw_Zmiana - z tej tabeli korzysta Sello i Sello NX a samą modyfikacją w tych polach steruje Subiekt chyba z poziomu kodu, tw_ZmianaTw - to jest chyba coś od vendero ale możliwe, że działa na triggerach. Możesz zerknąć co się tam zmienia i kiedy. Sello bazuje na dacie ostatniej zmiany w towarach i porównuje z datą ostatniej synchronizacji.

 

Natomiast zmiany stanów nie są w tych tabelach uwzględniane i tam robimy porównanie stanów w Sello i w Subiekcie w tw_Stan.