Temat: A ja się dziwię programistom, przepraszam Was...

Adrian Olszewski:
Wszystko zależy od tego, co robimy. W prostych sytuacjach ...
rekordu dla zachowania historyczności danych.

PS: tak, świadomie operuję pojęciami z RDB, zamiast - asocjacja i agregacja :)

Dodam jedynie kilka (być może mało istotnych) uwag. Redundancja danych jest możliwa i akceptowalna jedynie w fizycznym modelu danych, w logicznym modelu robimy zgodnie ze sztuką. Problem jest w tym, że często projektanci pomijają ten krok.

Wydaje się być bardziej zasadnym zastosowanie hurtowni danych. Baza danych i hurtownia danych istnieją obok siebie, z tą różnicą, że hurtownia utrwala stan danych w odniesieniu do konkretnego momentu czasowego (jest uproszczenie, nie chcę rozpisywać wykład :)). Załatwi to problem faktury.

Dziennik zmian (to ta dodatkowa redundantna tabela) w tym przypadku nie będzie redundancją danych, służy w określonym celu. Wtedy sięgamy do niej nie jako do alternatywnego źródła danych, ale jako do rejestru zmian.

Na koniec dodam, że redundancja jest względna. O tym chyba często się zapomina. Tak np. w jednej sytuacji adres to kod pocztowy, miasto, ulica, numer domu, numer mieszkania, imię, nazwisko. W innej sytuacji adres to Imię nazwisko, pole 1, pole 2. Jedno i drugie jest znormalizowane. Wszystko zależy od założeń projektowych.

Temat: A ja się dziwię programistom, przepraszam Was...

Jeśli jest to aplikacja, w której nie interesuje nas historia zmian, to wystarczy FK w bazie do pacjenta, plus w razie czego jakiś prosty auditing do osobnej tabeli - tylko dla naszej wygody. Pacjent jest zawsze tym samym fizycznie bytem. I tutaj wygodnie się wyszukuje informacje w bazie. Załóżmy, że jesteśmy właścicielem wideoteki i chcemy zobaczyć, kto jakie filmy wypożycza celem wygenerowania oferty promocyjnej. Interesuje nas WW (wielokrotna wdowa :) ) Kunegunda Wrocławska, która zmieniała 3 razy nazwisko po kolejnych mężach. Wystarczy, że podamy jedno z nazwisk, a grzebiąc po tabeli audytowej dotrzemy, jak po sznurku, do jej PK, a mając PK - możemy wygenerować kompletną listę rezultatów wyszukiwania. Zakładamy, że nie można prościej się do tego dokopać (np. po
PESELu).

ile kilometrów długości będzie miało to zapytanie i jak długo będzie trwało jego wykonanie?

bo na mój rozum wystarczy osobie dopisać PESEL lub NIP i zamiana nazwiska nie boli

również historyczne dane. Trzeba, bo pacjent, który dzwoni, nie pamięta swojego PESELa, numeru karty stałego klienta czy jeszcze tam czegoś innego.

wtedy mamy: znajdź pacjenta o nazwisku NAZWISKO i poszukaj innych wpisów o tym samym PESEL co ten... po drugie nie muszę sztucznie komplikować systemu tylko po to by "trzymać historię"...

Po drugie (chyba to gdzieś pisałem), używając atrybutów obiektów (związki logiczne a nie implementacyjne) zamiast trwałych asocjacji/relacji mogę komponenty dowolnie odłączać i zamienić z innymi, mogę je także bez problemu integrować z obcym systemem bo nie ogranicza mnie struktura bazy i relacji w niej (owe klucze itp...).

Temat: A ja się dziwię programistom, przepraszam Was...

Aleksander Olszewski:
Wydaje się być bardziej zasadnym zastosowanie hurtowni danych. Baza danych i hurtownia danych istnieją obok siebie, z tą

oczywiście, jedna tablica z moim aktualnym adresem i obok tablica faktów, proste i mało skomplikowane..

Temat: A ja się dziwię programistom, przepraszam Was...

Jarek Żeliński:

Jeśli jest to aplikacja, w której nie interesuje nas historia zmian, to wystarczy FK w bazie do pacjenta, plus w razie czego jakiś prosty auditing do osobnej tabeli - tylko dla naszej wygody. Pacjent jest zawsze tym samym fizycznie bytem. I tutaj wygodnie się wyszukuje informacje w bazie. Załóżmy, że jesteśmy właścicielem wideoteki i chcemy zobaczyć, kto jakie filmy wypożycza celem wygenerowania oferty promocyjnej. Interesuje nas WW (wielokrotna wdowa :) ) Kunegunda Wrocławska, która zmieniała 3 razy nazwisko po kolejnych mężach. Wystarczy, że podamy jedno z nazwisk, a grzebiąc po tabeli audytowej dotrzemy, jak po sznurku, do jej PK, a mając PK - możemy wygenerować kompletną listę rezultatów wyszukiwania. Zakładamy, że nie można prościej się do tego dokopać (np. po
PESELu).

ile kilometrów długości będzie miało to zapytanie i jak długo będzie trwało jego wykonanie?

Dla wprawnego programisty nie jest to żaden problem. Przecież równie dobrze można zapytać, ile kilometrów narzutu kodu i abstrakcji daje model obiektowy? Fabryki, repozytoria, adaptery, mosty, pyłki, Chryste Panie! :)

Jak długo? Bardzo szybko, jeśli umie się pisać zapytania, korzystać z planów zapytań, a zwłaszcza, jeśli było się obecnym przy tworzeniu schematu bazy i można było wskazywać na możliwości kompromisów. I w dodatku, dzięki modelowi relacyjnemu dokładnie wiem, co zrobi silnik. Owszem, jeśli zapytania pisze student, który ledwie ogarnia jednego "subselekta" w EXIST, a daj mu w zapytaniu jeszcze jakieś case-when w selekcie czy we fromie table_value_function podżoinowaną z XMLem, to się napoci strasznie. Dla kogoś, kto w tym siedzi jest to po prostu "napisanie kodu". I, jak wspomniałem, praca umysłowa zaczyna się przy podaniu warunków logicznych na to, czego klient sobie życzy.

bo na mój rozum wystarczy osobie dopisać PESEL lub NIP i zamiana nazwiska nie boli

Oczywiście. Powiedziałem, że tylko ilustracja. Możemy wyszukiwać po metodach badań laboratoryjnych :)

wtedy mamy: znajdź pacjenta o nazwisku NAZWISKO i poszukaj innych wpisów o tym samym PESEL co ten... po drugie nie muszę sztucznie komplikować systemu tylko po to by "trzymać historię"...

Jeśli mamy ten PESEL. W aplikacjach medycznych, zwłaszcza starszych, dość często nie mamy.

Po drugie (chyba to gdzieś pisałem), używając atrybutów obiektów (związki logiczne a nie implementacyjne) zamiast trwałych asocjacji/relacji mogę komponenty dowolnie odłączać i zamienić z innymi, mogę je także bez problemu integrować z obcym systemem bo nie ogranicza mnie struktura bazy i relacji w niej (owe klucze itp...).

Oczywiście. Dyskutowaliśmy już o tym. Pisałem także w tym kontekście o problemach ze spójnością danych oraz na etapie wdrożeń (w tym ręcznej modyfikacji bazy danych). Nie wszystkie systemy, jakie się pisze, to ERP, nie wszystkie wdrażane są w korporacjach z własnym pionem IT, nie wszystkie operują na tak dynamicznej dziedzinie, na tak heterogenicznych środowiskach, nie wszystkie wszystkie wymagają takiej modularności i wymienności. A wiele z nich i tak jest przepisywana po kilku latach od zera - na nowej dziedzinie, przy nowych założeniach, bardzo często przez inne zespoły i pod innych klientów.Adrian Olszewski edytował(a) ten post dnia 07.07.11 o godzinie 14:29

Temat: A ja się dziwię programistom, przepraszam Was...

Adrian Olszewski:

ile kilometrów długości będzie miało to zapytanie i jak długo będzie trwało jego wykonanie?

Dla wprawnego programisty nie jest to żaden problem.

oczywiście, chodzi o koszt

Przecież równie dobrze można zapytać, ile kilometrów narzutu kodu i abstrakcji daje model obiektowy? Fabryki, repozytoria, adaptery, mosty, pyłki, Chryste Panie! :)

i tu jest pewien atut, rozebrane na "klocki" projekty obiektowe i ich implementacja to ślicznie sformatowany tekst, z podziałem na akapity i rozdziały, zapytanie SQL do znormalizowanej bazy to jakby z tego tekstu usunąć całe formatowanie i podział na akapity i rozdziały...

Jak długo? Bardzo szybko, jeśli umie się pisać zapytania, korzystać z planów zapytań, a zwłaszcza, jeśli było się obecnym przy tworzeniu schematu bazy i można było wskazywać na możliwości kompromisów.

no coś dużo tych wymagań :)

I w dodatku, dzięki modelowi relacyjnemu dokładnie wiem, co zrobi silnik.

czyli co?

bo na mój rozum wystarczy osobie dopisać PESEL lub NIP i zamiana nazwiska nie boli

Oczywiście. Powiedziałem, że tylko ilustracja. Możemy wyszukiwać po metodach badań laboratoryjnych :)

wtedy mamy: znajdź pacjenta o nazwisku NAZWISKO i poszukaj innych wpisów o tym samym PESEL co ten... po drugie nie muszę sztucznie komplikować systemu tylko po to by "trzymać historię"...

Jeśli mamy ten PESEL. W aplikacjach medycznych, zwłaszcza starszych, dość często nie mamy.

czasami taniej jest zmienić samochód na nowszy niż używać starego który pali 20litrów/100km, ale to trzeba policzyć....

Nie wszystkie systemy, jakie się pisze, to ERP,

oczywiście, dlatego ja zawsze podkreślam: pisze o systemach biznesowych...

Temat: A ja się dziwię programistom, przepraszam Was...

Na wstępie - nie masz nic przeciwko siekaniu postów? Bo lubię ustosunkowywać się do konkretnych wypowiedzi, a widzę, że nie wszyscy to podzielają :)

Jarek Żeliński:

Adrian Olszewski:

ile kilometrów długości będzie miało to zapytanie i jak długo będzie trwało jego wykonanie?

Dla wprawnego programisty nie jest to żaden problem.

oczywiście, chodzi o koszt

Nie przesadzajmy, minuty. Pewnie, że można zliczać wszystkie minuty, ale co z palaczami, piciem kawy, czy gapieniem się w okno, gdy brak weny twórczej :)

Czasem o wiele większym kosztem jest research nowego komponentu, technologii, sposobu rozwiązania problemu, gdzie programista napisał zapytanie w 20 minut, ale nad jakimś zagadnieniem informatycznym siedział dwa dni. To są realne czasy.

i tu jest pewien atut, rozebrane na "klocki" projekty obiektowe i ich implementacja to ślicznie sformatowany tekst, z podziałem na akapity i rozdziały, zapytanie SQL do znormalizowanej bazy to jakby z tego tekstu usunąć całe formatowanie i podział na akapity i rozdziały...

Kwestia gustu, podejścia... może jestem trochę zboczony, bo dość swobodnie czytam zapytania. O ile ktoś rozsądnie ponazywał tabele i kolumny. Ale zagadnienie nazewnictwa jest istotne także w programowaniu i są odpowiednie szkoły.

Jak długo? Bardzo szybko, jeśli umie się pisać zapytania, korzystać z planów zapytań, a zwłaszcza, jeśli było się obecnym przy tworzeniu schematu bazy i można było wskazywać na możliwości kompromisów.

no coś dużo tych wymagań :)

Oj, jak bym popatrzył na wymagania a propos OOP :P A tak fajnie się siada do okna dialogowego, w którym pod OnClick podpina się wypełnianie gridów danymi ;) Nie zastanawiałeś się kiedyś (to tak na marginesie), jak bardzo Twoja świadomość tych zagadnień sprawia, że nie dostrzegasz, ile problemu mogą sprawiać innym? :) Ja to kiedyś zrobiłem i chociaż nie jestem żadnym "rasowym obiektowcem" (uczę się i mam dobre chęci :) ), rozmowa z kilkoma programistami była dla nas obu bardzo męcząca.

No to właśnie tak samo jest z pisaniem w SQLu. Dla "nas" (tzn. korzystających z niego regularnie i do bardziej złożonych celów, niż znalezienie pracownika starszego niż 30 lat i mieszkającego w Kutnie) nie są to jakieś szczególne wymagania. Programista musi znać kupę różnych zagadnień, włącznie z debugowaniem wielowątkowych aplikacji (co nie jest trywialne) czy pisaniem takiego HTMLa, żeby go rozumiało jak najwięcej przeglądarek. Jak ktoś pisze zapytania do bazy, to logiczne, że musi posiadać pewien zakres wiedzy. I jak siada do "automagicznego" ORMa, to też musi wiedzieć, jak go dostroić, żeby działał nie gorzej, niż normalny SQL.

I w dodatku, dzięki modelowi relacyjnemu dokładnie wiem, co zrobi silnik.

czyli co?

Wg planu zapytania i ustawień silnika - do jakich table się odwołuje, ile razy, co łączy, czy pamięta wyniki, czy w wyrażeniu SELECT (AVG(x)-X)/STDEV(x)* za każdym razem liczy agregaty, czy sobie je odkłada na boku i ponownie wykorzystuje i tak dalej i tak dalej.

czasami taniej jest zmienić samochód na nowszy niż używać starego który pali 20litrów/100km, ale to trzeba policzyć....

No pewnie, że masz rację, ale czasem są "naciski" i "okoliczności". Oraz współpraca z tym, co już jest od 15 lat i chwilowo jeszcze być musi... Czyli szara rzeczywistość.

oczywiście, dlatego ja zawsze podkreślam: pisze o systemach biznesowych...

No tak, ale dyskusje dobrze jest uogólniać, by jak najwięcej dobrych praktyk przenosić na jak najszersze obszary :) I wszyscy tutaj korzystamy z tego, że Tobie się chce rozbierać te tematy na części pierwsze i edukować nas (i za to Ci wielkie dzięki, bo takie korepetycje kosztują drogo). A my patrzymy, ile damy rady z tego zastosować do różnych "bagienek", czasem z bardzo różnych dziedzin i o różnych uwarunkowaniach, w których czasem siedzimy...

--------------------
* a czemu nie użyto tam zmiennych, np.
SET @srednia = wylicz średnią
SET @odch_std = wylicz odch. std
SELECT (@srednia - x)/@odch_std ?

Bo np. okienko do definiowania raportów SQL wstępnie przeprocesowuje kod i nie rozumie składni definiowania zmiennych... smutne, ale prawdziwe :)Adrian Olszewski edytował(a) ten post dnia 07.07.11 o godzinie 14:52

Temat: A ja się dziwię programistom, przepraszam Was...

rozpisaliśmy się o podnietach z powodu danych i języka SQL a gdzie aplikacja? Bo mnie tym "SQL boli nie raz to, że logika biznesowa jest rozwłóczona po bazie i po kodzie, próba spojrzenia na cokolwiek wymaga analizy niemalze całego kodu systemu....

Temat: A ja się dziwię programistom, przepraszam Was...

Chciałem krótko zauważyć, że z punktu widzenia utrzymania i rozwoju systemu nie ma kompletnie żadnego sensu zaszywanie logiki biznesowej w bazie danych. Nie jest żadnym usprawiedliwieniem potrzeba optymalizacji zapytań, jeśli wymaga ona ingerencji w warstwę logiki biznesowej to jest błędem niemal zawsze.
Postać normalna, optymalizacje logiki na poziomie bazy danych itp. rozwiązania były programową odpowiedzią na bardzo wysokie koszty pamięci oraz mocy obliczeniowej. Różnica w koszcie utrzymania 1TB danych w roku 92 i 2011 oraz różnica w kosztach mocy obliczeniowej i pracy zmieniła się tak bardzo, że bardziej opłaca się optymalizować koszty maintenance pozwalając na redundancję danych oraz nie koniecznie najszybsze możliwe przetwarzanie niż ograniczać koszty pamięci i mocy obliczeniowej poprzez przenoszenie logiki biznesowej w warstwę danych.

Temat: A ja się dziwię programistom, przepraszam Was...

Chciałem krótko zauważyć, że z punktu widzenia utrzymania i rozwoju systemu nie ma kompletnie żadnego sensu zaszywanie logiki biznesowej w bazie danych. Nie jest żadnym usprawiedliwieniem potrzeba optymalizacji zapytań, jeśli wymaga ona ingerencji w warstwę logiki biznesowej to jest błędem niemal zawsze.
Postać normalna, optymalizacje logiki na poziomie bazy danych itp. rozwiązania były programową odpowiedzią na bardzo wysokie koszty pamięci oraz mocy obliczeniowej.

Totalnie abstrahując od tematu wątku:

Zgadzam się z wyjątkiem jednej rzeczy -
postać normalna nie ma nic wspólnego z kosztami.
Bazę normalizuje się z tych samych powodów z jakich nie dubluje się funkcjonalności w kodzie.

Różnica w koszcie utrzymania 1TB danych w roku 92 i 2011 oraz różnica w kosztach mocy obliczeniowej i pracy zmieniła się tak bardzo, że bardziej opłaca się optymalizować koszty maintenance pozwalając na redundancję danych

Według mnie, jakakolwiek redundancja na poziomie bazy danych jest złym rozwiązaniem problemu wydajności. Jeśli 'design' systemu opiera się na redundancji to prędzej czy później - będą z jego rozwojem problemy.

oraz nie koniecznie najszybsze możliwe przetwarzanie niż ograniczać koszty pamięci i mocy obliczeniowej poprzez przenoszenie logiki biznesowej w warstwę danych.

Ciekawe, czy kiedyś ludziom przejdzie szajba na to, co nazywają 'optymalizacją' ... ;)

Temat: A ja się dziwię programistom, przepraszam Was...

Jakub Wojt:
Zgadzam się z wyjątkiem jednej rzeczy -
postać normalna nie ma nic wspólnego z kosztami.

koszty "nośna", normalizacja (to także usuwanie redundancji) miało na celu między innymi nie dublowanie zapisów uwagi na koszt pamięci.

Bazę normalizuje się z tych samych powodów z jakich nie dubluje się funkcjonalności w kodzie.

funkcjonalności także się dublują, jeśli różnią się jakimś wariantem wykonania, to się nazywa przeciążanie operacji (podklasy może mieć operację o tej samej nazwie ale roniące się metodami, klasyczny szkolny przykład to: i trójkąt i koło ma operację "narysuj" ale w obu przypadkach na ekranie powstaną zupełnie różne figury)

Według mnie, jakakolwiek redundancja na poziomie bazy danych jest złym rozwiązaniem problemu wydajności. Jeśli 'design' systemu opiera się na redundancji to prędzej czy później - będą z jego rozwojem problemy.

po co wymyślono hurtownie danych?

Temat: A ja się dziwię programistom, przepraszam Was...

Jarek Żeliński:
...

Bazę normalizuje się z tych samych powodów z jakich nie dubluje się funkcjonalności w kodzie.

funkcjonalności także się dublują, jeśli różnią się jakimś wariantem wykonania, to się nazywa przeciążanie operacji (podklasy może mieć operację o tej samej nazwie ale roniące się metodami, klasyczny szkolny przykład to: i trójkąt i koło ma operację "narysuj" ale w obu przypadkach na ekranie powstaną zupełnie różne figury)

Wydaje mi się, że ani jedna, ani druga analogia nie oddaje w sposób wystarczający problemu. Redundancję danych bardziej porównałbym do boskiego obiektu. Podobnie do niego mamy w bazie tabelę ze zbyt wielką kompetencją co do zakresu dostarczanych danych.

Inną analogią do kodu, byłaby błotna bryła. W tym przypadku, podobnie jak w kodzie, mielibyśmy strukturę danych o trudnej do zrozumienia strukturze, tabele są poszatkowane, a zakres ich odpowiedzialności jest niejasny.

Jednakże podczas projektowania systemu kierujemy się jakimiś wytycznymi. Podobne wytyczne istnieją co do projektowania bazy. Nie chcę wchodzić w dyskusję co ma powstać pierwsze: projekt bazy czy obiektowy model dziedziny. Ja osobiście widzę możliwość przejścia jednej i drugiej drogi. Jedne i drugie może ze sobą "dogadać się". Przypominam, że wyznaczenie zakresów odpowiedzialności i normalizacja są pojęciami dosyć subiektywnymi i zależą od kontekstu systemu.

Według mnie, jakakolwiek redundancja na poziomie bazy danych jest złym rozwiązaniem problemu wydajności. Jeśli 'design' systemu opiera się na redundancji to prędzej czy później - będą z jego rozwojem problemy.

po co wymyślono hurtownie danych?

Kiedyś stoczyłem ciekawą dyskusję, w której postawiłem tezę, że wytyczne i ograniczenia stawiane hurtowni (schemat typu gwiazda, wyznaczenie wymiarów i faktów itp.) sprawiają, że hurtownia zbudowana wedle nich jest bazą danych w drugiej postaci normalnej. Podczas dyskusji tezy tej nikt nie obalił ;)

Zgodzę się z Tobą, Jarku, że często zapomina się o tym, że jest coś takiego jak hurtownia danych. Hurtownia nie musi być zakupiona u jakiegoś giganta wytwarzającego systemy. Hurtownię może zrobić każdy, byle spełniała wymagania jej stawiane i stanowiła jedyne źródło wiarygodnych danych.

Temat: A ja się dziwię programistom, przepraszam Was...

Aleksander Olszewski:
Jednakże podczas projektowania systemu kierujemy się jakimiś wytycznymi. Podobne wytyczne istnieją co do projektowania bazy.

Moim zdaniem tymi wytycznymi są wymagania i ich ograniczenia, zaobserwowałem, że bardzo często na liście wymagań brakuje "magicznego": system powinien pozwalać na dodawanie nowych modułów w przyszłości w obszarze zarządzania produktami albo system powinien pozwalać na rezygnację z modułu HR i zastąpienie go w przyszłości nowym systemem HR (itp.)

Bazy relacyjne nie są złe same z siebie, one są po protu najbardziej niemodyfikowalnym elementem implementacji... bardzo często taka kula o nogi...

Zgodzę się z Tobą, Jarku, że często zapomina się o tym, że jest coś takiego jak hurtownia danych. Hurtownia nie musi być zakupiona u jakiegoś giganta wytwarzającego systemy. Hurtownię może zrobić każdy, byle spełniała wymagania jej stawiane i stanowiła jedyne źródło wiarygodnych danych.

ja to często nazywam w swoich projektach "wzorzec hurtownia danych" (jest to element modelu dziedziny odpowiedzialny za pamiętanie o wybranych zdarzeniach). Klasycznym przykładem jest zapisywanie np. kolejno wystawionych dokumentów: każdy nowy kwit to fakt zawierający pełną treść dokumentu (żadnych normalizacji), wymiary to kluczowe metadane takie jak np. NIP kontrahenta, jego adres itp. Ta struktura nie jest w żaden sposób połączona, żadnego "klucza" do rejestru kontrahentów itp. grzebanie w niej jest proste, załatwia problem "historii zmian adresu", itp...

w dowolnym momencie mogę przejść na "prawdziwą hurtownię" jak ta się zatka...(w miejsce interfejsu do mojej lokalnej wstawiam interfejs do zewnętrznej.Jarek Żeliński edytował(a) ten post dnia 08.07.11 o godzinie 09:42

Temat: A ja się dziwię programistom, przepraszam Was...

Mateusz Kurleto:
...
Chciałem krótko zauważyć, że z punktu widzenia utrzymania i rozwoju systemu nie ma kompletnie żadnego sensu zaszywanie logiki biznesowej w bazie danych. Nie jest żadnym usprawiedliwieniem potrzeba optymalizacji zapytań, jeśli wymaga ona ingerencji w warstwę logiki biznesowej to jest błędem niemal zawsze.

I tu się całkowicie zgadzam.

Postać normalna, optymalizacje logiki na poziomie bazy danych itp. rozwiązania były programową odpowiedzią na bardzo wysokie koszty pamięci oraz mocy obliczeniowej. Różnica w koszcie utrzymania 1TB danych w roku 92 i 2011 oraz różnica w kosztach mocy obliczeniowej i pracy zmieniła się tak bardzo, że bardziej opłaca się optymalizować koszty maintenance pozwalając na redundancję danych oraz nie koniecznie najszybsze możliwe przetwarzanie niż ograniczać koszty pamięci i mocy obliczeniowej poprzez przenoszenie logiki biznesowej w warstwę danych.

A tu nie zgodzę się z motywacją. Model relacyjny powstał jako model matematyczny, oparty na teorii mnogości. Matematyczny opis powstał na przełomie lata 60. i 70., a pierwsza komercyjna implementacja silnika bazy powstała pod koniec lat 70.. Przypominam również, że pierwszy język obiektowy powstał pod koniec lat 60.

Tak jak widać, ciężko tu mówić o motywacji spowodowanej kosztami. W latach 60. komputery nie były wykorzystywane komercyjnie. Rząd płacił za nie tyle ile było trzeba. Owszem nie mówiliśmy wtedy o terabajtach i gigahercach. Wtedy dużo stawiało się na optymalne rozwiązania. Skoro wykonanie czegoś zgodnie ze sztuką zajmuje tyle samo czasu co kompletnie chaotyczne rozwiązanie, to dlaczego nie można zrobić od razu dobrze?

Temat: A ja się dziwię programistom, przepraszam Was...

Jarek Żeliński:
...
Bazy relacyjne nie są złe same z siebie, one są po protu najbardziej niemodyfikowalnym elementem implementacji... bardzo często taka kula o nogi...

Jeśli podzielimy bazę, podobnie jak to jest w systemie, na warstwy (mało szczęśliwa nazwa - layers) zgodnie z tym jak dzielimy system na komponenty (dosłownie 1:1) dostaniemy bardziej elastyczną i prościej modyfikowalną strukturę. Niestety mało jest ekspertów od baz danych.

Temat: A ja się dziwię programistom, przepraszam Was...

Aleksander Olszewski:

Jarek Żeliński:
...
Bazy relacyjne nie są złe same z siebie, one są po protu najbardziej niemodyfikowalnym elementem implementacji... bardzo często taka kula o nogi...

Jeśli podzielimy bazę, podobnie jak to jest w systemie, na warstwy (mało szczęśliwa nazwa - layers) zgodnie z tym jak dzielimy system na komponenty (dosłownie 1:1) dostaniemy bardziej elastyczną i prościej modyfikowalną strukturę. Niestety mało jest ekspertów od baz danych.

jak tak tę bazę dobrze podzielić to dojdziemy np. do wzorca Active Record...;)

Temat: A ja się dziwię programistom, przepraszam Was...

Jarek Żeliński:
jak tak tę bazę dobrze podzielić to dojdziemy np. do wzorca Active Record...;)

I kilku innych, a potem dojdziecie do wniosku, że przydał by się dobry ORM, tylko że konfigurować go powinien ktoś kto ma świadomość co będzie działo się w bazie. Czekaj, czekaj... coś mi świta...;)

Temat: A ja się dziwię programistom, przepraszam Was...

Aleksander Olszewski:
stawiało się na optymalne rozwiązania. Skoro wykonanie czegoś zgodnie ze sztuką zajmuje tyle samo czasu co kompletnie chaotyczne rozwiązanie, to dlaczego nie można zrobić od razu dobrze?

Bo dobrze to pojęcie względne. Jeśli mając na uwagę planowane ilości danych system działający pod względem złożoności zapytań nieoptymalnie daje wyniki w zadowalającym czasie a dzięki temu jest łatwiej modyfikowalny to w takim np. marketingu gdzie w dzisiejszych czasach okresy zwrotu z projektu spadają już <12 miesięcy i jednym z ważniejszych czynników dla biznesowego sukcesu jest dostarczanie dedykowanych funkcjonalności w możliwie krótkim czasie nie ma większego sensu optymalizacja i normalizacja baz.
Ponieważ i pamięć i moc obliczeniowa tanieje, to ten punkt krytyczny gdzie czasy zapytań zaczynają być problematyczne przesuwa się coraz dalej.
Jeżeli weźmiesz do tego pod uwagę fakt, że dzisiaj systemy hermetyzuje się wokół pewnych procesów biznesowych i wymienia danymi a nie tworzy integrowane molochy zauważysz, że pracujesz na ograniczonych danych, robiąc nakłady na zachowanie integralności.

Temat: A ja się dziwię programistom, przepraszam Was...

Mateusz Kurleto:

Jarek Żeliński:
jak tak tę bazę dobrze podzielić to dojdziemy np. do wzorca Active Record...;)

I kilku innych, a potem dojdziecie do wniosku, że przydał by się dobry ORM, tylko że konfigurować go powinien ktoś kto ma świadomość co będzie działo się w bazie. Czekaj, czekaj... coś mi świta...;)

;), a po co ORM skoro nie mamy zastanej relacyjnej bazy ???:)

rozróżniajmy jakoś bazę w rozumieniu motor do obsługi tablic a bazę w rozumieniu system RDMS relacyjna baza danych, bo odnoszę wrażenie, to zaczyna byc stek nieporozumień :)

Temat: A ja się dziwię programistom, przepraszam Was...

Mateusz Kurleto:
...
np. marketingu gdzie w dzisiejszych czasach okresy zwrotu z projektu spadają już <12 miesięcy i jednym z ważniejszych czynników dla biznesowego sukcesu jest
dostarczanie dedykowanych
funkcjonalności w możliwie krótkim czasie nie ma większego sensu optymalizacja i normalizacja baz.

Możliwie krótki czas też jest pojęciem względnym ;) Dla biznesu nie jest wartością oddanie projektu w możliwie najkrótszym czasie, ale w czasie możliwie najbliżej zaplanowanej daty oddania. Rusza kampania reklamowa 1 stycznia --- nie ma zmiłuj ma być 1 stycznia :)

Zakładając, że zwrot inwestycji następuje poniżej roku, to przynajmniej przez kolejny rok biznes chce zarabiać :) A my tu wwalamy dodatkowe koszta w utrzymanie, a po kilki modyfikacja strzelamy sorry... więcej nie da rady zmodyfikować. Przemyślana architektura zniesie wiele, zrobiona aby aby, po trzecim aby wysiada.

Ponieważ i pamięć i moc obliczeniowa tanieje, to ten punkt krytyczny gdzie czasy zapytań zaczynają być problematyczne przesuwa się coraz dalej.
Jeżeli weźmiesz do tego pod uwagę fakt, że dzisiaj systemy hermetyzuje się wokół pewnych procesów biznesowych i wymienia danymi a nie tworzy integrowane molochy zauważysz, że pracujesz na ograniczonych danych, robiąc nakłady na zachowanie integralności.

I tak i nie. Nadal mamy systemy czasu rzeczywistego, systemy internetowe itd. Zwróć uwagę, że w Internecie nadal działa prawo pierwszej sekundy :) Za przykład dam jakiś popularny portal, gdzie może zadziałać efekt skali: 10kB zaoszczędzonego transferu dla np. 300'000 odsłon to 3GB zaoszczędzanego transferu dziennie. Skrócenie czasu zapytania o np. 10 ms to możliwość obsłużenia np. 300 użytkowników więcej na minutę. Jest o co walczyć :)Aleksander Olszewski edytował(a) ten post dnia 08.07.11 o godzinie 13:46

Temat: A ja się dziwię programistom, przepraszam Was...

Jarek Żeliński:

Mateusz Kurleto:

Jarek Żeliński:
jak tak tę bazę dobrze podzielić to dojdziemy np. do wzorca Active Record...;)

I kilku innych, a potem dojdziecie do wniosku, że przydał by się dobry ORM, tylko że konfigurować go powinien ktoś kto ma świadomość co będzie działo się w bazie. Czekaj, czekaj... coś mi świta...;)

;), a po co ORM skoro nie mamy zastanej relacyjnej bazy ???:)

Bo do części danych nie ma dostępnego lepszego kontenera. Bazy obiektowe są jeszcze zbyt niedojrzałe, nowoczesne struktury słownikowe podobnie. Ciężko o alternatywę.