Nie tak dawno temu wielu zarzucało Django , że w przeciwieństwie do Railsów nie posiada wbudowanego rozwiązania umożliwiającego wersjonowanie i modyfikowanie struktur bazodanowych. Niedługo po tym pojawił się South - dosyć obiecujące rozwiązanie, które oczywiście szybko przygarnąłem do projektów. Z czasem jednak okazało się, że architektura tego rozwiązania ma szereg wad.

Na południe

Podstawowym problemem a zarazem zaletą South jest związek migracji z aplikacjami Django . To poszczególne aplikacje są “dostawcami” migracji. Ma to na celu umożliwienie łatwiejszego utrzymania reusable apps, których upgrade w projektach był bez South bardzo trudny - wymagał poznania zmian struktury i własnoręcznego przygotowania skryptów SQL . O ile było to mozolne ale do zrobienia, to ustalenie migracji danych nie sposób było odtworzyć. Dzięki South sprawa się uprościła.

Zaiste nasi koledzy po fachu potrafią wycisnąć maksimum z teorii relacyjnych baz danych. Ba! To jest dzieło zasługujące na miano geniuszu!

Jest to fragment bazy danych popularnego bloga Wordpress 3.0. object_id jest FK jednocześnie do wp_post.ID oraz wp_link.link_id (sic!). Całość jeszcze nie wybuchła tylko dlatego, że fizycznie ta relacja NIE ISTNIEJE (istnieje tylko w podświadomości autorów) oraz dlatego, iż selecty z wp_term_relationships są robione zawsze z joinem do wp_term_taxonomy.