Temat: Wyceny zaprojektowania bazy

Bogdan Pieńkowski:
Słowniki, jak ja lubię ten temat. A jak priorytetem jest wydajność to co?

To nico. Słowniki jej wcale tak drastycznie nie obniżają, tylko należy do pól słownikowanych dodać:
- warunek not null
- indeks
Za to nie zrobienie słownika może w przyszłości powodować nieprzyjemne komplikacje podczas modyfikacji systemu.

A jak w każdej kategorii występuje nie więcej niż powiedzmy 5 elementów unikalnych 5 znakowych to co, też słowniki?

To już zależy od:
- tego, czy taki słownik nie przyda się w jeszcze innych tabelach
- jeśli nie, to od:
. liczby rekordów w tabeli słownikowanej
. tego, czy mamy pewność, że ta liczba nie wzrośnie (ja wolę rozszerzać słowniki, niż grzebać w aplikacji, aby zmienić w tych kilku miejscach, w których normalnie bym z nich korzystała, listę dozwolonych wartości). Jeśli jest ich co najmniej kilkaset tysięcy, to jak najbardziej słownik - i do tego indeks bitmapowy na FK.
. tego, czy jest szansa na to, że zmieni się wartość któregoś z tych 5 elementów.

Nikt nie zna zakresu, a już wiadomo, że 15 tablic to za mało bo trzeba będzie przynajmniej 10 słowników.

Bo:
- to ma być "bardziej skomplikowany portal usługowy"
- ludzie, którzy tu piszą mają wyobraźnię i wnikliwie podchodzą do tematu. Założę się, że rzadko widuję strukturę z tak małą ilością tabel.

A teraz odpowiedź na pytanie

... co można zawrzeć w strukturze tylko 10-15 tabel.

Tearabajty danych!

To ma być baza danych, a nie hurtownia. Przecież taki z Ciebie zwolennik wydajności...

Temat: Wyceny zaprojektowania bazy

Nie będę polemizował bo będzie OFFTOP :) ja podszedłbym do tego inaczej. Dla mnie przy projektowaniu bazy danych zawsze najważniejsze jest "wyjście", a nie "wejście" ;)

Temat: Wyceny zaprojektowania bazy

Izabela Korzińska:

Bogdan Pieńkowski:
Słowniki, jak ja lubię ten temat. A jak priorytetem jest wydajność to co?

To nico. Słowniki jej wcale tak drastycznie nie obniżają, tylko należy do pól słownikowanych dodać:
- warunek not null
- indeks

W szkole tak powiedzieli? ;-) Jeżeli indeks nie trzyma wartości - będzie jeden strzał w indeks, a potem drugi w tabelkę ze słownikiem. Jeżeli indeks trzyma wartości - dla pięciu, może 10 wartości - seqscan i tak jest szybszy. Tak czy siak, jeżeli słownik jest mały - przejrzenie go nie stanowi problemu. Problem może być to, że zwykle są więzy integralności. Baza nie wie, czy w tym konkretnym przypadku coś może się zmienić, więc na wszelki wypadek je wymusza. Warto o tym pamiętać przy przetwarzaniu wsadowym wyłączyć gada.

Za to nie zrobienie słownika może w przyszłości powodować nieprzyjemne komplikacje podczas modyfikacji systemu.

To się nazywa "job security". Nie ma słowników - trzeba zgadywać co, które pole oznacza. No, albo mieć kogoś, kto wie. ;)

Zgadzam się, że słowniki to dobry pomysł. I to takie proste. Niech ich będzie nawet sporo. Wolę mieć narzędzie do zarządzania wieloma słownikami niż odwołania do jednego mega-słownika. Analiza takiego systemu pod kątem wydajności jest o wiele prostsza. Ewentualny refaktoring, dzielenie systemu na mniejsze części, kwestia uprawnień... No, w każdym razie tyle mi przyszło do głowy.

Pytanie czy lepiej mieć stałe w kodzie. I tam budować / rozwijać słownik. Jak się będzie zmieniać to lepiej w bazie - no, ale co to za słownik. W każdym razie - w bazie zmiana będzie tańsza. Jak na bazę danych wszyscy patrzą przez ORMa to może lepiej w kodzie. Zależy od przypadku. Mnie osobiście wpienia jak mam coś do zrobienia i potrzebne informacje / powiązania są rozsiane to tu - to tam. Pewnie nie ma dobrego rozwiązania, bo zawsze jest za mało czasu. I potem trzeba biegać i się dopytywać...

Temat: Wyceny zaprojektowania bazy

Bartosz Ślepowronski:

Dariusz Ż.:

Oskar Jarczyk:

>Chyba już niektórzy zapomnieli, że studenci

zrobią wszystko za każdą cenę.

nie zapomnieli ze zrobia wszystko, ale pamietaja tez jak to robia ;)

Swoją drogą to nie rozumiem czemu "student" ma być synonimem spartolonej roboty. Partolą partacze, niezależnie od tego czy są studentami czy nie.

Student nie jest synonimem "partactwa", student jest na początku drogi i niewiele umie, zna teorie ale do poznania praktyki mu jest daleko, takiego człowieka trzeba pokierować i tyle.

Temat: Wyceny zaprojektowania bazy

Dariusz Ż.:

Student nie jest synonimem "partactwa", student jest na początku drogi i niewiele umie, zna teorie ale do poznania praktyki mu jest daleko, takiego człowieka trzeba pokierować i tyle.

Przypomniał mi się taki dowcip:
- Czym się różni student 1-go roku informatyki od studenta 5-go roku tego kierunku?
- Student 1-go roku myśli, że kilobajt to 1000 bajtów. Student 5-go roku myśli, że kilometr to 1024 metry.

A tak na poważnie, są studenci którzy uczą się o BD dopiero na studiach a są też tacy, którzy na uczelniach rozwijają swoje wcześniejsze zainteresowania. Ci drudzy często posiadają wieloletnie doświadczenie w swoim fachu i nie powinno się wkładć ich do jednego worka z tymi którzy dopiero startują. Tak jak napisał Bartek, partolą partacze, niezależnie od tego czy są studentami czy nie.

Temat: Wyceny zaprojektowania bazy

Łukasz Schabek:
A tak na poważnie, są studenci którzy uczą się o BD dopiero na studiach a są też tacy, którzy na uczelniach rozwijają swoje wcześniejsze zainteresowania. Ci drudzy często posiadają wieloletnie doświadczenie w swoim fachu

Z tym wieloletnim doświadczeniem to lekka przesada, chyba że masz na myśli osoby, które idą na studia w wieku 25-30 lat tylko po papierek, bo z posiadaną wiedzą to by raczej mogli tam wykładać a nie uczyć się.

btw dowcip dobry :D

Temat: Wyceny zaprojektowania bazy

Przypomniał mi się taki dowcip:
- Czym się różni student 1-go roku informatyki od studenta 5-go roku tego kierunku?
- Student 1-go roku myśli, że kilobajt to 1000 bajtów. Student 5-go roku myśli, że kilometr to 1024 metry.

Kolejne kroki dochodzenia do nirwany :)
To jeszcze dorzucę kilka etapów - tym razem jak najbardziej z życia wziętych:
- świeżo upieczony absolwent myśli, że wie wszystko, bo przecież skończył studia z wyróznieniem.
- absolwent po 3 latach po zakończeniu studiów odkrywa, że są rzeczy, których nie wie i o których nie słyszał.
- absolwent po 5 latach od zakończenia studiów odkrywa, że są tacy, którzy wiedzą od niego więcej - i to nie tylko w jednej, wąskiej dziedzinie.
- absolwent po 8 latach dochodzi do wniosku, że wiedza, którą zdobył podczas nauki C i asm na studiach zaczyna mu się przydawać w zupełnie nieoczekiwanych miejscach
Sorry za offtopa :)

Temat: Wyceny zaprojektowania bazy

Bogdan Pieńkowski:
Słowniki, jak ja lubię ten temat. A jak priorytetem jest wydajność to co? A jak w każdej kategorii występuje nie więcej niż powiedzmy 5 elementów unikalnych 5 znakowych to co, też słowniki?

A co? Chcialbys to zalatwic ograniczeniem CHECK na tabelce?
Projektantom placa od zaprojektowanej tabelki, wiec juz Cie nie lubia :-)

Nikt nie zna zakresu, a już wiadomo, że 15 tablic to za mało bo trzeba będzie przynajmniej 10 słowników.

A dokladnie - przy 15 tablicach wychodzi na to, ze 14 z nich to slowniki :-)

A teraz odpowiedź na pytanie

... co można zawrzeć w strukturze tylko 10-15 tabel.

Tearabajty danych!

W 15 tabelach? Tyle to mozna wpakowac do jednej tabeli... (zeby nie bylo - widzialem system zrobiony na jednej tabeli, ale to juz osobna bajka...)

Pozdrawiam

Mariusz

Temat: Wyceny zaprojektowania bazy

Mariusz Masewicz:

/.../

W 15 tabelach? Tyle to mozna wpakowac do jednej tabeli... (zeby nie bylo - widzialem system zrobiony na jednej tabeli, ale to juz osobna bajka...)

Hehe, ja na codzień ostatnio customizuję system, w którym zlecenia (de facto typowe dokumenty: nagłówek + pozycje) rozrzucone są w 12 bodaj tabelach: nagłówki w 6-ciu tabelach, pozycje w 4, słowniki w 2. Oczywiście wszystko znormalizowane (np. każda z tabel dot. nagłówka zawiera inne informacje z tych nagłówków) i powiązane tylko przez id :) Do dzisiaj nie rozumiem, jaki cel miał twórca systemu (nie ja na szczęście), robiąc takie śmigło.

Temat: Wyceny zaprojektowania bazy

Mariusz Masewicz:
A co? Chcialbys to zalatwic ograniczeniem CHECK na tabelce?

Nie bo po co?

Projektantom placa od zaprojektowanej tabelki, wiec juz Cie nie lubia :-)

Kiepski system rozliczeń!

A dokladnie - przy 15 tablicach wychodzi na to, ze 14 z nich to slowniki :-)

A czemu nie 15 byłby PWN ;) na półkę

W 15 tabelach? Tyle to mozna wpakowac do jednej tabeli... (zeby nie bylo - widzialem system zrobiony na jednej tabeli, ale to juz osobna bajka...)

rosyjska Nu pagadi?

Temat: Wyceny zaprojektowania bazy

biorąc pod uwagę, że zaprojektowanie prostej bazy 3-5 tabel powiedzmy dla stosunkowo (bardzo) prostego serwisu typu CMS czy blog, nad którym zwykle pracuje jedna osoba, zajmie jakieś dwa dni (2x8h = 16mh*; w tym mamy krótką analizę czego potrzebujemy, stworzenie diagramu, relacji, oraz ryzyko zmian / fixów), przy większym projekcie gdzie zwykle kilkuosobowy zespół pracuje nad rozwiązaniem czas takiego zadanie wydłuży się pewnie o 20-30% z powodu problemów w komunikacji, niejasności i na bieżąco dodawanych zmian w projekcie (case: nagle się okazuje że implementacja w zdefiniowany sposób jest technicznie niemożliwa, projektant / architekt może, ale nie musi zdawać sobie sprawy ze wszystkich ograniczeń, baa...czy da się przewidzieć wszystko? więc konieczne są przeróbki architektury danych, modelu, uaktualnienie dokumentacji, itd.). Dodatkowy czynnik, który wydłuży cały proces, to zwiększający się poziom złożoności (zwłaszcza w przypadku określania relacji)...skala wykładnicza. Jeżeli ktoś chce do tego podejść procesowo, mając na względzie zarówno koszty jak i jakość, lepiej porządnie przysiąść nad designem i poświęcić temu maksimum uwagi, bo jeżeli zrobi się projekt po łebkach to potem koszty polecą podwójnie (trzeba będzie wprowadzać zmiany zarówno w projekcie jak i w implementowanym systemie), ale to chyba oczywistość.

ja bym to szacował w ten sposób, przyjmując pewne założenia:

16 mh - empiryczna stawka bazowa (subiektywna sprawa)
R - ryzyko; wyrażane w prawdopodobieństwie przedział 0-1
C - poziom złożoności, stała wartość (1, 3, 9, 27...)
K - koszt całkowity

K = 16mh*(1+R)*C

Przykładowo:

K = 16mh*(1+0,2)*3 = 57,6 ~ 58 mh, czyli 7,25 MD**

Pozostaje ustalenie stawki godzinowej / dniowej ;).

Można oczywiście podejść do tematu w stylu "za mniej nie 20k nie ruszam się z tyłka" :D

Tak w ogóle, to wątek powinien raczej trafić na grupę:
http://www.goldenline.pl/grupa/estimating-software

* man hours
** man days

Temat: Wyceny zaprojektowania bazy

Izabela Korzińska:

Bartosz Ślepowronski:
Co do 10-15 tabel, to co za bzdura. Albo ktoś kto się zna ocenił już, że to będzie tyle tabel, więc niech zrobi do końca (a jeśli nie chce to tylko znak że za mało płacą), albo ocenia to na oko ktos kto nie ma o tym zielonego pojęcia i wtedy z 10-15 tabel równie dobrze może się zrobić 50-100 po doprowadzeniu do jakiejś tam postaci normalnej. W końcu to ma być "bardziej skomplikowany portał usługowy"...

Dokładnie :)
Nigdy nie projektowałam struktury dla portalu, ale za to często z przeróżnych portali usługowych korzystam, jako klient i wiem jedno: nie ma to, jak dobrze skategoryzowane usługi, aby klient mógł wyszukać coś, co spełnia jego dość szczegółowe kryteria. Więc na dzień dobry widziałabym tam 10-15... słowników.
Generelnie - jeśli jakakolwiek baza ma nie ulec zaśmieceniu, musi zostać jak najlepiej znormalizowana - oczywiście w granicach zdrowego rozsądku.
Poza tym - jeśli w jakiś sensowny sposób mają być przechowywane dane adresowe klientów, to to wymaga już kilku słowników.

Prawdę mówiąc ciężko mi sobie wyobrazić, co można zawrzeć w strukturze tylko 10-15 tabel.

hmm... może jakiś podsystem leasingowy :) ?

Temat: Wyceny zaprojektowania bazy

Jarosław Żurek:

Izabela Korzińska:

>[...]

Prawdę mówiąc ciężko mi sobie wyobrazić, co można zawrzeć w strukturze tylko 10-15 tabel.

hmm... może jakiś podsystem leasingowy :) ?

Hehe, dla niektórych tutaj to by było wystarczająco dużo na cały system obsługi leasingu ;]
Ale prawdę mówiąc mogłoby wystarczyć np. na 1/4 struktury do obsługi floty, jeśli wykorzystywałaby już istniejące tabele modułów: umów, przedmiotów i kontrahentów.

Temat: Wyceny zaprojektowania bazy

A gdyby tablice były 3-wymiarowe?

Temat: Wyceny zaprojektowania bazy

Prawie wszyscy skupiają się na tych tabelach, a gdzie analiza całości, a wraz z nią wymiarowanie projektu IT. Rozumiem że mały projekcik, ale proponuję się zainteresować metodami wymiarowania projektów IT (przykładem mogą być COSMIC, punkty funkcyjne), tylko najlepiej mieć doświadczenie w podobnych projektach, żeby móc dobrze oszacować. Dosyć często firmy stosują mutacje metod, ale na jedno wychodzi. Pewnie strzelam do wróbla z armaty, ale może ktoś się zainteresuje ;)

Temat: Wyceny zaprojektowania bazy

Bogdan Pieńkowski:
A gdyby tablice były 3-wymiarowe?

można jeszcze w ogóle zakombinować i powrzucać jakieś skomplikowane typy obiektowe do owych 15 tabel i udawać, że tabel jest 15, a faktycznie x razy więcej :)
Tylko że to nie miałoby wtedy nawet pół pierwszej postaci normalnej.

A tak przy okazji to chyba czasami wszyscy zapominamy, że w biznesie "na końcu dnia" chodzi o to, aby "tanio kupić - drogo sprzedać". Do realizacji tego celu (który się nie zmienił od setek lat) 15 tabel wydaje się zupełnie wystarczające.. :)

Metoda wyceny systemu za pomocą punktów funkcyjnych jest bardzo ciekawa - polecam google. Ale - jak napisał poprzednik - do umiejętnego jej stosowania trzeba faktycznie dużego doświadczenia, bo można popłynąć (zarówno software house, jak i klient).

Temat: Wyceny zaprojektowania bazy

moim skromnym zdaniem zacząłbym tu od opisania problemu biznesowego, a nie założenia że ma być 15 tabel. żeby ocenić trudność zadania a następnie podać szacunkową cenę warto by było spojrzeć na problem od strony logiki biznesowej.
Co ma być robione ? Co ma dana baza realizować ? Dopiero wtedy nam wyjdzie ile tabel, jaka struktura.

pozdrawiam

Temat: Wyceny zaprojektowania bazy

Raczej realista - policzył koszty brutto (z maintenancem).

Temat: Wyceny zaprojektowania bazy

Piotr K.:
biorąc pod uwagę, że zaprojektowanie prostej bazy 3-5 tabel powiedzmy dla stosunkowo (bardzo) prostego serwisu typu CMS czy blog, nad którym zwykle pracuje jedna osoba, zajmie jakieś dwa dni (2x8h = 16mh*; w tym mamy krótką analizę czego potrzebujemy, stworzenie diagramu, relacji, oraz ryzyko zmian / fixów), przy większym projekcie gdzie zwykle kilkuosobowy zespół pracuje nad rozwiązaniem czas takiego zadanie wydłuży się pewnie o 20-30% z powodu problemów w komunikacji, niejasności i na bieżąco dodawanych zmian w projekcie (case: nagle się okazuje że implementacja w zdefiniowany sposób jest technicznie niemożliwa, projektant / architekt może, ale nie musi zdawać sobie sprawy ze wszystkich ograniczeń, baa...czy da się przewidzieć wszystko? więc konieczne są przeróbki architektury danych, modelu, uaktualnienie dokumentacji, itd.). Dodatkowy czynnik, który wydłuży cały proces, to zwiększający się poziom złożoności (zwłaszcza w przypadku określania relacji)...skala wykładnicza. Jeżeli ktoś chce do tego podejść procesowo, mając na względzie zarówno koszty jak i jakość, lepiej porządnie przysiąść nad designem i poświęcić temu maksimum uwagi, bo jeżeli zrobi się projekt po łebkach to potem koszty polecą podwójnie (trzeba będzie wprowadzać zmiany zarówno w projekcie jak i w implementowanym systemie), ale to chyba oczywistość.

ja bym to szacował w ten sposób, przyjmując pewne założenia:

16 mh - empiryczna stawka bazowa (subiektywna sprawa)
R - ryzyko; wyrażane w prawdopodobieństwie przedział 0-1
C - poziom złożoności, stała wartość (1, 3, 9, 27...)
K - koszt całkowity

K = 16mh*(1+R)*C

Przykładowo:

K = 16mh*(1+0,2)*3 = 57,6 ~ 58 mh, czyli 7,25 MD**

Pozostaje ustalenie stawki godzinowej / dniowej ;).

Można oczywiście podejść do tematu w stylu "za mniej nie 20k nie ruszam się z tyłka" :D

Tak w ogóle, to wątek powinien raczej trafić na grupę:
http://www.goldenline.pl/grupa/estimating-software

* man hours
** man days

Trochę mnie nie było na GL i proszę i ile postów przybyło!
Mało konkretnie zadane pytanie, a konkretna odpowiedź :) Dzięki wielkie
Nie myślałem, że dyskusja tak się rozwinie :)

Temat: Wyceny zaprojektowania bazy

Piotr K.:
ja bym to szacował w ten sposób, przyjmując pewne założenia:

16 mh - empiryczna stawka bazowa (subiektywna sprawa)
R - ryzyko; wyrażane w prawdopodobieństwie przedział 0-1
C - poziom złożoności, stała wartość (1, 3, 9, 27...)
K - koszt całkowity

K = 16mh*(1+R)*C

Przykładowo:

K = 16mh*(1+0,2)*3 = 57,6 ~ 58 mh, czyli 7,25 MD**

Nie rozumiem tylko czemu ryzyko zmian jest tylko w zakresie (0,1).
Jako prawdopodobieństwo, to sensowne, ale czy koszt zmian nie może być większy od kosztu implementacji?