Poprzedni wpis (Dziwne potrzeby, oczywiste rozwiązania: polib) | Następny wpis (Nine Inch Nails, We're In This Together)
Ludzie mają problemy
A my nie! (My, czyli kilka naszych aplikacji)
Iwan Sagalajew, pracujący dla yandex.ru, podzielił się kilkoma spostrzeżeniami po nieudanym odpaleniu nowego serwisu społecznego. Czytałem to z niekłamanym zadowoleniem — większość problemów, które tam opisał, nie ma nawet szans, żeby nas dotyczyć. Po kolei:
- zbyt długi czas zapisu danych sesji, nie dotyczy nas, bo sesje trzymamy w memcache;
- efekt "dog-pile", nie dotyczy nas, bo rzeczy kosztowne robimy poza aplikacją (poniekąd asynchronicznie);
- pomimo nacisków naszego DB-speca, nie normalizujemy naszego modelu nadmiernie.
Nie mam złudzeń, że w pewnym momencie będziemy musieli troszkę przyciąć nasz radosny bałaganik, ale aplikacja została zaplanowana z tak dużym zapasem, że to na pewno nie nastąpi w ciągu najbliższych kilku miesięcy...
Mała aktualizacja, pod wpływem komentarza Bluszcza — to on to wymyślił. A żeby nie rozpłynął się w samozachwycie, to wymyślił też parę marnych rzeczy, ale tego co marne pozbędziemy się prędzej czy później...
Etykiety: django free software / open source internet praca programowanie python
Komentarze (7)
#2 jarek skomentował(-a) 25 lutego 2008 o 22:27
Nie my, tylko Ty. :)
#3 depesz skomentował(-a) 26 lutego 2008 o 09:52
jako, ze przynajmnniej aktualnie jestem waszym "db-specem" prosze o sprostowanie.
nigdy nie sugerowalem normalizacji. nigdy nie proponowalem normalizacji. nigdy nie przedstawialem normalizacji jako lekarstwa na jakiekolwiek (faktyczne badz wyimaginowane) problemy.
nie wiem skad sie wzielo to zdanie: "pomimo nacisków naszego DB-speca, nie normalizujemy naszego modelu nadmiernie." zwlaszcza biorac pod uwage, ze wielokrotnie na forach publicznych informowalem, ze nie uwazam normalizacji za swietego graala i nigdy nie zdarzylo mi sie naciskac na kogokowleik w celu przeprowadzenia normalizacji do ktorejkolwiek postaci normalnej.
#4 jarek skomentował(-a) 26 lutego 2008 o 10:25
A Twoja niechęć do "generic foreign keys"? ;)
#5 depesz skomentował(-a) 27 lutego 2008 o 11:42
do czego? chodzi ci o pola które nie mają foreign keya, mogą być do dowolnej tabelki i o tym do której tabeli łączą informuje inne pole które jest mapowane w aplikacji?
jeśli o to, tak uważam, że używanie czegoś takiego to proszenie się o kłopoty.
zakłada to, że z bazy danych będzie zawsze korzystała tylko i wyłącznie jedna aplikacja z jednym orm'em, i nigdy nic więcej. napisanie czegokolwiek (sql) pod taką bazę jest tragedią porównywalną jedynie z oraniem pola własnym przyrodzeniem.
natomiast to zagadnienie jest całkowicie niezwiązane z normalizacją.
#6 jarek skomentował(-a) 27 lutego 2008 o 12:30
Wydawało mi się, że wprowadzanie kluczy obcych jest elementem normalizowania postaci bazy danych, ale widocznie jestem za cienki w tych sprawach.
A założenie rzeczywiście mamy takie. Prawie roczna zaś praktyka wykazuje, że z "żywego" sql korzystamy tak rzadko, że prawie nigdy.
#7 forgems skomentował(-a) 27 lutego 2008 o 13:26
>do czego? chodzi ci o pola które nie mają foreign keya, mogą być do >dowolnej tabelki i o tym do której tabeli łączą informuje inne pole >które jest mapowane w aplikacji?
>jeśli o to, tak uważam, że używanie czegoś takiego to proszenie się o kłopoty.
Depesz w django to do jakiej tabelki(a raczej modelu) jest mapowanie tez jest trzymane w bazie danych :)
select * from django_content_type;
Nie jest to zaszyte nigdzie w aplikacji ( no chyba że masz zdefiniowaną inną nazwę tabeli niż wskazuje nazwa modelu) ;)
#1 bluszcz skomentował(-a) 25 lutego 2008 o 21:56
jesteście zajebiści i pomysłowi ;)