class Green < ActiveRecord::Base
belongs_to :colors
…
class Red < ActiveRecord::Base
belongs_to :colors
…[/code]
Czy sa jakies przeciwwskazania co do np. wygody uzytkowania, wydajnosci czy czegokolowiek innego, czy spokojnie mozna takiej konstrukcji uzywac ?
z kolorami to byl tylko przyklad taki chodzilo mi czy duzo has_many nie obciazy bardzo bazy, ale z tego co mi sie wydaje po zaladowaniu jednego Modelu klasy kolor pozostale skladowe obiekty sa ladowane dynamicznie (wiec i polaczenie z baza dopiero wtedy sie odbywa) dopiero przy odwolaniu, mam racje ?
Pozwolę sobie jednak wysunąć pewne wątpliwości - czy faktycznie potrzebujesz klas takich jak “Red”, “Blue”, etc.
Wyglądają mi one zdecydowanie na instancje klasy kolor, a nie jej podklasy. Czy każdy z kolorów będzie miał inną funkcjonalność?
Szczerze w to wątpię. Z pewnością mogą różnić się wartościami atrybutów (np. heksadecymalny zapis koloru w palecie RGB), ale nie sądzę by miały metody o odmiennej implementacji.
Nie daj Boże, jeśli chodzi Ci o sytuację, w które kolor ma być wybierany np. w polu select - tutaj zdecydowanie nie powinno się tworzyć odrębnych klas. Żeby dodać nowy kolor, będziesz musiał zmieniać kod! A przecież spokojnie mogłoby to być robione przez interfejs administratora. Oczywiście jest to tylko praktyczny problem, który wynika z niewłaściwego modelu.
Rzuć okiem na moje notatki dot. modelowania konceptualnego (w szczególności punkt dot. relacji “isa”) oraz obiektowości w Rubim w (szczególności podpunkt “dziedziczenie”).
Zastanów się dobrze, czy właściwie wykorzystujesz ten mechanizm.
Faktycznie przykład z kolorami przedstawiony przez mojego imiennika jest niezbyt fortunny - w przypadku klasy Color zapisywałbym osobne składowe RGB w wartościach integer i wszystko by było cacy.
Arturowi chodziło tylko o to, czy przy dużej ilości relacji has_many w modelu nie będzie przeciążona baza danych. Nie zawsze trzeba zaglądać do podmodeli. I domyślnie tak się nie dzieje. Aby wymusić pobranie podmodeli trzeba użyć parametru :include.
@apohllo: A notatki Twoje o modelowaniu zostały dodane do ulubionych
Zainteresowala mnie ta relacja ISA która wskazales, w tym przykladzie “Planeta”, “Cialo niebieskie”, “Gwiazda” i “Ksiezyc” w przelozeniu na baze danych to beda poprostu tabele ?
Jak w tym przykladzie, w bazie danych, bedzie wygladac w praktyce np Ziemia która jest zarowno planeta jak i cialem niebieskim ?
Masz model CiałaNiebieskie, który ma pola: masa, średnica.
Model dziedziczący z niego to Planeta, ma pole dodatkowo jeszcze: zamieszkana
Inny model dziedziczący z CiałaNiebieskiego to Gwiazda, która ma pole dodatkowe: Jasność
Od strony technicznej wygląda to tak, że masz tabelę ciała_niebieskie, gdzie masz kolumny: masa, srednica, zamieszkana, jasnosc, type. Gdzie type określa typ dziecka CiałaNiebieskiego.
Tak to działa w STI(Single Table Inheritance).
Graficzne przedstawienie: http://martinfowler.com/eaaCatalog/singleTableInheritance.html
Post napisany przed dorzuceniem obrazka
A z tym krążeniem jeszcze, to nie wiem. Trzeba by było się zastanowić, ale to chyba jest has_one/belongs_to pomiędzy nimi jeszcze. Co jest możliwe jak najbardziej.
parametr moze byc liczba i brany z innej tabeli, w koncu nie bedzie ich 1000 tylko kilka/kilkanaście a wartość będzie stringiem, choć zależy co tam będzie trzymane cho widze ze promien jasnosc to moze byc integer.
ciala nioebieskie
1 | Nazwa | Gwiazda | Masa | Tempetratura
2 | Nazwa2 | Księżyc | Masa2 | Tmp2
Relacja Ksiezyc >|— Planeta to chyba nie ma co kombinowac i poprostu bylo by has_many, belongs_to jak Yax napisal. has_many bo planeta moze miec wiele ksiezyców, jak widac na wykresie
chodzilo mi czy duzo has_many nie obciazy bardzo bazy, ale z tego co mi sie wydaje po zaladowaniu jednego Modelu klasy kolor pozostale skladowe obiekty sa ladowane dynamicznie (wiec i polaczenie z baza dopiero wtedy sie odbywa) dopiero przy odwolaniu, mam racje ?
