Witam

Jest to mój pierwszy post na tym forum także witam wszystkich
Mam kilka pytań odnośnie danych przechowywanych w jednym polu w bazie danych i sposobu ich pobierania.
Liczę na pomoc lub naprowadzenie mojego toku myślenia na poprawny

1. Pierwsze pytanie
Chciałbym stworzyć drzewo wartości tak jak na poniższym schemacie:
-> poziom 1
-> poziom 1.1
-> poziom 1.1.1
-> poziom 2
-> poziom 2.1

Przy założeniu że będą 3 poziomy zagłębień to niema problemu mogę zrobić w bazie 3 kolumny które będą przenosiły poziom szczegółowości. Ale jak wykonać taką funkcjonalność gdy takich poziomów chciałbym mieć X?

2. Drugie pytanie
Może okazać się, że rozwiązanie dla pytania pierwszego i 2 będzie takie samo, natomiast chciałbym jeszcze stworzyć relację danych w bazie jeden do wielu. O co mi chodzi:
np.:
Kowalski lubi sport i podczas wypełniania formularza zaznacza kilka dyscyplin sportowych. Chciałbym aby informacje które wybrał Kowalski trafiły do jednego pola w bazie danych. Nie chcę tworzyć 5 kolumn które będą opisywały zainteresowania Kowalskiego.
Chciałbym aby te dane przetrzymywane były w jednym polu np.:
mam listę zainteresowań, każde zainteresowanie ma swoje ID i żeby w takim polu była informacje 1;3;5;10 gdzie każda liczba oznacza ID zainteresowania.
I teraz tak:
a. Funkcjonalnie jest to jak najbardziej do wykonania, ale czy nie jest to przerost formy nad treścią. Stworzenie takiego mechanizmu jest troszkę skomplikowane.
b. Jak wyglądała by wydajność systemu gdy pobieralibyśmy informacje np.: 50 userów i jeszcze dodatkowo wykonywali X zapytań żeby pobrać ich zainteresowania.
c. Czy istnieje inna możliwość realizacji tego zagadnienia??

Od razu powiem kilka sów o sobie. Ekspertem w programowaniu nie jestem, ale mam troszkę pojęcia na ten temat. Potrafię posługiwać się google.pl ale chodzi mi bardziej o to żeby ktoś naprostował mój tok myślenia jeżeli do czegoś źle podchodzę. Za konstruktywną krytykę się nie obrażam

Pozdrawiam

Jeżeli chodzi o punkt pierwszy, to polecam zapoznanie się z "Drzewkami Depesza": http://www.depesz.com/index.php/drzewka-w-bazach-danych/
Swego czasu wykonałem implementację (nieoptymalną) dla MySQL'a: http://www.scanner.eu.org/dev/zathras/


Jeżeli natomiast chodzi o punkt drugi, to trzymanie zainteresowań w jednym polu jest pomysłem chybionym. Powinieneś lepiej zastanowić się nad trzema tabelami: Użytkownicy, Zainteresowania i UzytkownicyZainteresowania. Ta trzecia będzie miała dwa pola: Id_Uzytkownik i Id_Zainteresowanie - dzięki temu w prosty sposób odczytasz wszystkie zainteresowania użytkownika oraz wszystkich użytkowników mających dane zainteresowanie.

Co do pierwszego to przeglądałem na szybko tę stronę i powiem Ci że to co jest przedstawione w 5 Metodzie jest bardzo interesujące.

A co do 2 pytanie dzięki za sprowadzenie mnie na prawidłowy tok rozumowania faktycznie tego nie przemyślałem pod tym kątem.
Ale z tego względu, że ja jestem dociekliwą bestią i liczę na Twoją wyrozumiałość to jak przeanalizowałem to co napisałeś to jest dla mnie wszystko jasne. Ale czy widziałeś może inny sposób rozwiązanie tego zagadnienia Bo w tym przypadku mamy tylko jedna niewiadomą której wartość jest X a druga zainteresowania jest z góry określona. A co w przypadku kiedy mamy 2 niewiadome Czy taki układ będzie miał nadal taki wydajny jak w przypadku tylko jednej niewiadomej

Dwie niewiadome? Czyli chcesz wyświetlić co..? Wszystkie zainteresowania wszystkich userów?
Na pewno zaproponowane rozwiązanie będzie wydajniejsze niż trzymanie ID zainteresowań w polu tekstowym.

Przy tym 2 pytaniu to moja pierwsza propozycja odpada bo wielkość jednego pola w bazie będzie olbrzymia.
Ale chodzi mi oto że np:
mam 1000 kowalskich albo X kowalskich
i mam 1000 zainteresowań labo Y zainteresowań
(porównanie nierealne ale chodzi mi o idee)
I jak każdy kowalski wybierze 1000 zainteresowań to otrzymamy 100 000 rekorów, funkcjonalnie nadal będzie to działało. Ale staram się patrzeć pod względem wydajności czy jest możliwość optymalizacji takiej struktury danych. Czy po prostu należy ograniczyć ilość wyświetlanych rekorów za jednym razem.

Po to są bazy danych, żeby obrabiać i przechowywać duże ilości rekordów.
Przykładowo jeden z moich klientów ma bazę, gdzie tabela relacji w drzewku depesza ma skromne 134099 rekordów i niczemu to nie przeszkadza, a ta ilość to i tak nie jest dużo.
Jeśli dobrze wszystko zaplanujesz, zarówno pod względem przechowywania jak i pobierania, to nie będzie dla Ciebie żadnego problemu.

A jak przy swojej metodzie pobierzesz userow zainteresowanych zainterewowaniem A?

Creneos czy ja?
I jak rozumiem masz na myśli metodę z polem tekstowym? Już to wykluczyliśmy z rozumowania, więc spokojnie

@scanner:
Pewnie ze Creneos
Jak pisalem posta to twojego jeszcze nie bylo


hymm, czytalem i jakos to umknelo mojej uwadze

to znaczy tak to jest generalnie proste
"proste" do realizacji - chyba bo nie próbowałem tego pisać aktualnie przygotowuje środowisko - fedora 10 nadchodzi
zakładamy ze wszystkie dane które będą trafiać do pola z zainteresowaniami będą oddzielone separatorem np.: ";" średnik
pobieram dane z pola, segreguje i tworze z nich tablice, następnie sprawdzam czy szukane zainteresowanie jest przypisane do konkretnego kowalskiego jeżeli tak to wyświetlam szukane informacje

mam nadzieje że logicznie to napisałem, natomiast wydaje mi się, że tworzenie takiego czegoś to przerost formy nad treścią, ale dla sprawdzenie własnych umiejętności postaram się popełnić i przetestować kawałek takiego kodu

Z racji doświadczenia odradzam.
Tak się tego po prostu nie robi, a czas jaki zmarnujesz nie jest tego wart.

Pierwszy blad - to jest relacja wiele do wielu, co standardowo w SQL robi sie przez dodanie 3ciej tabeli (UserZainteresowania) - jak juz @scanner pisal).


(***)To to sie moglo by nadawac w przypadku gdy Kowalski zaznacza swoje zainteresowania, i jedyna operacja wykonywana pozniej jest pokazanie zainteresowan usera.
Wszystkie inne wyszukiwania sa niewykonalne w praktyce.


Przy N:M bedziesz mial w takim przypadku 5 rekordow dla Kowalskiego + mozliwosc modyfikowania zainteresowan bez zmiany schematu bazki.


No to by bylo tragiczne, bo mozna to zrobic 2ma sqlkami: 1. pobrac userow, 2. pobrac ich zainteresowania i odpowiednio wyswietlic.


Podstawowe pytanie: jak bedziesz operowal na zainteresowaniach, jesli chcesz robic cos wiecej niz (***) to zapomnij o srednikach.

przepraszam ze robię drobne OT, ale problem b. podobnej tematyki.
powiedzcie mi, jak to zrealizować...
klient wybiera sobie do 5 roznych kategorii w drzewku depesza, (myslalem ze na zasadzie <select><option>).
dodanie do tabeli wiele do wielu wpisow polega na:
- pobraniu wszystkich id dzieci wybranej kategorii
- dodaniu do tabeli klientKategorie odpowiedniej ilosci wpisow, oczywiscie sprawdzajac pierw, czy klient nie wybral kategorii powielajacych się....

i teraz nie wiem, czy w tej tabeli przykladowo przy jednej kategorii wybranej, ktora ma 11 dzieci, ma byc az 12 wpisow,
czy drzewko depesza umozliwia inaczej pobierac wszystkie wpisy danej kategorii, uwzgledniajac wpisy kategorii-dzieci ?