Temat: strona internetowa czy program?
Maciej W.:
A ja nauczony doświadczeniem, unikam używania funkcji w bazach danych, ponieważ najdrobniejsza nawet zmiana w jakiejś tabeli, powoduje ogromny problem. Pół biedy jeśli trzeba zmienić jakiś trigger, ale jeśli tabela jest "popularna", wówczas roboty jest cała masa.
Wiele zależy od tego jak zostało to rozplanowane. Poza tym jeśli logikę wyrzucisz z bazy, to to samo co musiałbyś zmieniać w funkcjach w bazie będziesz musiał zmienić w funkcjach poza nią (PHP?).
popieram... ciągłe użeranie się z nowymi wersjami przeglądarek to
niepotrzebne zawyżanie kosztu utrzymania softu.
A ja nie. Weźmy np taką Vistę lub SP3. Ile z tym problemu. Owszem, przeglądarki zmieniają się często, jednak jeśli używa się gotowych bibliotek do renderowania widoku, wówczas wystarczy poczekać na aktualizację danej biblioteki i po sprawie. A aktualizacje takie pojawiają się wcześniej niż oficjane wydanie nowej przeglądarki.
Ja do renderowania widoku używam JAVY... i nie muszę się przejmować tym czy klient jest odpalony na Viście, SP3, czy linuxie.
oczywiście są gotowe zmyśle biblioteki, ale oni zbyt często chcą
niestandardowe zachowanie
Od tego są pluginy do tych bibliotek, które rozwiązują taki problem. A jeśli nie ma takiej biblioteki, zawsze można ją napisać.
Tak... i tu jest problem, bo napisanie takiej zmyślnej biblioteki to ogromna praca. Zmyślna biblioteka nie może być tylko po stronie serwera - to zbyt niewygodne dla userów. Musi mieć różne javascripty, ajaxy... Musi przewidywać najróżniejsze wyjątkowe typy widoków (bo np. dla modułu obsługującego urlopy musi być widok kalendarzowy, z latami i miesiącami...). A to dopiero biblioteka do widoków. A biblioteka do formularzy? Obsługa wielu zakładek, mnóstwo helperów do typów pól (np. pole autouzupełniające, na podstawie słownika, a może na podstawie tabeli, a może z filtrami pochodzącymi z innych pól z formularza). Gdzieś też trzeba wepchnąć kontrolę dostępu na poziomie pojedynczego rekordu (i po co robić to dodatkową warstwą i zapytaniami, skoro dobrze napisany widok w bazie to załatwi? ).
Więc jak ktoś ma pieniążki i zakupuje takie coś gotowe - fajnie. Ktoś ma wystarczająco wiele pieniędzy aby posadzić przy tym kilku DOBRYCH programistów na dłuższy czas na tworzenie (bo rzecz nie w tym aby stworzyć potworka, który po pewnym czasie będzie się miało ochotę pisać od nowa), a następnie na utrzymywanie - to też fajnie.
Ale nie każdą firmę stać na aż takie inwestowanie, tylko po to aby móc powiedzieć - aby użyć naszego systemu nie musisz nic instalować.
Co szybko okaże się nieprawdą, gdy leniwi użytkownicy zapytają - "A jak dodawać wiele załączników na raz?" - i wtedy okazuje się, że jednak jakaś platforma typu Flash/czy Java i tak jest potrzebna. Albo "A jak zsynchronizować z..." i tu coś, co najwygodniej byłoby synchronizować lokalnie. Np. organizer w telefonie...
Jeśli coś ma działać sieciowo (workflow, zarządzanie treścią, itp) to tylko aplikacja www.
Moje doświadczenia są takie, że da się to zrobić, ale koszt jest ogromny. Wielki narzut poświęcany aby w HTML/Javascipt (Ajax) zamodelować zachowania które w zwykłej aplikacji można robić w banalny sposób. Problem ze znajdowaniem błędów (współpraca PHP/Javascript - póki nie przetestujesz nie znajdziesz).
Dodatkowy atut - jeśli dajesz potem kogoś do opieki nad systemem (ile razy trafia się coś w stylu - tak, system na to nie pozwala, ale to jest wyjątkowa sytuacja i TRZEBA coś zmienić) - to wystarczy, że będzie miał pojęcie o bazach danych, aby zdiagnozować i poprawić większość problemów.
A wracając do tematu. Nie można uciec przed zmianami. Każda technologia się zmienia i należy tak tworzyć oprogramowanie, czy to okienkowe, czy www, by albo było odporne na zmiany albo łatwo modyfikowalne.
Dokładnie. Przy czym upieranie się aby przepuszczać coś przez przeglądarkę(jak przez dziurkę od klucza) , kiedy to nie jest konieczne (np. w intranecie firmowym, bo tak czy siak wszystkie komputery są pod kontrolą IT) jest drogą fanaberią.
Adam Turczyniak edytował(a) ten post dnia 03.06.08 o godzinie 00:04