Przechowywanie tablicy obiektów(???)

0

Witam,
Do tej pory dane zapisywałem w plikach xml i było ok, jednak niedawno pojawiła się konieczność przeniesienia tego do bazy danych.
W swoim programie mam klasę (powiedzmy firma), która ma kolekcję obiektów innej klasy (powiedzmy pracownik), z których każdy ma oczywiście swoje pola (imię, nazwisko, itp). Nie bardzo pasuje mi tworzenie nowej tabeli pracownicy i tworzenie powiązań z tabelą dokumentów (mam dużo danych i na samą myśl o konfliktach, które by powstały to aż mnie mdli). Zastanawiałem się nad tworzeniem dla każdej firmy tablicy o nazwie np. IDFirmy_Pracownicy, jednak nie wiem, czy nie zamorduje tym bazy danych. Zastanawiałem się też nad bardzo długim stringiem, zawierającym po prostu posklejane odpowiednie pola, ale wydaje mi się to nieeleganckie. Jak proponujecie to rozwiązać?

1

Twoje pierwsze rozwiązanie to WTF, a drugie to gwałt na normalności.
Dane pracowników trzymaj w oddzielnej tablicy.

0
somekind napisał(a):

a drugie to gwałt na normalności.

Chyba miałeś na myśli normalizacji.

0

Dzięki za odpowiedź, więc będę musiał to przełknąć. Kolejne pytanko:
Mam jeden centralny serwer i kilka klientów, przy zamykaniu programu chciałbym wysłać (a przy uruchomieniu pobrać) dane z bazy danych. Problemów mam kilka - np.

  1. usuwanie rekordu z bazy. W programie po prostu wywalam go z kolekcji (nie mogę przechowywać usuniętych, ponieważ użytkownik na innym kliencie mógł usunąć rekord). Jedyną sensowną opcją wydaje mi się pobranie ID wszystkich dokumentów z serwera i porównanie ich z tym, co mam na miejscu.
  2. Modyfikacja rekordu - w przypadku jednego użytkownika to po prostu dodałbym boola mówiącego, czy był modyfikowany, jednak w przypadku wielu użytkowników wpadłem na taki pomysł: do każdego obiektu dodaję datę modyfikacji i updatuje rekord w bazie tylko, jak jest nowszy. Tu z kolei nasuwa się problem rozjechania zegarków (bo np. ktoś wymieni baterię w biosie i rozwali bazę). Jest jakiś prosty sposób na rozwiązanie tego problemu?
0

Tzn. pobierasz wszystkie dane przy uruchomieniu klienta, a potem pracujesz offline? Nie wiem, czy to jest dobre rozwiązanie, ja bym wszelkie zmiany, także usuwanie, wprowadzał do bazy od razu.
Co do kwestii nr 2, to jest prosty sposób, nazywa się optimistic concurrency. W skrócie polega na tym, że masz dodatkową kolumnę która służy do przechowywania znacznika czasowego (np. dedykowanego typu danych, ale to już od SZBD zależy) i jest aktualizowana automatycznie przez serwer przy każdej aktualizacji rekordu. Podczas zapisywania rekordu porównuje się te rekordy (update ... where znacznik = pobranyWczesniejZnacznik), jeśli się nie zgadzają, to dane nie zostają zapisane.

1 użytkowników online, w tym zalogowanych: 0, gości: 1