Witam wszystkich
Sytuacja jest następująca - chciałbym zrobić sensowny system który będzie wyświetlał produkt( jego opis) z bazy MySQL, lub/i z pliku. Chciałbym aby system był w miarę możliwości wydajny i w przyszłości było łatwo do niego napisać moduł administratorski. Wszystko wydało mi się w miarę proste i logiczne, do czasu kiedy doszło do mnie ile musiałbym dać kolumn w tabeli.
Zakładając że przykładowy produkt to komputer, to na sam opis podzespołów zeszło by około 10 kolumn, a do tego cena, numer fabryczny itd. Więc liczę około 15 kolumn, do tego opisy i już jest koło 20 kolumn. Myślałem wcześniej że do jednej tabeli jeszcze wcisnę linki do grafik, ale teraz myślę że tabela nie zamkła by się nawet w 30 kolumnach.

Nigdy jeszcze nie prowadziłem strony na której generowany jest duży ruch, ale myślę że wydajność takiej ogromnej 30 kolumnowej tabeli nie będzie duża.
Dlatego proszę o radę - w którą stronę iść? Rozbić tabele produkty na 3 - produkty_baza ( w ktorych będą kody produktu, ceny, dostępność, opisy całości ) produkty_opis ( np wykaz poszczególnych podzespołow ) i tabele produkty_grafika, czy moze iść w drugą strone zrobić jedną tabele_baza która będzie zawierała dodatkowo kolumny w których będzie link do pliku xml/php w którym będzie a) opis podzepołow linki do grafik. Który z pomysłów lepiej się sprawdzi, pod względem wydajności i łatwości zarządzania tym potem?

Co wtedy gdy opis będzie większy niż maksymalna długość rekordu? Co gdy przykładowy produkt będzie miał np dwa dyski twarde, jak uwzględnić taką hipotetyczną opcje?

Pozdrawiam
grexlort

Tak sobie głośno myślę. A może stworzyć tabelę z produktami, a w niej id, id_kategorii, nazwa i do tego stworzyć tabelę z opisem i w niej np. tworzyć id, id_produktu, nazwa_opisu (np. dysk twardy, procesor, ilość pamięci ram), opis. Z tym, że pole opis musiałoby mieć chyba wartość text, więc to już troszkę niepotrzebnie będzie obciążać bazę w przypadku, gdy mógłby być sam INT. Ale np. robisz coś takiego: id, id_produktu, "Ilość pamięci ram:", "4 GB". Żeby to wyglądało w ten sposób. Ja bym to może i tak rozwiązał. Później w panelu administracyjnym tworzyło by się określone pola i przypisywało by się do danego produktu.

Dzięki za odpowiedź, ale wtedy tabele mialy by po 15 kolumn, to i tak wydaje mi się dużo, szczególnie jak potem tych produktów było by więcej.
Ale dalej mnie nurtuje pytanie, czy warto to rozbić na 3 tabele, czy zrobić wczytywanie danych z jakiegoś pliku i do tego jedna tabela.

Przykładowy produkt który ma obszerny opis,

[PHP] pobierz, plaintext 
Kod Producenta	 Powerbit Office
System operacyjny	 Windows 7
Płyta główna	 Intel DH61
Procesor (rodzina)	Intel Celeron
Procesor (opis)	 Celeron G530 2.4 Ghz
Pamięć zainstalowana (pojemność)	 2GB
Pamięć (opis)	 DDR3
Karta graficzna	 Intel HD Graphics 3000
Karta muzyczna	 Realtek ALC892
Czytnik kart pamięci / FDD	Nie
Napęd optyczny (rodzina)	 Asus
Napęd optyczny (opis)	DRW-24B3ST SATA czarny OEM
Dysk twardy (pojemność)	 160GB
Dysk twardy (opis)	HDD SEAGATE 160GB ST3160812AS 8MB 7200 SATA
Obudowa	 I BOX FORCE
Monitor	Nie
Klawiatura	 Nie
Mysz	 Nie
Wyposażenie dodatkowe	 
Informacje dodatkowe	 Gwarancja na 24 miesiące
[PHP] pobierz, plaintext 

Jakieś 20 kolumn

Do tego 7 do 10 obrazków. Czyli jakieś 11 kolumn

I informacje typu ogólnego o produkcie

[PHP] pobierz, plaintext 
id 	
produkt_nazwa 
produkt_kod 	
produkt_cena 	
produkt_status 	
produkt_typ 	
produkt_dod 
[PHP] pobierz, plaintext 

czyli kolejne 7 kolumn, reasumując prawie 40 kolumn ktore użytkownik każdorazowo będzie wczytywał z bazy podczas oglądania produktu.

Jeżeli odwiedzi temat pan moderator, to mógłbym liczyć na przeniesienie do działu sql lub php? Napisałem tu gdyż to mój pierwszy temat.

Pozdrawiam
grexlort

Ja bym zaprojektował to w taki sposób:

Zrobiłbym tabele która zawierałaby ID produktu oraz obce ID z pozostałych tabel (opisanych poniżej), stanowiłaby pewnego rodzaju drogowskaz. Posiadając samo ID produktu wskazywałaby gdzie znajduję się informacje o nim.

Następna tabela zawierałaby najważniejsze i podstawowe informacje: cene, stan, krótki opis, rodzaj itp. (do tego ID dla każdego, które byłoby wykorzystywane w 'drogowskazach' )

Tabela z parametrami, byłaby swego rodzaju tabelą "systemową" zawierałaby tylko dwie kolumny: ID i "Parametry". O ile ID jest sprawą oczywistą, to "Parametry" zawierałyby typy parametrów (wiem że troche to mało jasne), przykładowo [rekord pola Parametry]: "producent|karta graficzna|zasilacz|obudowa|gniazda" (takie parametry wystarczy pobrać jednym zapytaniem i rodzielać za pomocą explode() )

Ostatnia tabela zawierałaby kolejne informacje o produkcie, i w kolumnie np. "Dane" znajdowałyby się dane do określonych parametrów z tabeli wyżej np.: "HP|nVidia Ge Force GTX Titan|OCZ 750W|ATX|2xHDMI, 5x USB3.0" i znowu tutaj explode i połączenie z parametrami z tabeli powyżej

Co do zdjęć, jeśli dobrze zaprojektowane jest drzewo katalogów na serwerze, nadawałbym wgrywanym na serwer plikom nazwy składające się z numeru ID (powiększonego o jakąś stałą wartość, lub jakiś stały, dozwolony znak alfanumeryczny dla zwiększenia bezpieczeństwa), separatora (czyli np znowu znaku alfanumerycznego) i następnie numer zdjęcia (jeśli np jest 10 zdjęć do jednego produktu). Nazwa takiego zdjędcia to np: 2010ax1.jpg (zdjęcie do produktu o ID:1007 [ ID zwiększamy o 1003] i dodajemy "a", potem separator "x" i index zdjęcia), następne zdjęcia do tego samego produktu to: 2010ax2.jpg, 2010ax3.jpg. W bazie danych jedynie trzeba zapisać ile jest zdjęć do danego produktu, np w głównej tabeli z 'drogowskazami'


Więc baza na plikach odpada ze względu na bezpieczeństwo oraz ryzyko usunięcia.


Zależy to od parametrów serwera i łącza, oraz najważniejsze czy zapytania do bazy będą dobrze napisane. Kiedy są złe zapytania nawet kilku kolumnowa tabela może stać się nie optymalną. Sam fakt tego że tabela miałaby 40 kolumn nie jest problemem i nie byłaby to największa tabela na świecie, problem z wydajnością stanowi ogromna ilość pustych pól oraz problem z przewidzeniem ile miejsca (znaków/bitów) będzie potrzebne na dany rekord w kolumnie.