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:52] ztb2011 |
pl:dydaktyka:ztb:2011:projekty:migracja_crm:start [2011/09/28 11:56] ztb2011 |
||
|---|---|---|---|
| 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//". | ||
| Linia 147: | Linia 147: | ||
| **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//>. | ||
