#naukaprogramowania #python #django Mam taką zagwozdkę mirki. Rozwiązanie jest zapewne banalne, ale nie mam pomysłu, jak do tego podejść. Chciałbym, aby każdy użytkownik po rejestracji otrzymywał wydzielone dla siebie 2 tabele (jeśli nie mam jakichś błędów w rozumowaniu, to można je utożsamić z modelami). Każda para będzie identyczna dla każdego użytkownika (będzie zawierać te same pola), różnica polegałaby tylko na nazwie (n.p. dodanym id po nazwie modelu).
Jest na to jakiś sposób? Jak na razie odgrzebałem na SO dynamiczne tworzenie modeli, ale tam nawet pola są zmienne. Jakimś rozwiązaniem byłoby też dodanie w tych dwu modelach obcego klucza w postaci id użytkownika do każdego rekordu, ale to wydaje się nieco brutalne.
@LOLWTF: @Szarlejowiec: będę używał ich do przetrzymywania danych potrzebnych do obsługi generatora list czytających (mój ostatni post w programowaniu). W pierwszej tabeli będą przetrzymywane osoby - imię, 3 wartości bool i jeden int zliczający ilośc wystąpień w liście (potrzebny do sortowania).
W drugiej tabeli będą przetrzymywane historyczne generacje list (używane do odtworzenia starszych aktów generacji).
I chciałbym, żeby każdy user miał swoje własne tabele, aby nie trzymać tego
@Fitoplankton: nie mozesz uzależniać modelu bazy danych od konkretnych danych, nie liczac widoków. moim zdaniem podejscie jest błedne i mialbyś z nim mega duzo problemow
@LOLWTF: @beeper: ok, po przemyśleniu to wydaje się być najlepszą opcją. W szczególności, że z django dopiero się zapoznaję i zbytnie "chachmęcenie" raczej mi nie pomoże. Już nawet nie wspominając kwestii, że złożenie do kupy tego wszystkiego przy dwu statycznych modelach będzie pierdyliardy razy prostsze. Dzięki za pomoc :)
@ksiak: to partycjonowanie jest bardzo ciekawe! Nawet gdzieś hasła o tym przewijają się po GitHubie (w kontekście samego django. Partycjonowanie odbywa się na płaszczyźnie samej bazy danych przy zachowaniu kompatybilności z django). To też poleciało do zakładek, dzięki :)
@Fitoplankton: dokładnie. To jest funkcja samej bazy danych i jest niejako transparentna dla języka SQL. Bardzo często jednak bazy dostarczają dodatkowe rozszerzenia do języka SQL którymi możesz coś więcej podziałać.
@morsik: zgadzam się, ale grzebanie na poziomie bazy korzystając z django zdarza się rzadko i większości przypadków oznacza, że robi się coś źle - jak w powyższym przykładzie
@Szarlejowiec: @morsik: akurat w tej sytuacji moje początkowe podejście było bez sensu, zgadzam się. Ale wątek z partycjonowaniem jest ciekawy. Nie wiem, na ile jest to bezpieczne działanie, ale przy naprawdę dużej bazie zysk powinien być zauważalny
Mam taką zagwozdkę mirki. Rozwiązanie jest zapewne banalne, ale nie mam pomysłu, jak do tego podejść.
Chciałbym, aby każdy użytkownik po rejestracji otrzymywał wydzielone dla siebie 2 tabele (jeśli nie mam jakichś błędów w rozumowaniu, to można je utożsamić z modelami). Każda para będzie identyczna dla każdego użytkownika (będzie zawierać te same pola), różnica polegałaby tylko na nazwie (n.p. dodanym id po nazwie modelu).
Jest na to jakiś sposób? Jak na razie odgrzebałem na SO dynamiczne tworzenie modeli, ale tam nawet pola są zmienne.
Jakimś rozwiązaniem byłoby też dodanie w tych dwu modelach obcego klucza w postaci id użytkownika do każdego rekordu, ale to wydaje się nieco brutalne.
Jakieś rady? Dzięki z góry ( ͡° ͜ʖ ͡°)
@Fitoplankton: coś robisz źle. Co chcesz osiągnąć?
W drugiej tabeli będą przetrzymywane historyczne generacje list (używane do odtworzenia starszych aktów generacji).
I chciałbym, żeby każdy user miał swoje własne tabele, aby nie trzymać tego
@beeper: czasami można a nawet trzeba tak uzależniać.