Eksport tworzy nową kopię poza zabezpieczeniami widoku
W CRM użytkownik może widzieć tylko wybrane rekordy i pola. Po eksporcie otrzymuje osobny plik, który nie reaguje już na późniejsze odebranie dostępu w aplikacji. Dlatego projektowanie eksportu zaczyna się od pytania, do czego plik jest potrzebny i jakie informacje są rzeczywiście niezbędne. Wydruk listy kontaktowej na wydarzenie nie wymaga automatycznie historii rozliczeń ani wewnętrznych komentarzy opiekuna. Domyślny zakres powinien odpowiadać zadaniu, nie całej tabeli bazy.
Uprawnienie do oglądania pojedynczego klienta nie musi oznaczać prawa do pobrania całej listy. Oddziel te możliwości i kontroluj je po stronie serwera. Parametr kolumn przesłany z przeglądarki wymaga sprawdzenia, nawet jeśli interfejs pokazuje wyłącznie dozwolone pola. W przeciwnym razie ukryta kolumna może nadal trafić do pliku po ręcznej zmianie żądania. Rejestr eksportu powinien wskazywać autora i zakres, ale nie duplikować w logach całej zawartości.
Zdefiniuj moment, którego dotyczą pobrane dane
Długi eksport może odczytywać bazę w kilku partiach, gdy pracownicy równocześnie wprowadzają zmiany. Ustal, czy wynik ma odzwierciedlać jeden spójny stan, czy zbiór odczytów wykonanych w pewnym przedziale czasu. Raport wymagający uzgodnienia liczb potrzebuje innej gwarancji niż robocza lista telefonów. Nazwij ograniczenie w metadanych pliku. Sama data rozpoczęcia nie dowodzi, że wszystkie wiersze opisują dokładnie tę samą chwilę.
W przypadku dużych zbiorów rozważ zadanie w tle i stabilną kolejność rekordów. Zwykłe przesuwanie numeru strony podczas równoczesnego dopisywania danych może prowadzić do pominięć lub powtórzeń. Dobierz sposób stronicowania i izolacji do bazy oraz wymaganej spójności. Nie trzymaj niepotrzebnie długiej transakcji bez oceny kosztów. Najpierw określ potrzebny rezultat, a dopiero potem wybierz mechanizm techniczny i ograniczenia wielkości eksportu.
Arkusz kalkulacyjny może zmienić znaczenie tekstu
CSV nie zapisuje bogatych typów komórek. Program otwierający plik może uznać numer z zerem na początku za liczbę, kod za datę, a niektóre wartości za formułę. To problem zarówno poprawności, jak i bezpieczeństwa. Dane podane przez klienta powinny pozostać danymi, nie poleceniem wykonywanym przez arkusz. Samo ujęcie wartości w cudzysłów nie gwarantuje neutralizacji formuł po otwarciu w każdym programie i po ponownym zapisaniu pliku.
Dla odbiorców pracujących w arkuszu rozważ format pozwalający jawnie oznaczyć komórki tekstowe. W CSV określ bezpieczną strategię obsługi wartości interpretowanych jako formuły, separatorów, nowych linii i cudzysłowów, a potem sprawdź ją w rzeczywiście używanym oprogramowaniu. Nie usuwaj bez zastanowienia pierwszego znaku z każdego pola, bo zmienisz legalne dane. Zachowaj oryginał w systemie i jasno oddziel techniczny zapis eksportowy od wartości źródłowej.
Gotowy plik wymaga kontroli dostępu i czasu życia
Plik zawierający klientów nie powinien trafiać pod przewidywalny, publiczny adres. Pobranie musi być autoryzowane albo odbywać się przez odpowiednio ograniczony mechanizm dostępu. Losowa nazwa utrudnia zgadywanie, ale nie zastępuje sprawdzenia, komu wolno pobrać dokument. Przy linkach czasowych pamiętaj, że sam odnośnik może zostać przekazany dalej. Ustal, czy potrzebne jest dodatkowe uwierzytelnienie i czy prawo do pobrania sprawdzasz ponownie po zakończeniu generowania.
Zaprojektuj usuwanie nieaktualnych plików i obsługę nieudanych zadań. Archiwum tymczasowe nie powinno rosnąć bez końca tylko dlatego, że użytkownik nie kliknął pobierania. Powiadomienie e-mail może informować o gotowości, zamiast przenosić całą bazę jako załącznik. Nie obiecuj jednak, że usunięcie kopii serwerowej odbierze plik osobie, która już go zapisała. Kontrola dalszego użycia wymaga procedur organizacyjnych poza samym przyciskiem aplikacji.
Format odbieraj z użytkownikiem, który wykorzysta dane
Uzgodnij nazwy kolumn, kodowanie, separator, format dat, walutę i znaczenie pustej wartości. Brak informacji, zero i „nie dotyczy” nie są tym samym. Przy numerach identyfikacyjnych zachowaj dokładny tekst. Jeżeli plik ma wracać do systemu, dołącz stabilny identyfikator rekordu i wersję schematu, a nie tylko nazwę klienta. Ułatwi to odróżnienie późniejszej aktualizacji od utworzenia duplikatu, choć sam eksport nie powinien automatycznie uruchamiać importu.
Przygotuj próbkę obejmującą polskie znaki, długą notatkę, cudzysłów, nową linię, wartość zaczynającą się od zera i bezpieczny tekst testowy przypominający formułę. Otwórz plik w docelowym narzędziu, zapisz i otwórz ponownie. Sprawdź także wydruk i przekazanie do innego programu, jeśli to część procesu. Zgodność bajtów z generatorem nie wystarcza, gdy odbiorca zobaczy inne znaczenie danych po automatycznej konwersji.
Bezpieczny eksport ma właściciela i ślad wykonania
W historii operacji zapisz zakres, liczbę rekordów, moment przygotowania, status i osobę zlecającą. Przy błędzie pozwól ponowić zadanie świadomie, z aktualnie obowiązującymi uprawnieniami. Nie oznaczaj pustego pliku jako poprawnego, jeśli zapytanie do bazy zakończyło się wyjątkiem. Rozdziel „brak pasujących rekordów” od „nie udało się odczytać danych”. Odbiorca musi wiedzieć, czy wynik jest wiarygodny, zanim wykorzysta go do dalszej pracy.
Ogranicz nadmierną liczbę równoczesnych eksportów i monitoruj nietypowe próby pobierania całej bazy. Nie każdy duży eksport oznacza nadużycie, ale powinien mieć biznesowe uzasadnienie i uprawnionego autora. Odbiór funkcji zakończ próbą z kontem o ograniczonym dostępie oraz kontem, któremu odebrano rolę między zleceniem a pobraniem. Eksport jest odrębną ścieżką dostępu do informacji, dlatego wymaga pełnego projektu, a nie tylko serializacji tabeli do pliku.