Różnice między wybraną wersją a wersją aktualną.
| Both sides previous revision Poprzednia wersja Nowa wersja | Poprzednia wersja | ||
|
pl:dydaktyka:ztb:2011:projekty:migracja_crm:start [2011/09/28 11:49] ztb2011 |
pl:dydaktyka:ztb:2011:projekty:migracja_crm:start [2019/06/27 15:50] (aktualna) |
||
|---|---|---|---|
| Linia 1: | Linia 1: | ||
| - | ===== Wdrażanie systemów CRM czyli udoskonalenie procesów zarządzania przepływu danych w firmie.===== | + | ====== Wdrażanie systemów CRM czyli udoskonalenie procesów zarządzania przepływu danych w firmie. ====== |
| Linia 124: | Linia 124: | ||
| Do najprostszych przykładów migracji możemy zaliczyć synchronizację dwóch baz. Może odbywa się np. za pomocą triggerów. Częstym problem s synchronizacji zwrotnej (dwustronnej) jest zapętlanie. Podczas zmiany (np. UPDATE) jednej z tabel uruchomi się trigger synchronizujący , który wykona update na drugiej bazie, gdzie tak samo uruchomione zostanie plecenie updateu. Najbardziej oczywistym rozwiązaniem będzie zastosowanie tzw. TIMESTAMPSów i na ich podstawie dokonywanie kolejnych operacji. Cały trik polega na tym by podczas aktualizacji zapisywać TIMESTAMP z bazy która wysłała dane do uaktualnienia wtedy ryzyko zapętlenia znika, gdyż podczas zmiany wiadomo, która wersja jest aktualna. Należy także unikać modyfikacji tych samych danych w obu bazach jednocześnie - powstaje problem która wersja jest bardziej aktualna? | Do najprostszych przykładów migracji możemy zaliczyć synchronizację dwóch baz. Może odbywa się np. za pomocą triggerów. Częstym problem s synchronizacji zwrotnej (dwustronnej) jest zapętlanie. Podczas zmiany (np. UPDATE) jednej z tabel uruchomi się trigger synchronizujący , który wykona update na drugiej bazie, gdzie tak samo uruchomione zostanie plecenie updateu. Najbardziej oczywistym rozwiązaniem będzie zastosowanie tzw. TIMESTAMPSów i na ich podstawie dokonywanie kolejnych operacji. Cały trik polega na tym by podczas aktualizacji zapisywać TIMESTAMP z bazy która wysłała dane do uaktualnienia wtedy ryzyko zapętlenia znika, gdyż podczas zmiany wiadomo, która wersja jest aktualna. Należy także unikać modyfikacji tych samych danych w obu bazach jednocześnie - powstaje problem która wersja jest bardziej aktualna? | ||
| - | Do kopiowanie większych bloków danych możemy użyć polecenia SELECT INTO | + | Do kopiowanie większych bloków danych możemy użyć polecenia [[http://technet.microsoft.com/en-us/library/aa225219%28SQL.80%29.aspx|SELECT INTO]] |
| <code> | <code> | ||
| Linia 137: | Linia 137: | ||
| Do najczęstszych przypadków migracji nalezą te w których struktura jednaj bazy różni się od drugiej. Jest to głównie spowodowane zmiana części funkcjonalności, bądź rozbudową systemu który operuje na naszej bazie. W takiej sytuacji, gdy tabele nie pasują do siebie w prosty sposób najlepiej jest użyć polecenia MERGE. Wykonuje ono wstawiania (INSERT), aktualizacje(UPDATE) lub operacji usuwania tabeli docelowej(DELETE) w oparciu o wyniki JOINów z tabeli źródłowej. Na przykład, można synchronizować dwie tabele przez wstawianie, aktualizowanie lub usuwanie wierszy w jednej tabeli na podstawie stwierdzonych różnic w innej tabeli. Ponieważ MERGE jest stanie przenosić dane na podstawie zadanych warunków, mamy pełna kontrolę nad tym co znajdzie się w naszej nowej bazie. | Do najczęstszych przypadków migracji nalezą te w których struktura jednaj bazy różni się od drugiej. Jest to głównie spowodowane zmiana części funkcjonalności, bądź rozbudową systemu który operuje na naszej bazie. W takiej sytuacji, gdy tabele nie pasują do siebie w prosty sposób najlepiej jest użyć polecenia MERGE. Wykonuje ono wstawiania (INSERT), aktualizacje(UPDATE) lub operacji usuwania tabeli docelowej(DELETE) w oparciu o wyniki JOINów z tabeli źródłowej. Na przykład, można synchronizować dwie tabele przez wstawianie, aktualizowanie lub usuwanie wierszy w jednej tabeli na podstawie stwierdzonych różnic w innej tabeli. Ponieważ MERGE jest stanie przenosić dane na podstawie zadanych warunków, mamy pełna kontrolę nad tym co znajdzie się w naszej nowej bazie. | ||
| - | == SKŁADNIA == | + | == Składnia polecenia MERGE: == |
| + | Opis pełnej składni znajdziesz na srtonie [[http://technet.microsoft.com/en-us/library/bb510625.aspx|technet.microsoft.com]] | ||
| - | opis pełnej składni znajdziesz na srtonie [[http://technet.microsoft.com/en-us/library/bb510625.aspx|technet.microsoft.com]] | ||
| - | == OPIS NIEKTÓRYCH ARGUMENTÓW == | + | == Opis niektórych argumentów: == |
| - | **WITH** - Określa tymczasowym zestaw wyników lub widok, znane również jako "common table expression". | + | **WITH** - określa tymczasowym zestaw wyników lub widok, znane również jako "//common table expression//". |
| - | **TOP** - Liczbowy lub procentowy wskaźnik na jaką liczbę wyników wpłynie operacje MERGE. np. ustawiając TOP(10) operacja wykona się dla pierwszych 10 z czego nie musza to być te same operacje, możemy wykonać UPDATE dla 7 i np. deldete dla 3. | + | **TOP** - liczbowy lub procentowy wskaźnik na jaką liczbę wyników wpłynie operacje MERGE. np. ustawiając TOP(10) operacja wykona się dla pierwszych 10 z czego nie musza to być te same operacje, możemy wykonać UPDATE dla 7 i np. deldete dla 3. |
| - | //database_name// - Jest nazwą bazy danych, w którym znajduje się target_table. | + | **//database_name//** - jest nazwą bazy danych, w którym znajduje się target_table. |
| - | //schema_name// - To nazwa schematu, do której należy target_table. | + | **//schema_name//** - to nazwa schematu, do której należy target_table. |
| - | //target_table// - Tabela lub widok, który służy za wzór dopasowania danych w <table_source> na podstawie <clause_search_condition>. Target_table jest celem każdego wstawiania, aktualizacji lub usuwania określonych przez klauzule WHEN .target_table nie może być tabelą zdalną, nie może też mieć żadnych wczesniej zdefiniowanych warunków. | + | **//target_table//** - tabela lub widok, który służy za wzór dopasowania danych w <//table_source//> na podstawie <//clause_search_condition//>. Target_table jest celem każdego wstawiania, aktualizacji lub usuwania określonych przez klauzule WHEN .target_table nie może być tabelą zdalną, nie może też mieć żadnych wczesniej zdefiniowanych warunków. |
| - | **USING** - Określa źródło danych, które są dopasowywane do wierszy danych w target_table na podstawie <merge_search condition>. | + | **USING** - określa źródło danych, które są dopasowywane do wierszy danych w target_table na podstawie <//merge_search condition//>. |
| - | **ON** - Określa warunki, na jakich <table_source> jest połączona z target_table, by zweryfikować w których miejscach do siebie pasują | + | **ON** - określa warunki, na jakich <//table_source//> jest połączona z target_table, by zweryfikować w których miejscach do siebie pasują |
| - | **WHEN MATCHED THEN** - kiedy wszystkie wiersze target_table pasują do wierszy zwracanych przez <table_source> ON <merge_search_condition>, i spełnione są wszystkie pozostałe warunki zapytania zwrócone rekordy są updateowane, bądź usuwane zgodnie z klauzulą <merge_matched>. | + | **WHEN MATCHED THEN** - kiedy wszystkie wiersze target_table pasują do wierszy zwracanych przez <//table_source//> ON <//merge_search_condition//>, i spełnione są wszystkie pozostałe warunki zapytania zwrócone rekordy są updateowane, bądź usuwane zgodnie z klauzulą <//merge_matched//>. |
| - | **WHEN NOT MATCHED BY SOURCE THEN** - określa wszystkie wiersze target_table nie pasujące do wierszy zwracanych przez <table_source> ON <merge_search_condition>, są one albo zaktualizowane albo usunięte zgodnie z klauzulą <merge_matched>. | + | **WHEN NOT MATCHED BY SOURCE THEN** - określa wszystkie wiersze target_table nie pasujące do wierszy zwracanych przez <//table_source//> ON <//merge_search_condition//>, są one albo zaktualizowane albo usunięte zgodnie z klauzulą <//merge_matched//>. |
