W dniu 2011-05-19 14:33, Michal Kleczek pisze:
> Andrzej Jarzabek wrote:
>
>> On May 18, 5:05 pm, Michal Kleczek<k...@g...com> wrote:
>>> Andrzej Jarzabek wrote:
>>>
>>>>> To tylko potwierdza moja teze - jezeli daje sie w dwa miesiace zrobic
>>>>> _uzyteczne_ (w sensie gotowe do wdrozenia produkcyjnego)
>>>>> oprogramowanie, to oznacza tylko tyle, ze to oprogramowanie jest po
>>>>> prostu trywialne.
>>>
>>>> Można to też ująć w ten sposób, że prawie zawsze złożone
>>>> oprogramowanie ma w sobie "trywialny" ale już użyteczny, choćby w
>>>> minimalnym stopniu, rdzeń.
>>>
>>> Dajmy na to taki RDBMS albo OS - jaki jest ten trywialny ale juz
>>> uzyteczny rdzen, ktory daje sie zrobic w dwa miesiace w wersji nadajacej
>>> sie do produkcji?
>>
>> Wziąłeś dwa ogólne przykłady typów programów, które mają od dziesiątek
>> lat wielu przedstawicieli gotowych do kupienia lub wzięcia z półki.
>> Oczywiście istnieje użyteczny rdzeń RDBMS czy OS jako takiego.
>> Przykładowo dla RDBMS będzie to program, który trzyma n tablic, gdzie
>> każda tablica ma k kolumn, dane są persistent i istnieje dostęp do
>> nich w jakikolwiek sposób, plus jakieś indeksy. Program, który spełnia
>> te założenia można napisać nawet w miesiąc i on już może być do czegoś
>> użyteczny. Oczywiście tu i teraz, gdzie istnieją gotowe RDBMSy można
>> powiedzieć, że skoro mozna mieć znacznie bardziej użyteczne RDBMSy za
>> darmo, to użyteczność robionego na zamówienie RDBMSa o takiej
>> funkcjonalności jest w praktyce zerowa.
>
> Dokladnie o to mi chodzi - niebanalny system ma taka ceche, ze jego
> "fragment" nie ma sensu z punktu widzenia uzytkownika. To nie jest tak, ze
> funkcjonalnosc (juz nie mowiac o cechach) daje sie dzielic i "wyciagac" i
> nadal twierdzic, ze system jest uzyteczny. To jest IMO mit rozpowszechniany
> przez zwolennikow "agile", ktorzy probuja - na szkode klienta - przekonac
> go, ze prototyp i produkt to to samo.

Ależ to zależy od klienta i systemu. Z drugiej strony nie wierzę, że
nie można w dużym odsetku projektów nie wyodrębnić choćby
funkcjonalności klasy "nice to have". I takie nie są krytycznie
potrzebne, da się je "wyciągnąć". Nie jest tak, że wszystkie systemy są
typu "wszystko albo nic", gdzie brak jednej funkcjonalności powoduje
kompletną bezużyteczność. Pozwolę sobie sparafrazować - to jest IMO mit
rozpowszechniany przez zwolenników waterfalli, którzy próbują - na
szkodę klienta - przekonać go, że bez choćby jednej funkcjonalności
produkt nadaje się tylko do kosza.

>> Ale w takim razie jeśli pytamy o robienie nowego RDBMSa na zamówienie
>> tu i teraz, to powstaje pytanie, dlaczego ktoś w ogóle zamawia nowego
>> RDBMSa? Odpowiedź może brzmieć np. tak, że potrzebny jest mu killer
>> feature A, którego nie ma żaden dostępny na rynku RDBMS. I w takiej
>> sytuacji dla klienta może być nawet użyteczny minimalny RDBMS z killer
>> feature A, choćby nie miał języka zapytań,
>
> LOL - to wlasnie jest podstawowa cecha definiujaca RDBMS (specjalnie nie
> napisalem DBMS). Sam fakt, ze w pliku mozna przechowywac rekordy stalej
> dlugosci nie swiadczy o tym, ze system plikow to RDBMS.
>
>> dostępu przez sieć,
>> transakcji, równoległego dostępu,
>
> Mozliwosc rownoleglego dostepu jest jedna z cech definiujacych DBMS (juz nie
> mowiac o RDBMS) - za wikipedia:
> "A DBMS provides facilities for controlling data access, enforcing data
> integrity, managing concurrency control, recovering the database after
> failures and restoring it from backup files, as well as maintaining database
> security"

Co nie umniejsza użyteczności rozwiązania, jakkolwiek by go nie
klasyfikować. Po prostu tyle wystarczyło, więcej było wyrzucaniem
pieniędzy w błoto, a co gorsza - stratą czasu. Budować w tej sytuacji
coś, co spełnia definicję (R)DBMS, kosztem czasu i pieniędzy w celu
spełnienia definicji (lub stworzonych rok wcześniej, a już
nieaktualnych założeń)?

--
Paweł Kierski
n...@p...net