"Nieograniczona" ilość atrybutów? Opcje

[Tiregan]

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.

Ten post edytował Tiregan 25.01.2011, 23:44:15

[Tiregan]

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ć.

Ten post edytował Tiregan 26.01.2011, 00:32:22