Temat: Redundancja / Optymalizacja

Witam.

Mam przed sobą pewne zadanie, które ma w sobie pełno niuansów, istotną nie jest to Czy da się zrobić, tylko jak zrobić najlepiej:

Założenia:
- Baza ma przechowywać informacje o nutach.
- Każde nuty posiadają autor(a/ów), gatun(ek/ki), instrumen(t/ty), tytu(ł/ły).
Tak więc wszystkie tabele w relacji M:N, co wiąże się z 4 dodatkowymi tabelami. W dużym uproszczeniu wygląda to mniej więcej tak:



- Dodatkowym problemem jest wielojęzyczność serwisu (wielo nie jest słowem przesadzonym, od włoskiego przez chiński po arabski) co wiąże się z tym, że będę musiał zastosować relację tabel TITLE i ARTIST do samych siebie by jednoznacznie identyfikować "Chopin" i "Szopen". Mało tego muszę zastosować kodowanie UTF8 (mulitbyte character zwalniający wyszukiwanie ).
- Rozmiar bazy ma znaczenie ( mały procent redundancji )

Domyślam się, że wiele rzeczy może wydać się sprzeczne i spowoduje pewnie pełną emocji dyskusję, ale wg. mnie i tego interface'u użytkownika, który mam zamiar wcielić w życie to jedyna sensowna opcja. Natomiast, jeżeli komuś wydaje się ( i ma to poparte doświadczeniem ),że jest na to lepszy sposób to w takim razie Bardzo Proszę o wskazówki ;)

Pozdrawiam
RafałRafał Wardas edytował(a) ten post dnia 12.04.08 o godzinie 00:40

Temat: Redundancja / Optymalizacja

Rafał Wardas:
Witam.

Założenia:
- Baza ma przechowywać informacje o nutach.
- Każde nuty posiadają autor(a/ów), gatun(ek/ki), instrumen(t/ty), tytu(ł/ły).
Tak więc wszystkie tabele w relacji M:N, co wiąże się z 4 dodatkowymi tabelami. W dużym uproszczeniu wygląda to mniej więcej tak:
- Dodatkowym problemem jest wielojęzyczność serwisu (wielo nie jest słowem przesadzonym, od włoskiego przez chiński po arabski) co wiąże się z tym, że będę musiał zastosować relację tabel TITLE i ARTIST do samych siebie by jednoznacznie identyfikować "Chopin" i "Szopen". Mało tego muszę zastosować

Albo porobić słowniki, wtedy w ARTIST byłoby tylko ARTIST_ID, a reszta w tabeli lokalizowanej, identyfikowane przez ARTIST_ID i LANG_ID.

I tak samo wszędzie gdzie potrzeba lokalizacji.

Temat: Redundancja / Optymalizacja

Jakub L.:

Rafał Wardas:
Witam.

Założenia:
- Baza ma przechowywać informacje o nutach.
- Każde nuty posiadają autor(a/ów), gatun(ek/ki), instrumen(t/ty), tytu(ł/ły).
Tak więc wszystkie tabele w relacji M:N, co wiąże się z 4 dodatkowymi tabelami. W dużym uproszczeniu wygląda to mniej więcej tak:
- Dodatkowym problemem jest wielojęzyczność serwisu (wielo nie jest słowem przesadzonym, od włoskiego przez chiński po arabski) co wiąże się z tym, że będę musiał zastosować relację tabel TITLE i ARTIST do samych siebie by jednoznacznie identyfikować "Chopin" i "Szopen". Mało tego muszę zastosować

Albo porobić słowniki, wtedy w ARTIST byłoby tylko ARTIST_ID, a reszta w tabeli lokalizowanej, identyfikowane przez ARTIST_ID i LANG_ID.

I tak samo wszędzie gdzie potrzeba lokalizacji.

W pewnym sensie miałem na myśli słownik. Nie podoba mi się tylko to, że posiadam kolumny `fname`, `lname` co trochę kłuci się z architekturą słownika, poza tym czasami w miejsce autora wpisuje się zespół a nie osobę(y). Myślę, że chyba utworzę anglojęzyczny odpowiednik artysty w jednej tabeli reprezentowany przez: (artist_id, fname, mname, lname, type, popularity) i dodam tabelę słownika (artist_id, keyword).

Pozdrawiam,
Rafał

Temat: Redundancja / Optymalizacja

wydaje mi się, że bardziej relacyjnie będzie przechowywać synonimy w osobnej tabeli

Temat: Redundancja / Optymalizacja

Mateusz Sokoła:
wydaje mi się, że bardziej relacyjnie będzie przechowywać synonimy w osobnej tabeli

W chwili obecnej rozmawiamy o wersji +/- takiej:



więc powyższa uwaga nie wchodzi w grę. ;)
Myślę, że jak połączę to z pspell i regex na wyszukiwaniu to powinno dawać całkiem dobry rezultat.

Pozdrawiam,
Rafał.Rafał Wardas edytował(a) ten post dnia 12.04.08 o godzinie 22:00

Temat: Redundancja / Optymalizacja

Podstawowe pytanie - co ma być w centrum zainteresowania? Utwór? I z nim mają być związane różne linie melodyczne? Czy może linia melodyczna, z autorem jest w centrum? Wydaje mi się, że raczej do drugie, ale z tego schematu, nazewnictwa to nie wynika...
Co do wersji językowych - jeżeli baza ma pilnować relacji to tylko osobna tabelka i relacja 1-do-Wielu.

Temat: Redundancja / Optymalizacja

Troche niescisloci widze w bazie..

a) jesli nutka, to przywiazana do konkretnego utworu, to dlaczego relacja M:N? jeden utwor, wiele nutek.. jesli ma byc M:N to sie robi burdel gdzie pod wieloma nazwami moze sie kryc wspolna nutka, ale to raczej bym przez jakies synonimy rozwiazywal a nie w taki sposob

b) genre, artist powinno byc podpiete imho pod utwor tez, bedziez mial zdublowane dane w wielu miejscach,

c) wersje jezykowe imho przez tabele z wpisanym langCode jako parametr, bo robienie wersji pol w bazie _it, _pl i etc. jest malo wygodne i elastyczne

d) synonimy do artystow i tytulow, nie wiem czy sam full-text nie wystarczy zeby w miare skutecznie wyszukiwac, sprawdz czy napewno takie synonimy potrzebujesz. ;)

Temat: Redundancja / Optymalizacja

Dariusz Sroka:
Troche niescisloci widze w bazie..

a) jesli nutka, to przywiazana do konkretnego utworu, to dlaczego relacja M:N? jeden utwor, wiele nutek.. jesli ma byc M:N to sie robi burdel gdzie pod wieloma nazwami moze sie kryc wspolna nutka,

Co do artysty przyznaję rację, że po dodaniu synonimów jest zbędna. "Genres" to tak naprawdę miało być "Style" i tu jest sprawa trochę śliska, bo różne utwory można wykonywać na różnych instrumentach. Utwór może być cover'em, reprezentującym zupełnie inny styl.

ale to raczej bym przez jakies synonimy rozwiazywal a nie w taki sposob

b) genre, artist powinno byc podpiete imho pod utwor tez, bedziez mial zdublowane dane w wielu miejscach,

Rezultat wyszukiwania będzie wyświetlany na zmaterializowanym widoku z agregacją stringów. Zdaję sobie sprawę, że można by to uprościć lub np. użyć typu tablicowego, chodzi o to, że przy przeglądaniu zawartości użytkownik ma możliwość (jeżeli nie w implementacji pierwszej wersji to na zapas) poruszania się po stronie wg atrybutów, np. przeglądać wg gatunku, stylu, autora.

c) wersje jezykowe imho przez tabele z wpisanym langCode jako parametr, bo robienie wersji pol w bazie _it, _pl i etc. jest malo wygodne i elastyczne

Tak też zrobiłem tepe ;)

d) synonimy do artystow i tytulow, nie wiem czy sam full-text nie wystarczy zeby w miare skutecznie wyszukiwac, sprawdz czy napewno takie synonimy potrzebujesz. ;)

Myślałem raczej o rozciągnięciu tabeli w pionie i indeksie B-drzewa, ale faktycznie może lepszy/wygodnijszy full-text.Rafał Wardas edytował(a) ten post dnia 16.04.08 o godzinie 01:02