Witajcie,
Chciałem się zapytać co bardziej doświadczonych o pewne zjawisko, które spostrzegłem.
Otóż na niektórych serwisach przy dodawaniu różnych "rzeczy" jest możliwość dodania nowego atrybutu, chociażby taki gmail, gdy tworzymy kontakt możemy mu dodawać różne pola, i to bardzo dużo, nie doszedłem do limitu.

Może ktoś z Szanownych Forumowiczów wie, wyobraża sobie jak, to wygląda w bazie MySQL?


Czy mój pomysł jest dobry?
Dodajmy atrybut typu longtext o nazwie opis. Niech będzie, to opis jakiegoś produktu w sklepie internetowym. Tak na prawdę nie będzie, to jedna zakładka na karcie produktu, ale będzie przechowywała ich kilka. Utworzę tak jakby znacznik nowej zakładki/atrybutu np. [bookmark]Nazwa zakładki[/bookmark]. Potem utworzę funkcję "parsującą", która mi podzieli owe pole opis na zakładki po tym właśnie znaczniku.

Przykład:
[bookmark]Opis[/bookmark]
Teks w zakładce.
[bookmark]Dane techniczne[/bookmark]
Teks w zakładce.
[bookmark]Dodatki[/bookmark]
Teks w zakładce.
[bookmark]Coś tam[/bookmark]
Teks w zakładce.

I tak w jednym polu typu longtext mamy teoretycznie ile chcemy zakładek.
Minusem jest, to że operacje na długim tekście wykonują się długo, z tego co wiem przynajmniej. Ktoś może ma lepszy pomysł? W MySQL chyba nie ma jakiegoś "typowego" rozwiązania tego problemu?


Jeżeli Wam także wątek wydaje się ciekawy, to może nie wybrałem najlepszego tytułu? Może go zmienić na inny?

Dziękuję,
T.

W mysql jest Model EAV albo po prostu xml trzymany w bazie.
W rzeczywistości są od tego bazy dokumentowe. W ogromnych rozwiązaniach to już duuużo by mówić

Dziękuję za cenne informacje. Nie wiedziałem o żadnej z wymienionych przez Ciebie technologii.

A mógłbyś mi coś polecić? A te XML trzymane w bazie, to coś w rodzaju mojego przykładu?

Ten Model EAV wydaje się interesujący. Chcę napisać pewien projekt w kohana i nie wiem, czy to obsłuży ORM.

Jeszcze raz dzięki.

Właściwie to troszkę sie zagalopowałem w odpowiedzi :/ Przepraszam.
Równie dobrze możesz przechowywać dane w tabeli o takiej strukturze

Oczywiście możesz ją rozszerzyć o jakieś "id_pola" dla typów predefiniowanych (email, telefon)
Wraz z pobraniem kontaktu pobierasz wszystkie pola do niego przypisane. Wpakujesz to wszystko razem w jeden obiekt cache i po sprawie. Wadą tego rozwiązania jest to iż wyszukiwanie po takiej tabeli jest niewydajne. W modelu EAV również wyszukiwania nie będzie supermanem. Oczywiście mam na myśli już tabele pokaźnych rozmiarów.

No właśnie. Chcę napisać w Koahana 3.x CMS do sklepów internetowych(nie tylko, ale żeby potrafił robić też bardziej rozbudowane serwisy i był bardzo upgrade'owalny). I tak czasami w ciągu dnia wpadają mi różne pomysły... Ale ten po prostu muszę mieć:-)
Nie znam się tylko na wydajności i nie wiem jakie jest najlepsze rozwiązanie pod tym względem. W sklepie internetowym może być bardzo dużo produktów, nie wiem czy dobrze(bardziej na "czuja"), ale wydaje mi się, że szukanie w dodatkowej tablicy, gdzie może być po np. 10 "podatrybutów", może okazać się mało wydajne? A może po założeniu indeksu na id_produktu w tabeli z tymi dodatkowymi "podatrybutami" rozwiąże poniekąd problem wydajności?
Jeżeli wszystko jest w tej tabeli typu EAV, to MySQL ma od razu atrybuty pod "ręką", chyba, więc może on jest wydajniejszy(ale co jeżeli dodam "podatrybut" po jakimś czasie, chyba doda go gdzieś na końcu tabeli? A wtedy pal licho tę "podręczność")?

Właśnie czytam jakiś kurs na jakimś anglojęzycznym forum o EAV i autor zniechęca do korzystania z niego, ale na forum gdzie ten kurs znalazłem zjechali go za, to...
I jak tu taki laik ma coś poradzić...
Jeżeli mi nie pomożesz wybrać, to chyba wylosuje sobie rozwiązanie, albo nie, zrobię, to wtedy w EAV, bo będę mógł powiedzieć, że wiem co to jest i to stosowałem:-) Ale jeżeli nie jest, to dobre rozwiązanie, to nie będę z tego korzystać.
No i jeżeli moduł ORM Kohana tego nie obsłuży, a ja nie będę potrafił go zmienić.

Przepraszam za niefachowe określenia. Nauczę się ich przy okazji nauki praktyki:-) Wydaje mi się, że tak jest szybciej.


P.S. To ja powinienem przeprosić za zawracanie głowy:-) Tobie mogę tylko podziękować.

Jeżeli sklepy nie będą duże to EAV nawet się sprawdzi. Z reguły właśnie takie będą ponieważ trudno mi znaleźć sklep internetowy posiadający ponad milion produktów.
Dodatkowo dla atrybutów, które będziesz przeszukiwać możesz utworzyć tabelę właśnie do wyszukiwania.
W przeciwnym wypadku musisz użyć innych technologii. Ale najpierw wypróbuj powyższy pomysł.

Co do ORM-ów. Zend Framework to implementował. Kohana raczej nie. Co do własnego pisania obsługi takiego zachowania to nie jest to trudne. Nie musisz przeciez implementować ścisłych wytycznych co do tego modelu. Chodzi o zrozumienie jego logiki i przetworzenie na własne potrzeby.

Wybacz, ale nie za bardzo rozumiem. Jeżeli wykorzystam model EAV, to chyba właśnie zastąpi mi on tę drugą tabelę z dodatkowymi atrybutami?

A, to myślałem, że sklep, to jest już duża baza:-) No w sumie, to serwisy aukcyjne mają pewnie największe bazy? Ciekaw jestem jak sobie z tym radzą.

Dlatego napisałem, że będzie to tabela tylko do wyszukiwania. Niczego więcej.

Allegro korzysta z Hurtowni danych Oracle.
Inni z baz dokumentowych (mongodb, riak) albo indeksów wyszukiwania pełnotekstowego (Solr, Sphinx, Elasticsearch)