Projektowanie baz danych w praktyce.

Ostatnio natknąłem, się w pracy na ciekawy problem. Wydajność bazy danych, ale nie rozumiana jako czas wykonania zapytania, ale jej zdolność do wykonania wszystkich zadanych jej w jednym czasie operacji.

Dzisiejsze aplikacje nie tylko są wielowątkowe, ale również wielo-aspektowe. Pojedyncza aplikacja, już dawno przestała stanowić całość rozwiązania, a składa się na nie (rozwiązanie) cały ekosystem modułów i aplikacji. Często w takim systemie możemy znaleźć np. moduł importu oraz eksportu uruchamiane np. przy pomocy wyrażeń CRON.

Projektując bazę danych dla takiego ekosystemu, trzeba zwrócić uwagę na dodatkowy aspekt jakim jest jednoczesny dostęp do danych z poziomu różnych procesów biznesowych.
Rozważmy przypadek w którym:

  • istnieje encja Towar
  • towary są eksportowane do zewnętrznego systemu za każdym razem gdy ulegną zmianie (odpowiada za to przebieg uruchamiany np. CRON’em)
  • ceny towarów są aktualizowane przez zewnętrzny generator (np. przy pomocy WebService)
  • w momencie gdy użytkownik pobiera towar do edycji jest on blokowany dla niego na wyłączność, aby uniknąć nadpisywania danych przez 2 użytkowników jednocześnie.

Najprostszym rozwiązaniem w tej sytuacji jest stworzenie tabeli towar z kolumnami:

  • ID
  • Nazwa
  • Atrybut Towaru 1
  • Atrybut Towaru 2
  • Cena
  • Ostatnia data exportu

Takie rozwiązanie jednak się nie sprawdzi. Wystarczy, że jakiś użytkownik będzie edytował towar a nie zadziała ani export ani aktualizacja ceny.
W takiej sytuacji należy rozważyć wyniesienie kolumn Cena oraz Ostatnia data exportu do oddzielnych tabel. Dzięki temu będą one mogły być blokowane niezależnie od pozostałych danych towaru i poszczególne procesy nie będą ze sobą kolidowały.

Comments:0

Leave a Reply

Your email address will not be published. Required fields are marked *