Temat: Koszt realizacji bazy danych

Paweł Grzegorz Kwiatkowski:

Jak chce wyceniać, to ma np. metodę punktów funkcyjnych.

Tylko, że wycena wg. tej metody może się różnić o 2 rzędy wielkości albo i lepiej dla różnych firm.

Temat: Koszt realizacji bazy danych

Dziś, jak ktoś zaczyna od zera, robi model w jakimś ORMie. Wygenerowanie schematu z takiego modelu nic nie kosztuje, a zwykle model i tak trzeba zrobić. Jeżeli MySQL, to pewnie będzie PHP, żeby było taniej. Jeżeli tak, to pewnie będzie Symfony. Pierwszy link z google'a: http://www.symfony-project.org/jobeet/1_2/Propel/pl/03

Osobną sprawą jest optymalizacja tego wszystkiego. Jeżeli jednak projekt zaczyna się od zera, albo czegoś podobnego... Założyłbym pełen zestaw oczywistych indeksów - obie strony więzów integralności + pola, po których jest wyszukiwanie. Dodałbym też monitoring, żeby można było śledzić zmiany, wyłapać problemy. Cacti + Nagios - i można śledzić co się dzieje.

Temat: Koszt realizacji bazy danych

Paweł Grzegorz Kwiatkowski:
...
Jak chce wyceniać, to ma np. metodę punktów funkcyjnych.

Właściwie metoda puntów funkcyjnych z reguły nie działa i dotyczy głownie aplikacji. Tu są dane i z definicji nie powinno zawierać zbyt dużo tzw. magii w triggerach i procedurach. Tak więc wszystko i tak z reguły sprowadzi się do jednego puntu funkcyjnego: ma być baza :) lub do spisania wszystkich zapytań jako kolejnych punktów funkcyjnych. Jedne da zbyt duży margines błędu, drugie będzie zbyt kosztowne, jak to z reguły jest przy tej metodzie.

Temat: Koszt realizacji bazy danych

Michał Z.:
Dziś, jak ktoś zaczyna od zera, robi model w jakimś ORMie.

Dlaczego mam przeczucie, że w takim podejściu nie powstanie a ni jedna fizyczna relacja w bazie?

Wygenerowanie schematu z takiego modelu nic nie kosztuje, a zwykle

czy to komputer sam zrobi, czy jednak człowiek usiądzie i poświęci kilka godzin czy dni na rzeźbienie tego? No to chyba nie jest za darmo.

model i tak trzeba zrobić. Jeżeli MySQL, to pewnie będzie PHP,

w tym ujęciu nie będzie to model, a nadal skrypt generujący, tyle że w obiektowej otoczce.

żeby było taniej. Jeżeli tak, to pewnie będzie Symfony. Pierwszy link z google'a: http://www.symfony-project.org/jobeet/1_2/Propel/pl/03

Osobną sprawą jest optymalizacja tego wszystkiego. Jeżeli

no właśnie, czyli bez relacji i normalizacji. Czyli za rok magika od baz, bo baza nie wydoli?

jednak projekt zaczyna się od zera, albo czegoś podobnego... Założyłbym pełen zestaw oczywistych indeksów - obie strony

nie wiele jest indeksów oczywistych. Trzeba wiedzieć do czego baza służy i jak tabele będą się łączyć w zapytaniach i jakich.

więzów integralności + pola, po których jest wyszukiwanie. Dodałbym też monitoring, żeby można było śledzić zmiany, wyłapać problemy. Cacti + Nagios - i można śledzić co się dzieje.

Temat: Koszt realizacji bazy danych

Aleksander Olszewski:

Michał Z.:
Dziś, jak ktoś zaczyna od zera, robi model w jakimś ORMie. jednak projekt zaczyna się od zera, albo czegoś podobnego... Założyłbym pełen zestaw oczywistych indeksów - obie strony

nie wiele jest indeksów oczywistych. Trzeba wiedzieć do czego baza służy i jak tabele będą się łączyć w zapytaniach i jakich.

Tutaj głównie podejścia są dwa:
- zrobić indeksy jak się wydaje słuszne (a potem sprawdzać co dodać bo wolno działa)
- zrobić indeksy na wszystko (a potem monitorować ich używanie i wywalić nieużywane)

i sam nie wiem które jest lepsze... jak zwykle przy bazach: to zależy.

Temat: Koszt realizacji bazy danych

Aleksander Olszewski:

Michał Z.:
Dziś, jak ktoś zaczyna od zera, robi model w jakimś ORMie.

Dlaczego mam przeczucie, że w takim podejściu nie powstanie a ni jedna fizyczna relacja w bazie?

Nie mam pojęcia. Często zaczynam modelowanie w ormie i jakoś nie ma problemu z eksportem tego do skryptu sql... Taki skrypt to przecież też nie są relacje w bazie.

Wygenerowanie schematu z takiego modelu nic nie kosztuje, a zwykle

czy to komputer sam zrobi, czy jednak człowiek usiądzie i poświęci kilka godzin czy dni na rzeźbienie tego? No to chyba nie jest za darmo.

Ojej... Kolejny flame? Ja po prostu uważam, że projektowanie bazy w tym przypadku jest kompletnie bez sensu. Mając strategię biznesową firmy, można przygotować analizę konkretnego projektu. Potem zrobić projekt systemu. Oprogramować - w wybranej technologii. W ramach oprogramowywania oczekuję, że powstanie model. Jego wyeksportowanie do czegoś, co pozwoli bazie na stworzenie odpowiednich struktur jest banalne. Robienie najpierw bazy jest jak zabieranie się za programowanie od d... strony.

Zamiast zakładać, że to jest jakiś kolos - proszę założyć, że to prosty system - góra 100 tabel, wszystkiego, ze słownikowymi i co tam jeszcze może być potrzebne. Jeżeli ktoś chciałby system, którego projekt bazy danych kosztowałby 10k pln - nie pytałby na grupie, w ten sposób. Budżet całego projektu spokojnie pozwoliłby na zatrudnienie kogoś kumatego, kto udzieliłby odpowiedzi na takie pytanie. Ten ktoś wziąłby za to pieniądze i odpowiedzialność.

Z innych rzeczy - ORM potrafi tak wyeksportować model, żeby więzy integralności były założone. Które indeksy uważam za oczywiste też napisałem. To jest pierwsze przybliżenie, jeżeli okaże się, że któryś indeks nie jest potrzebny, wyjdzie w praniu i będzie go można skasować. Uważam, że takie coś spokojnie pochodzi przez 2-3 miesiące, a w tym czasie zostaną zebrane dane o pracy systemu. Zwykle też można się spodziewać, że klient będzie miał jakieś inne uwagi - np. dotyczące interfejsu użytkownika. Pewnie i tak trzeba się spotkać, omówić wdrożenie, dalszy rozwój aplikacji. Przejrzenie statystyk z bazy danych uważam za dobrą podstawę do rozmów. Dodatkowo można posprzątać to co nie jest potrzebne.

EOT.

Temat: Koszt realizacji bazy danych

Michał Z.:
...
Nie mam pojęcia. Często zaczynam modelowanie w ormie i jakoś nie ma problemu z eksportem tego do skryptu sql... Taki skrypt to przecież też nie są relacje w bazie.

W SQL skrypt generujący może wyglądać tak:

CREATE TABLE t2 (

  id INT UNSIGNED, 

  parent_id INT UNSIGNED,

  INDEX par_ind (parent_id),

  FOREIGN KEY (parent_id) REFERENCES parent(id)

  ON UPDATE CASCADE 

  ON DELETE RESTRICT

) ENGINE=INNODB; 

Jak widać jest tu kilka rzeczy, których rzekomo skrypt generujący nie generuje :)

Nie wiem jak z tym ORM, ale z reguły w ORM były braki z klauzulami UNSIGNED czy np. VARCHAR(12)
czy typem ENUM. Pyza tym jest masakra z dopilnowaniem unikatowych nazw indeksów i relacji (które de facto też są indeksami). I ostatecznie, na miłość boską, a ni kod w ORM ani skrypt SQL nie jest modelem! Modeluje się wizualnie.

Wygenerowanie schematu z takiego modelu nic nie kosztuje, a zwykle

czy to komputer sam zrobi, czy jednak człowiek usiądzie i poświęci kilka godzin czy dni na rzeźbienie tego? No to chyba nie jest za darmo.

Ojej... Kolejny flame? Ja po prostu uważam, że projektowanie bazy w tym przypadku jest kompletnie bez sensu. Mając strategię biznesową firmy, można przygotować analizę konkretnego projektu. Potem zrobić projekt systemu. Oprogramować - w wybranej technologii. W ramach oprogramowywania oczekuję, że powstanie model. Jego wyeksportowanie do czegoś, co pozwoli bazie na stworzenie odpowiednich struktur jest banalne. Robienie najpierw bazy jest jak zabieranie się za programowanie od d... strony.

Jeśli mówimy o programowaniu to się zgadzam. Tylko ilu programistów zna się na bazach? Jasne dobrym rozwiązaniem jest narobić syfu na początek, niech ktoś inny potem się martwi, jak zatrudnimy kogoś od baz.

Zamiast zakładać, że to jest jakiś kolos - proszę założyć, że to prosty system - góra 100 tabel, wszystkiego, ze słownikowymi i co tam jeszcze może być potrzebne. Jeżeli ktoś chciałby system, którego projekt bazy danych kosztowałby 10k pln - nie pytałby na grupie, w ten sposób. Budżet całego projektu spokojnie pozwoliłby na zatrudnienie kogoś kumatego, kto udzieliłby odpowiedzi na takie pytanie. Ten ktoś wziąłby za to pieniądze i odpowiedzialność.

Prosty system na 100 tabel w poprzednich postach "wyceniłem" na 800 PLN, czyli tyle co koszt 2 wieczorów nadgodzin programisty. Jak mu za to nie zapłacimy, to rzeczywiście dostaniemy to wszystko za darmo :)

Z innych rzeczy - ORM potrafi tak wyeksportować model, żeby więzy integralności były założone. Które indeksy uważam za oczywiste też napisałem. To jest pierwsze przybliżenie, jeżeli okaże się, że któryś indeks nie jest potrzebny, wyjdzie w praniu i będzie go można skasować. Uważam, że takie coś spokojnie pochodzi przez 2-3 miesiące, a w tym czasie zostaną zebrane dane o pracy systemu. Zwykle też można się spodziewać, że klient będzie miał jakieś inne uwagi - np. dotyczące interfejsu użytkownika. Pewnie i tak trzeba się spotkać, omówić wdrożenie, dalszy rozwój aplikacji. Przejrzenie statystyk z bazy danych uważam za dobrą podstawę do rozmów. Dodatkowo można posprzątać to co nie jest potrzebne.

EOT.

Mam za sobą kilka akcji ogarniania takich baz po 6.-12. miesiącach od ich utworzenia w ORM. W jednym z przypadków usunąłem 50% indeksów, ale dochodzenie co rzeczywiście jest potrzebne zajęło 1 tydzień. Taki tydzień też nie jest za darmo. Z poziomu ORM pewnych rzeczy nie widać. Jak taki programista założy indeks z ORM a kolejny programista pod inną nazwą indeks na to samo pole robi się syf. Sztuka z bazą polega na rozpoznaniu i indeksów na poziomie projektu bazy. No ale jak zwykle wolimy kupować tanie rzeczy, najlepiej za darmo. Jak SI jest za darmo, to jego utrzymanie kosztuje krocie. Nie żyjemy w komunizmie i za darmo nic nie ma.

Temat: Koszt realizacji bazy danych

Aleksander Olszewski:
Sztuka z bazą polega na rozpoznaniu i indeksów na poziomie projektu bazy. No ale jak zwykle wolimy kupować tanie rzeczy, najlepiej za darmo. Jak SI jest za darmo, to jego utrzymanie kosztuje krocie. Nie żyjemy w komunizmie i za darmo nic nie ma.

No to życzę pomyślnych łowów. Ech. Wymyślenie dobrych indeksów na podstawie projektu bazy to rzeczywiście sztuka.

Ja się widocznie nie znam, ale robię przeważnie indeksy, które są potrzebne, a nie te wynikające z projektu bazy. Projekt sobie może być jaki chcesz, a potem się okaże, że baza jest używana tak a nie inaczej i to jest niezależne od projektu. Indeksy nie są po to żeby projekt był ładny. Indeksy są tylko do przyspieszenia zapytań (oczywiście tylko niektórych i tylko czasami).

Temat: Koszt realizacji bazy danych

Szymon G.:

Aleksander Olszewski:
Sztuka z bazą polega na rozpoznaniu i indeksów na poziomie projektu bazy. No ale jak zwykle wolimy kupować tanie rzeczy, najlepiej za darmo. Jak SI jest za darmo, to jego utrzymanie kosztuje krocie. Nie żyjemy w komunizmie i za darmo nic nie ma.

No to życzę pomyślnych łowów. Ech. Wymyślenie dobrych indeksów na podstawie projektu bazy to rzeczywiście sztuka.

Trochę czegoś nie "łapię". Owszem robiąc bazę tabelkę po tabelce, ad hoc uwaga była słuszna. Czy taka właśnie padła tu propozycja? Podchodząc jednak do SI od strony projektowej, realizując go nawet metodą iteracyjną pewne ośrodki odpowiedzialności musimy najpierw zaprojektować. Gdzieś w tym wszystkim znajdzie się baza. Są wymagania użytkownika typu: "Chcemy wystawiać faktury firmom oraz klientom indywidualnym. Powinniśmy móc zidentyfikować klienta, któremu taką fakturę już wystawiliśmy." Co z tych dwóch zdań wynika? Potrzebujemy NIP, PESEL, Imię, Nazwisko/Nazwa, Adres zamieszkania/Siedziby, być może numer telefonu, ewentualnie e-mail oraz wszystko to co się znajdzie w fakturze. Po normalizacji dostaniemy relacje oraz klucze główne/klucze obce, które są już indeksowane i uwaga: nie trzeba na nie zakładać indeksów, bo będą się dublować. To chyba proste? Dodatkowo indeksujemy zapewne nr. telefonu, adres e-mail, PESEL (o ile nie jest kluczem głównym), NIP (i ile nie jest kluczem głównym i firma jest w osobnej encji), Nazwisko i pewnie miasto i ulicę ze wspólnym indeksiem lub osobnym, zależy z czym mamy do czynienia. Reszta z punktu widzenia tych dwóch zdań jest wtórne. Jaki z tym problem?

Chyba że klient mówi: "Mam wystawiać te eee..., faktury. No i, eee... będę je drukował. No i mmm..., wie pan lepiej ode mnie jak to działa."
To pewnie programista powie: "No to zrobimy eee... szybko, a tam się mmm..., zobaczy."

To dopiero jest przepis na klęskę projektową. No ale ja się na kozackich zagraniach się nie znam.

Ja się widocznie nie znam, ale robię przeważnie indeksy, które są potrzebne, a nie te wynikające z projektu bazy. Projekt sobie może być jaki chcesz, a potem się okaże, że baza jest używana tak a nie inaczej i to jest niezależne od projektu. Indeksy nie są po to żeby projekt był ładny. Indeksy są tylko do przyspieszenia zapytań (oczywiście tylko niektórych i tylko czasami).

Jeśli projekt rozbiega się z potrzebami klienta to znaczy, że potrzeby klienta nie są rozpoznane. To tak jak by budynek rozbiegał się z projektem budynku a tam coś poprawimy, jak zobaczymy. Jeśli baza opisuje rzeczywistość (a po to ten nieszczęsny model relacyjny powstał), taka baza "pociągnie" bez modyfikacji kilka lat, bo rzeczywistość tak szybko się nie zmienia (nie mylić z otoczeniem biznesowym). Czyżby to ogłoszenie nadal jest aktualne?

Temat: Koszt realizacji bazy danych

Aleksander Olszewski:

Doskonałe! Słyszałem kiedyś opinie, że gdyby inżynierzy budowlani budowali tak jak programiści kodują, żylibyśmy w rozpadającej się rzeczywistości ;)))

Moim skromnym zdaniem, programista powinien posiadać chociaż minimum wiedzy na temat branży dla której realizuje projekt, tj. jeśli koduje program księgowy, powinien orientować się (lub ktoś z zespołu) w księgowości przynajmniej na podstawowym poziomie.Eugeniusz Fizdejko edytował(a) ten post dnia 23.03.12 o godzinie 11:02

Temat: Koszt realizacji bazy danych

Eugeniusz Fizdejko:
...
Moim skromnym zdaniem, programista powinien posiadać chociaż minimum wiedzy na temat branży dla której realizuje projekt, tj. jeśli koduje program księgowy, powinien orientować się (lub ktoś z zespołu) w księgowości przynajmniej na podstawowym poziomie.

Jest to wręcz wymóg formalny przy bodowie zespołu w Scrum :)Aleksander Olszewski edytował(a) ten post dnia 23.03.12 o godzinie 11:03

Temat: Koszt realizacji bazy danych

Aleksander Olszewski:

Po normalizacji dostaniemy relacje oraz klucze główne/klucze obce, które są już indeksowane i uwaga: nie trzeba na nie zakładać indeksów, bo będą się dublować. To chyba proste? Dodatkowo indeksujemy zapewne nr. telefonu, adres e-mail, PESEL (o ile nie jest kluczem głównym), NIP (i ile nie jest kluczem głównym i firma jest w osobnej encji), Nazwisko i pewnie miasto i ulicę ze wspólnym indeksiem lub osobnym, zależy z czym mamy do czynienia. Reszta z punktu widzenia tych dwóch zdań jest wtórne. Jaki z tym problem?

Rozumiem, że mówisz o projekcie robionym od początku do końca na jedną konkretną bazę danych, tak? Czyli od razu zakładamy tylko mysql + innodb i nic innego?

Temat: Koszt realizacji bazy danych

OFFTOP:

Aleksander Olszewski:
[...]
Potrzebujemy NIP, PESEL, Imię, Nazwisko/Nazwa, Adres zamieszkania/Siedziby, być może numer telefonu, ewentualnie e-mail oraz wszystko to co się znajdzie w fakturze. Po normalizacji dostaniemy relacje oraz klucze główne/klucze obce, które są już indeksowane i uwaga: nie trzeba na nie zakładać indeksów, bo będą się dublować.

Warto zaznaczyć że to jest prawda o ile fiksujemy się na MySQL'u bo np. w Oracle już niekoniecznie. Ponieważ Pan opisuje wysoki poziom abstrakcji warto wspomnieć, że Pana uwaga dotyczy tylko konkretnej technologii.Przemysław Kantyka edytował(a) ten post dnia 23.03.12 o godzinie 14:21

Temat: Koszt realizacji bazy danych

Przemysław Kantyka:
OFFTOP:

Aleksander Olszewski:
[...]
Potrzebujemy NIP, PESEL, Imię, Nazwisko/Nazwa, Adres zamieszkania/Siedziby, być może numer telefonu, ewentualnie e-mail oraz wszystko to co się znajdzie w fakturze. Po normalizacji dostaniemy relacje oraz klucze główne/klucze obce, które są już indeksowane i uwaga: nie trzeba na nie zakładać indeksów, bo będą się dublować.

Warto zaznaczyć że to jest prawda o ile fiksujemy się na MySQL'u bo np. w Oracle już niekoniecznie. Ponieważ Pan opisuje wysoki poziom abstrakcji warto wspomnieć, że Pana uwaga dotyczy tylko konkretnej technologii.

Otóż to... zresztą indeksy i tak są "implementation detail" i, jeśli dobrze pamietam, nawet nie są uwzględnione w standardzie SQL.

W opisie na tak wysokim poziomie abstrakcji nie powinno być słowa o indeksach. Indeksy dotyczą implementacji li tylko.

Temat: Koszt realizacji bazy danych

Przemysław Kantyka:
OFFTOP:

Aleksander Olszewski:
[...]
Potrzebujemy NIP, PESEL, Imię, Nazwisko/Nazwa, Adres zamieszkania/Siedziby, być może numer telefonu, ewentualnie e-mail oraz wszystko to co się znajdzie w fakturze. Po normalizacji dostaniemy relacje oraz klucze główne/klucze obce, które są już indeksowane i uwaga: nie trzeba na nie zakładać indeksów, bo będą się dublować.

Warto zaznaczyć że to jest prawda o ile fiksujemy się na MySQL'u bo np. w Oracle już niekoniecznie. Ponieważ Pan opisuje wysoki poziom abstrakcji warto wspomnieć, że Pana uwaga dotyczy tylko konkretnej technologii.

Mam na myśli wizualne modelowanie w narzędziu CASE. Tak więc wszystko jedno do jakiej technologii to wszystko będzie później przenoszone. Jak CASE do MySQL nie obsłuży np. ORACLE, to ORACLE ma CASE z reverse engineering. Najgłówniejsze aby model był "ogarnięty".

Temat: Koszt realizacji bazy danych

Szymon G.:
...
Otóż to... zresztą indeksy i tak są "implementation detail" i, jeśli dobrze pamietam, nawet nie są uwzględnione w standardzie SQL.

W opisie na tak wysokim poziomie abstrakcji nie powinno być słowa o indeksach. Indeksy dotyczą implementacji li tylko.

Nie koniecznie. Na tym poziomie abstrakcji powinno się rozważyć typowe zapytania do bazy, jak np. wyszukiwania klienta po wcześniej wprowadzonych danych w fakturze. Rzecz jasna model biznesowy z czasem może się zmienić, ale nie zmienia on rzeczywistości. Tak więc model powinien odwzorowywać stan startowy. Jest to ważne z punktu widzenia nauki poprojektowej i ewentualnej weryfikacji kierunków ewolucji systemu.

Temat: Koszt realizacji bazy danych

Aleksander Olszewski:

Przemysław Kantyka:
OFFTOP:

Aleksander Olszewski:
[...]
Potrzebujemy NIP, PESEL, Imię, Nazwisko/Nazwa, Adres zamieszkania/Siedziby, być może numer telefonu, ewentualnie e-mail oraz wszystko to co się znajdzie w fakturze. Po normalizacji dostaniemy relacje oraz klucze główne/klucze obce, które są już indeksowane i uwaga: nie trzeba na nie zakładać indeksów, bo będą się dublować.

Warto zaznaczyć że to jest prawda o ile fiksujemy się na MySQL'u bo np. w Oracle już niekoniecznie. Ponieważ Pan opisuje wysoki poziom abstrakcji warto wspomnieć, że Pana uwaga dotyczy tylko konkretnej technologii.

Mam na myśli wizualne modelowanie w narzędziu CASE. Tak więc wszystko jedno do jakiej technologii to wszystko będzie później przenoszone. Jak CASE do MySQL nie obsłuży np. ORACLE, to ORACLE ma CASE z reverse engineering. Najgłówniejsze aby model był "ogarnięty".

OFFTOP:

Chyba się nie zrozumieliśmy - mnie chodzi o to, że w Oracle klucze obce nie są domyślnie indeksowane, a Pan napisał, że nie trzeba ich zakładać. W MySQL to prawda, ale w Oracle (jeśli narzędzie tego nie dopilnuje) stworzy Pan w ten sposób nieoptymalny system. Dodałem zatem, że Pana uwaga tyczy się już konkretnej implementacji, lub (to dodaję teraz) uwzględnia narzędzie które samo tego pilnuje.

Z tym "wszystko jedno do jakiej technologii" - takie stwierdzenie zawsze zapala u mnie w mózgu żółte światełko. Na pewnym poziomie abstrakcji to oczywiście prawda, ale zazwyczaj diabeł tkwi w szczegółach - np. wspomniane indeksowanie kluczy.

Pozdrawiam

Temat: Koszt realizacji bazy danych

Przemysław Kantyka:
...
Chyba się nie zrozumieliśmy - mnie chodzi o to, że w Oracle klucze obce nie są domyślnie indeksowane, a Pan napisał, że nie trzeba ich zakładać. W MySQL to prawda, ale w Oracle (jeśli narzędzie tego nie dopilnuje) stworzy Pan w ten sposób nieoptymalny system. Dodałem zatem, że Pana uwaga tyczy się już konkretnej implementacji, lub (to dodaję teraz) uwzględnia narzędzie które samo tego pilnuje.

Pierwotnie temat dotyczył MySQL, stąd być może dosyć mocno skupiłem się na konkretnej fizycznej implementacji. Niestety pomimo tego, że silniki bazodanowe niby implementują wystandaryzowane wytyczne języka, jednak ta implementacja wychodzi różnie: np. brak autoinkrementacji w PostgreSQL, czy prezent od ORACLE w postaci obsługi struktur drzewiastych. Przykłady można mnożyć.

Dlatego istotną kwestią jest dwukrokowa budowa modelu: model logiczny, a dopiero potem model fizyczny. Uodporni to model na zmianę technologii, a przejście na inną technologie odbywa się mniej boleśnie i mniejszym kosztem.

Z tym "wszystko jedno do jakiej technologii" - takie stwierdzenie zawsze zapala u mnie w mózgu żółte światełko. Na pewnym poziomie abstrakcji to oczywiście prawda, ale zazwyczaj diabeł tkwi w szczegółach - np. wspomniane indeksowanie kluczy.

Cieszę się, że żółte, a nie czerwone :) W projektowaniu obowiązuje reguła: od ogółu do szczegółu. Nie można zaniedbywać a ni jednego a ni drugiego.

Temat: Koszt realizacji bazy danych

Aleksander Olszewski:

Przemysław Kantyka:
...
Chyba się nie zrozumieliśmy - mnie chodzi o to, że w Oracle klucze obce nie są domyślnie indeksowane, a Pan napisał, że nie trzeba ich zakładać. W MySQL to prawda, ale w Oracle (jeśli narzędzie tego nie dopilnuje) stworzy Pan w ten sposób nieoptymalny system. Dodałem zatem, że Pana uwaga tyczy się już konkretnej implementacji, lub (to dodaję teraz) uwzględnia narzędzie które samo tego pilnuje.

Pierwotnie temat dotyczył MySQL, stąd być może dosyć mocno skupiłem się na konkretnej fizycznej implementacji. Niestety pomimo tego, że silniki bazodanowe niby implementują wystandaryzowane wytyczne języka, jednak ta implementacja wychodzi różnie: np. brak autoinkrementacji w PostgreSQL, czy prezent od ORACLE w postaci obsługi struktur drzewiastych. Przykłady można mnożyć.

Znaczy się, że nie ma autoinkrementacji w Postgresie??? Jak nie ma jak jest? (hint: typ serial)
Struktury drzewiaste w Postgresie są obsługiwane też.

Dlatego istotną kwestią jest dwukrokowa budowa modelu: model logiczny, a dopiero potem model fizyczny. Uodporni to model na zmianę technologii, a przejście na inną technologie odbywa się mniej boleśnie i mniejszym kosztem.

I tu się zgadzam :)

Z tym "wszystko jedno do jakiej technologii" - takie stwierdzenie zawsze zapala u mnie w mózgu żółte światełko. Na pewnym poziomie abstrakcji to oczywiście prawda, ale zazwyczaj diabeł tkwi w szczegółach - np. wspomniane indeksowanie kluczy.

Cieszę się, że żółte, a nie czerwone :) W projektowaniu obowiązuje reguła: od ogółu do szczegółu. Nie można zaniedbywać a ni jednego a ni drugiego.

a to w praktyce różnie wygląda, niestety :)

Temat: Koszt realizacji bazy danych

Szymon G.:
...
Znaczy się, że nie ma autoinkrementacji w Postgresie??? Jak nie ma jak jest? (hint: typ serial)

Zwracam honory. Dobrze pamiętam, że dopiero od wersji 7.3?

Struktury drzewiaste w Postgresie są obsługiwane też.

Tu akurat nie mogę się wypowiedzieć na temat PostgreSQL. ORACLE naprawdę nieźle oprogramował obsługę struktur drzewiastych. Tylko tyle maiłem na myśli :)

Dlatego istotną kwestią jest dwukrokowa budowa modelu: model logiczny, a dopiero potem model fizyczny. Uodporni to model na zmianę technologii, a przejście na inną technologie odbywa się mniej boleśnie i mniejszym kosztem.

I tu się zgadzam :)

Z tym "wszystko jedno do jakiej technologii" - takie stwierdzenie zawsze zapala u mnie w mózgu żółte światełko. Na pewnym poziomie abstrakcji to oczywiście prawda, ale zazwyczaj diabeł tkwi w szczegółach - np. wspomniane indeksowanie kluczy.

Cieszę się, że żółte, a nie czerwone :) W projektowaniu obowiązuje reguła: od ogółu do szczegółu. Nie można zaniedbywać a ni jednego a ni drugiego.

a to w praktyce różnie wygląda, niestety :)

To prawda. Łatwo jest ulec presji i puść na skróty.