GoldenLine
Zaloguj się

konto usunięte

Temat: Projekt bazy danych.

Adrian O.:
Opisujesz typowe problemy wynikające z projektowania typu "database centric" i trzymania jakiejs części logiki w bazie, gdzie sporo obliczeń wykonuje sama kwerenda. A cierpi potem m.in. właśnie DBA.

Nie, Weź chociażby zmianę dwóch kolumn na jedną. Nieważne dlaczego, bo programista miał zły dzień i tak chce.

Przed zmianą było to: table a (x text, y text), a po zmianie ma być: table a (z text), gdzie dane to z = x || " " || y.

Zrobienie tego jednym updatem grozi ładnym lockowaniem całej tabeli, stara aplikacja nie pójdzie na nowej strukturze, nowa nie pójdzie na starej. Można zatem zatrzymać program, zaktualizować bazę, odpalić nowy program. Pytanie tylko ile czasu to zajmie. Jak wrzucałem SQLa, który był wynikiem półrocznej pracy programistów i miał ok. 40 tys. linii, to miało to zająć dwa tygodnie.

Innym rozwiązaniem jest np. to, że można dodać kolumnę (dobrze napisana stara aplikacja pójdzie), napisać trigger aktualizujący kolumnę z, oraz w tle, przy działąjącej aplikacji, kopiować dane wiersz po wierszu. Sam upgrade aplikacji może oznaczać skasowanie kolumn x i y, albo też i niekasowanie ich na razie wcale.

Nie ma tu żadnej logiki i wykonywania obliczeń w bazie, a problem jest. Ot, po prostu programista miał chęć połączenia kolumn.
Link do wypowiedziLink
Acg N.

Acg N. .

Temat: Projekt bazy danych.

Szymon G.:
Nie, Weź chociażby zmianę dwóch kolumn na jedną. Nieważne dlaczego, bo programista miał zły dzień i tak chce.

A, rozumiem. No tak, to jest problem. W dodatku upierdliwy, bo poza "przemłóceniem danych" potencjalnie nie wnoszący niczego wartościowego - ot odrobinę inna reprezentacja danych. Zawsze w takich przypadkach pytam o uzasadnienie. Dlaczego nie może skleić wartości w trakcie odpytywania (jedna instrukcja! bo chyba nie programują w assemblerze), dlaczego nie może skleić wartości w warstwie widoku, tylko blokować z tak błahego powodu bazę na kilka godzin. Byłoby to jeszcze zrozumiałe w opisanym przeze mnie przypadku dokładnego odwzorowania dokumentu, ale i tak takie rzeczy najpierw się projektuje, a nie potem "scala", więc nie sądzę by to było powodem, raczej "tak, bo tak".

Wtedy - musisz bronić jak lew TWOJEJ działki. No... pod warunkiem, że masz "siłę przebicia" i jakiś wpływ na decyzje, a wiem, ze z tym różnie bywa. W końcu jeśli w projekcie jest obecny DBA (po coś go zatrudniono) to powinno się go słuchać.Ten post został edytowany przez Autora dnia 30.12.14 o godzinie 13:14
Link do wypowiedziLink

konto usunięte

Temat: Projekt bazy danych.

Adrian O.:
Szymon G.:
Nie, Weź chociażby zmianę dwóch kolumn na jedną. Nieważne dlaczego, bo programista miał zły dzień i tak chce.

Wtedy - musisz bronić jak lew TWOJEJ działki, pod warunkiem, że masz "siłę przebicia" i jakiś wpływ na decyzje...

A to już kwestia organizacji pracy. Fajnie jak jest DBA w zespole i na bieżąco rozmawia z ludźmi. No ale to problem stary jak świat, czy warto brać do pracy ludzi znających swoje narzędzia, czy lepiej zastąpić ich stadem studentów. A potem powstaje taki system do liczenia głosów dla PKW :)
Link do wypowiedziLink

konto usunięte

Temat: Projekt bazy danych.

Widzę ciekawa dyskusja z tego wynikła :)
No tak na pewno przyda mi się na bardziej praktyczne podejście do sprawy, którego na pewno na studiach się nie nauczę. Jako że zainteresowały mnie bazy danych dobrze znać zalety i wady tego co aktualnie na studiach poznaje.
Póki jednak czas nie pozwala mi bardziej poznać temat. Na pewno nadejdzie na to czas:)
Moja wiedza niestety z baz danych opiera się dopiero na tym co się nauczyłem na studiach w tym semestrze i mnie ogranicza :) .Do tego myślę że projekt raczej też nie musi być strasznie skomplikowany.
Dlatego szukam jakiś prostszych rozwiązań mojego problemu, niestety rzadko najbardziej efektywnych.
W moim projekcie muszą znajdować się atrybuty zmieniające się w czasie więc u mnie to raczej pieniądze na kontach.
Tak więc czy może być tak że po prostu jak było pisane niżej stworzyć druga tabelę taką samą jak rachunki + data i kwota na rachunku ? i po każdej transakcji dodawać nowe wierze?Ten post został edytowany przez Autora dnia 30.12.14 o godzinie 20:26
Link do wypowiedziLink
Marek Kubiś

Marek Kubiś programista c#

Temat: Projekt bazy danych.

Adrian O.:
Marek K.:
Wypada uzupełnić, że zmianom danych towarzyszą zmiany struktur danych i to jest źródłem największych problemów programistycznych.
Owszem, tak właśnie jest, kiedy stosuje się model relacyjny wyłącznie w >= III NF.
Wyłącznie? Pozostanę jednak przy opcji, że zmiany struktur danych zawsze są sprawcą problemów programistycznych, a o skali decyduje skala tych zmian. ;-)
Szymon G.:
Owszem, ale na potrzeby tej dyskusji akurat to pominąłem. To jest tylko projekt na zaliczenie, nikt nie będzie go później bardzo zmieniał.
Pełna zgoda. Ponieważ jednak pojawił się wątek dostępu do danych historycznych więc nawiązałem. ;-)
Natomiast wypada jeszcze uzupełnić, że sama zmiana struktury to często większy koszmar dla DBA, niż programisty.
Adrian O.:
Opisujesz typowe problemy wynikające z projektowania typu "database centric" i trzymania jakiejs części logiki w bazie, gdzie sporo obliczeń wykonuje sama kwerenda. A cierpi potem m.in. właśnie DBA.
A jak nie ma logiki w bazie to nie ma takich problemów? Uważam, że są i jest to cecha charakterystyczna każdego rozwiązania, które łączy w sobie różne środowiska tak programistyczne jak i obejmujące integrację dowolnych rzeczy, systemów, np. hardware + software, np. przykład Szymona na łączenie pól - prosto i na temat. ;-)
Adrian A.:
Dlatego szukam jakiś prostszych rozwiązań mojego problemu, niestety rzadko najbardziej efektywnych.
I bardzo dobrze, ale musisz uświadomić sobie, że nie uciekniesz od uzasadnienia dlaczego takie a nie inne rozwiązanie przyjąłeś. A udzielenie odpowiedzi na pytanie dlaczego wymaga wyjście poza założone granice. Czyli musisz wiedzieć nie tylko to co musisz wiedzieć, ale także musisz wiedzieć to czego nie wiesz. To czego nie wiesz nie musisz wiedzieć, zawsze możesz odpowiedzieć, że się nauczysz wtedy kiedy będzie taka potrzeba (i tę potrzebę prawidłowo wskażesz), ale pozostawienie pytania bez odpowiedzi skazuje cię na nieprzewidziane problemy.

Mówiąc krótko, nasza wiedza składa się z naszej wiedzy i wiedzy o naszej niewiedzy. ;) To minimalizuje negatywne skutki nieprzewidywalnego. ;-)
Tak więc czy może być tak że po prostu jak było pisane niżej stworzyć druga tabelę taką samą jak rachunki + data i kwota na rachunku ? i po każdej transakcji dodawać nowe wierze?
Jedną nie ogarniesz. Drugą taką samą tabelą też nie. Natomiast rozwiązanie z dwoma podobnymi tabelami Transaction i Account plus ClientProduct plus tabele słownikowe BankProduct, .., plus wcześniej wskazane tabele jako wersja minimum wydaje się, że pozwolą już coś stworzyć. ;-)
Link do wypowiedziLink

konto usunięte

Temat: Projekt bazy danych.

Marek K.:
Natomiast rozwiązanie z dwoma podobnymi tabelami Transaction i Account plus ClientProduct plus tabele słownikowe BankProduct, .., plus wcześniej wskazane tabele jako wersja minimum wydaje się, że pozwolą już coś stworzyć. ;-)

Hm nie za bardzo rozumiem. Na pewno potrzebna jest jedna tabela podobna do Accounts , a nie zrozumiałem czy chodzi o tabelę podobną do Transactions czy one dwie powinni być do siebie podobne. Tak samo za bardzo nie rozumiem do czego miało by być ClientProduct i BankProduct:(
Link do wypowiedziLink
Marek Kubiś

Marek Kubiś programista c#

Temat: Projekt bazy danych.

Adrian A.:
Hm nie za bardzo rozumiem.
Podobieństwo Account i Transaction - rejestracja zmieniających się w czasie wartości (pieniądze).

Account - stany kont klientów banku,
Transaction - wpłaty, wypłaty, przelewy, .., (wszystkie operacje na + i -)
BankProduct - słownik z ofertą banku: kredyt hipoteczny, kredyt samochodowy, debet w rachunku, ..,
ClientProduct - produkty bankowe klientów (jeden klient wziął kredyt taki, inny klient siak kredyti, a jeszcze inny ubezpieczył się i dodatkowo coś jeszcze, .. itp).
Link do wypowiedziLink

konto usunięte

Temat: Projekt bazy danych.

Aaa to już uwzględniłem w moim projekcie, dziękuję bardzo za pomoc :)
Link do wypowiedziLink

konto usunięte

Temat: Projekt bazy danych.

Adrian O.:
[...]
Słowniki w bazie to gwarancja spójności.
Po drugie - są sytuacje, gdzie baza przeżywa, a technologia, która z niej korzysta zmienia się.

Jeżeli powyższe nie mają znaczenia. Można robić jakkolwiek.
Link do wypowiedziLink
« Wróć do tematów
Odpowiedz

Podobne tematy


Następna dyskusja:

Projekt-bazy danych




Wyślij zaproszenie do
Anuluj